card-class-handbook

Enforce the canonical Mica card-class contract for authoring UI components.

Updated May 21, 2026
One-click install
npx skills add https://github.com/mica-agent/mica-solar-system --skill card-class-handbook
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: card-class-handbook
Source: https://github.com/mica-agent/mica-solar-system/tree/main/.qwen/skills/card-class-handbook
Command: npx skills add https://github.com/mica-agent/mica-solar-system --skill card-class-handbook

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents repeated build-and-lint failures by codifying the canonical Mica card-class contract that tools enforce, so authors don’t redeclare injected globals, wrap code incorrectly, or write invalid metadata shapes.

Core Features & Use Cases

  • Defines canonical card-class architecture: explains the required four-file card class layout and how it renders an instance.
  • Documents the CANONICAL CARD.JS shape (CARD_SHIM contract): clarifies how container and mica are injected and must be used without redeclaration, plus where teardown logic belongs.
  • Spec frontmatter contract and decomposition tiers: teaches how structured specs map to handler/sidecar/dependencies and how to pick the cheapest viable tier per subtask.
  • Dependency-loading rules: explains UMD vs ESM patterns and how to load external libraries without guessing URLs.

Quick Start

Read this handbook, then author or update your card class by following the canonical card.js structure and the card-class spec frontmatter contract.

Frequently Asked Questions about card-class-handbook

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure a Mica card class using mica_create_class?

Mica card class authoring requires a canonical four-file layout including card.js and metadata.json. This structure ensures the class renders correctly and passes enforced build-and-lint checks without failure.

Why does my card.js build fail when I declare container and mica variables?

Card.js builds fail because container and mica are injected globals governed by the CARD_SHIM contract. Authors must use these objects directly without redeclaring them to prevent compilation errors.

How do I load external dependencies in a Mica card class?

Loading external dependencies in a Mica card class requires following strict UMD versus ESM library initialization patterns. This prevents incorrect code wrapping and ensures external libraries load without guessing URLs.

What is the spec frontmatter decomposition tier for Mica card classes?

Spec frontmatter decomposition maps structured specs to handler, sidecar, and dependencies configurations. It allows authors to select the cheapest viable execution tier per subtask to optimize card rendering.

Can I use ESM modules with mica_edit_class_file workflows?

ESM modules work with mica_edit_class_file workflows if you follow the documented UMD vs ESM initialization patterns. Adhering to the canonical file layout ensures proper module loading and handler selection.

Where should I put teardown logic in a Mica card.js component?

Teardown logic belongs inside the canonical card.js shape defined by the CARD_SHIM contract. Placing cleanup routines here ensures proper resource management when the card instance is destroyed.