Imported from BaezFJ/ExpressiveCSS (AGENTS.md). Install upstream with npx skills add BaezFJ/ExpressiveCSS. Copyright stays with the author.

Shared development instructions

• Start with CONTRIBUTING.md. Read the relevant source and callers before changing behavior.
• Keep fixes in the shared implementation. Reuse existing code, native browser features, and installed dependencies before adding abstractions.
• Read Sass architecture before stylesheet changes and TypeScript conventions before component changes. Engineering history and pitfalls live in development notes.
• Preserve public exports, markup compatibility, accessibility contracts, upstream references, and license notices unless an accepted change explicitly replaces them.
• semantics.json owns markup rules. The docs catalogue owns page inventory. Regenerate committed derived files with npm run build:semantics and npm run build:skill; do not edit generated copies by hand.
• Tests run against built bundles. Use npm run verify for the contributor checks and the separate MCP commands in CONTRIBUTING.md. Always tear down components and timers in finally blocks.
• Never initialize components in static semantics checks. Do not claim a browser or visual check passed when it was skipped.
• Follow SECURITY.md at trust boundaries and RELEASING.md for releases. Never publish from a contributor branch or move a published tag.
• Use Conventional Commit messages. Do not add Co-authored-by trailers or other Codex/AI attribution to commit messages.

Graft — repo context graph

Graft is optional. Its graft/ index is a local, ignored cache and is absent on clean checkouts. See optional setup. If the CLI or graph is unavailable, or a Graft command fails, use rg and direct source inspection instead. Do not block work or install tools just to satisfy these instructions. The graph workflow below applies only when Graft is usable.

With Graft available, get context from the graph before grepping or opening source files. Re-ask freely (it's cheap) and reuse literal identifiers you already have (symbol, error string, file name) as the query. New to this repo? Run graft map first — a token-budgeted orientation (dir clusters, hubs, hotspots), no LLM, no key.

• Run graft ask "<your question>" --source → ranked nodes with the relevant code spans inlined (each hit's ≤8-line crux by default; --full for whole definitions when the crux isn't enough). Match the tool to the task shape: for understanding or editing, the top node IS the answer — cite its covers: file:line spans and edit straight from --source. For exhaustive tasks ("every occurrence / every caller of this pattern"), ranked results are top-N, not complete — run graft grep "<literal>" instead (exhaustive over indexed files, grouped by enclosing symbol), falling back to raw grep -rn only for unindexed files.
• graft skeleton <file> → every definition's signature + span, ~10× cheaper than reading the file; use it to skim an API surface.
• graft callers <symbol> gives precomputed, exact edges — who calls this. Add --direction out for what it calls, or --depth N to walk transitively for the full blast radius. For structural questions, skip ranking and use this directly.
• Or browse: graft/INDEX.md lists every node; follow the links.
• Monorepos and folders of multiple repos rank fairly across sub-projects — hits carry [scope/] labels naming which one they're from. Narrow with graft ask "<task>" --in <scope>/ once you know where you're working.

If a returned span is truncated ("+N more lines"), open the file at that exact range before finalizing. Only open source files when a node genuinely lacks a needed detail, and then at the exact file:line the node points to — never re-read whole files.

After big code changes, refresh the graph with graft build (deterministic, no API key, $0).