movq/claude-plugins
2
0
Fork 0
Code Issues Pull Requests Actions Releases Activity

feat(composer): discovery-phase plugin from "I want an app that..." to tracker-loaded stories

Browse Source 
Plugin pairs with Symphony — Composer's output (issues in the project's
tracker) is Symphony's input. State-aware /composer command walks the
user through 11 phases: concept, users (with workflow probing for hidden
actors), requirements/NFR/IA, design system, interaction design, flows,
mocks, architecture, stories, roadmap, load. Each phase produces a
reviewable artifact in docs/planning/ (or, for design and interaction,
a project-local skill — see below).

Architecture is intentionally LAST, after the spec is complete. Mocks
are JSX/TSX regardless of final stack and pass a "text feasibility"
audit — every visible string is categorized (static/computed/authored),
computed strings are traced to source data, and any string implying an
unspecified feature halts the commit.

Design system and interaction design are produced as PROJECT-LOCAL
SKILLS in .claude/skills/<slug>-design-system/ and
.claude/skills/<slug>-interaction-design/, not as docs in
docs/planning/. Skills auto-load via description matching whenever UI
work happens; a reference doc gets read once and drifts out of context.
The mocks skill imports tokens directly from the design-system skill
for a single source of truth across mocks and (eventually) real code.

ui-system is currently a PLACEHOLDER — captures the minimum needed for
mocks to proceed with <TBD: ...> markers as a return-pass worklist.
Full interview specification is the next pass.

Council touchpoints baked in: PM/skeptic/end-user after requirements,
end-user/a11y after mocks, full architecture council after architecture,
plus auto-additions (legal-triage on regulated data, privacy-advocate
on PII, finance-controller on money flows).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
movq
2026-04-29 21:03:40 -05:00
parent cd3032458c
commit 594fccc80a
25 changed files with 1595 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

185
composer/skills/composer-mocks/SKILL.md Normal file
View File

@@ -0,0 +1,185 @@
---
name: composer-mocks
description: Generate or revise high-fidelity JSX/TSX mocks for named user flows in a Composer project. Mocks reference the design system tokens and follow the patterns declared in interaction-design.md. After generation, runs a text feasibility audit — every visible string is categorized (static/computed/authored) and traced to source data, so mocks don't lie about features the app can't yet generate. Use when the user runs /composer-mock, when the composer skill reaches phase 7, or when the user asks to "mock the X flow".
---
# Composer mocks
You generate **high-fidelity, non-functional** mocks in JSX/TSX. The
final application may end up React, React Native, SwiftUI, Flutter, or a
plain server-rendered template — JSX is just a fast, expressive way to
encode layout, content, and component composition. The mock is a
**storyboard**, not a build artifact.
## Prerequisites (hard checks)
Before generating, verify all of:
1. `docs/planning/flows.md` exists and contains the named flow.
2. `docs/planning/users.md` exists.
3. The **design-system skill** exists at `.claude/skills/<slug>-design-system/`,
including its `tokens.ts` and `components.md` sidecars.
4. The **interaction-design skill** exists at `.claude/skills/<slug>-interaction-design/`.
If any are missing, stop and tell the user which one — then point at the
phase that should produce it. The skills (not docs) are the contract:
they're what auto-load when UI work happens, so a missing skill means
generated mocks will reference patterns that aren't in context.
The `<slug>` is resolved the same way the `ui-system` skill resolves
it (package.json → git remote → directory name → ask).
## Tokens are the skill's sidecar
The mock imports tokens directly from the design-system skill:
```tsx
import { color, spacing, fontSize, radius, motion } from
"../../.claude/skills/<slug>-design-system/tokens";
```
There is no separate `mocks/tokens.ts`. The design-system skill's
`tokens.ts` IS the source of truth, and mocks import it directly.
This keeps a single token file in scope whenever UI is being touched
(mock or real code) — no duplication, no drift.
## Generation
For a flow named `<flow>`:
1. Read the flow's steps from `flows.md`.
2. Read the relevant patterns from the **interaction-design skill**
(state surface for this kind of action, motion policy, breakpoints,
locale). The skill should already be in context via description match;
read the SKILL.md explicitly if not.
3. Read the relevant entities from `ia.md` so component names match the
project's vocabulary.
4. Read `components.md` from the design-system skill so any component
referenced in the mock matches the declared anatomy.
4. Draft `docs/planning/mocks/<flow>.tsx` as a single-file mock.
- Use Tailwind classes referencing token values, or inline styles
reading from `tokens.ts` — whichever the design system declares.
- Components, not framework abstractions. No state, no effects, no
fetchers — this is a still life.
- Cover the empty/loading/error/offline states declared in
interaction-design.md, even if just as commented-out variants.
5. Run the **text feasibility pass** (below).
6. Offer a council review (Marge + Maya).
## Text feasibility pass
This is the headline pass. Every visible string in the generated mock is
categorized:
| Category | Definition | Mock shows… |
|---|---|---|
| **STATIC** | UI label, button text, fixed copy | The literal string |
| **COMPUTED** | Derived from data via a transform | A representative example + annotation comment |
| **AUTHORED** | Free text the user types in | A placeholder + clear "user-authored" marker |
For every **COMPUTED** string, document:
- **Source**: which entity / field. Must trace back to an entity declared
in `ia.md` or a state declared in `users.md`.
- **Transform**: what produces the string from the source.
- **Status**: ✅ source exists / ⚠️ source not yet specified / ❌ implies an unstated feature.
Output the audit to the user **before** committing the mock to disk
(if the source is incomplete) or **alongside** the mock (if everything traces).
### Audit format
```
log-feeding.tsx — text feasibility audit
14 strings. STATIC: 9, COMPUTED: 4, AUTHORED: 1.
COMPUTED:
┌─ "Last fed 6 hours ago"
│ Source: starter.feedings[-1].timestamp
│ Transform: relative-time formatter, locale-aware
│ Status: ✅ source field exists in ia.md
│ Note: interaction-design.md should declare relative-time
│ policy (when do we switch to absolute?)
│
├─ "Activity score: 7.2"
│ Source: starter.activityScore
│ Transform: format(score, 1 decimal)
│ Status: ❌ activityScore not in ia.md — implies a feature
│ we have not specified
│ Action: either add activityScore (with its computation) to
│ the model and to requirements.md, or remove this
│ element from the mock
│
├─ "Will peak around 4:30 PM today"
│ Source: prediction.peakTime
│ Transform: format(peakTime, "around h:mm a")
│ Status: ⚠️ prediction is in requirements.md as soft —
│ call out that "peak prediction" is a real subproject,
│ not a label
│
└─ "3 active starters"
Source: count(starters where status='active')
Transform: pluralize("active starter", n)
Status: ✅ trivial
```
### Halt-vs-warn
- **❌ status** in any string → **halt**. Do not commit the mock until the
user resolves: spec the feature properly, or remove the element. Lying
mocks anchor stakeholders to capabilities the team has not agreed to build.
- **⚠️ status** → **warn**. Commit the mock, but add a comment in the file
flagging the implication, and surface it in the post-generation report.
- **✅ everywhere** → commit cleanly.
## Naming and file shape
`docs/planning/mocks/<flow>.tsx`. One mock per flow. State variants
(empty / loading / error) live in the same file as commented sections or
as additional named exports — whichever the user prefers.
Header comment of every mock:
```tsx
/**
* Mock: <flow name>
* Source: docs/planning/flows.md § <flow>
* Generated: <date>
* Status: <draft | reviewed | stale>
*
* This is a non-functional mock. No state, no fetchers, no logic.
* Strings are annotated for source/transform per text feasibility pass.
*/
```
## Re-running on an existing mock
If the mock file exists:
- Compare `flows.md` § <flow> mod-time to the mock file. If flow is
newer, regenerate; if mock is newer, ask the user before overwriting.
- Always re-run the text feasibility pass after changes.
- Preserve the user's hand-edits where possible: diff before write.
## Council review
After a clean text pass, offer:
```
Mock committed. Summon Marge (end-user) and Maya (a11y) for review? [Y/n]
```
The review reads the mock and `interaction-design.md` and produces the
standard council output. Save to `docs/planning/reviews/mock-<flow>-<date>.md`.
## Hard rules
- **No mock without a clean (or warned) text feasibility audit.** A mock
that implies an unspecified feature is a mock that has lied to its viewer.
- **No tokens hardcoded.** Everything visual comes from the design-system skill's `tokens.ts`. Import directly; do not copy.
- **No state, no effects, no async.** This is a still life. If the mock
needs interaction to communicate, write a second mock for the next state.
- **Match the vocabulary in `ia.md`.** Don't introduce new terms in mocks
that the rest of the planning doesn't use.

291
composer/skills/composer/SKILL.md Normal file
View File

@@ -0,0 +1,291 @@
---
name: composer
description: Discovery-phase orchestrator. State-aware skill that walks a user from "I want an app that…" to a tree of stories in their issue tracker, writing reviewable artifacts in docs/planning/ along the way. Use when the user runs /composer, /composer-status, /composer-review, or /composer-load — or asks to "start product discovery", "lay out a project", or "plan an app". For mock generation, the composer-mocks skill is invoked. For design/interaction system, ui-system is invoked.
---
# Composer — orchestrator
You walk a user through product discovery, one phase at a time, producing
artifacts in `docs/planning/`. **Detect first, ask second.** Read what exists
before asking anything; resume at the first missing or stale phase.
## Modes
This skill has four modes, dispatched by which command invoked it:
- **continue** (default, from `/composer`) — resume the interview at the next missing phase.
- **status** (from `/composer-status`) — read-only progress report.
- **review** (from `/composer-review`) — convene a council on an artifact.
- **load** (from `/composer-load`) — push stories to the project's tracker.
## Phase order and artifacts
| # | Phase | Artifact path | Skill |
|---|---|---|---|
| 1 | concept | `docs/planning/concept.md` | self |
| 2 | users | `docs/planning/users.md` | self |
| 3 | requirements | `docs/planning/requirements.md` | self |
| 3 | requirements (NFR) | `docs/planning/nfr.md` | self |
| 3 | requirements (IA) | `docs/planning/ia.md` | self |
| 4 | design-system | `.claude/skills/<slug>-design-system/SKILL.md`† | `ui-system` |
| 5 | interaction-design | `.claude/skills/<slug>-interaction-design/SKILL.md`†| `ui-system` |
| 6 | flows | `docs/planning/flows.md` | self |
| 7 | mocks | `docs/planning/mocks/` | `composer-mocks` |
| 8 | architecture | `docs/planning/architecture.md` + `adr/` | self |
| 9 | stories | `docs/planning/stories.md` | self |
| 10| roadmap | `docs/planning/roadmap.md` | self |
| 11| load | (project tracker) | self |
†Phases 4 and 5 produce **project-local skills**, not docs in
`docs/planning/`. Skills auto-load via description matching whenever
UI work happens; a doc would not. Each phase also drops a pointer file
in `docs/planning/` (`design-system.md` and `interaction-design.md`) so
the planning index can find the skill location. Detect completion by
the SKILL.md file in the project skill directory, not by the pointer.
A phase with multiple files (requirements) is "complete" only when all its
files exist. The slug is resolved from `package.json` `name`, then git
remote name, then directory name (kebab-case ASCII).
## continue mode
### Detect
Scan `docs/planning/`. For each phase, decide:
- **missing** — artifact absent, this is where we resume.
- **present** — artifact exists.
- **stale** — artifact exists but an upstream phase was modified after it.
The first **missing** phase is where to resume. If everything is present, ask
the user whether to advance past load (suggest `/symphony-init`) or revisit a
phase.
### Phase 1 — Concept
Goal: one-paragraph north star.
```
What are you building? One sentence is fine.
```
Probe minimally — surface, audience, platform — then draft `concept.md` from
the template. Show the draft, accept edits, write the file. Do not invent
goals the user didn't state.
### Phase 2 — Users & workflows
Goal: surface every actor that touches the system, including non-human ones.
The interview pattern:
1. Ask who the user thinks the user is.
2. Ask what they *do* — list verbs.
3. For each verb, ask who or what is on the other side.
4. Probe for: other humans, AI agents, integrations, scheduled jobs, the data
format itself, future-self, backups.
Example move: if the user says "just me" but later mentions "I want Claude to
read these," surface that explicitly:
> Then we have at least two users: you (primary), and the agent (read access,
> possibly write?). That changes the data model — agent-readable usually means
> structured-enough to query. Want to add the agent as a named user-class?
Write `users.md` with: primary persona, anti-personas, named user-classes
(humans + non-humans), and a verb-keyed workflow list. **Never draft a
speculative second human persona.** Hidden actors are surfaced through
workflows, not invented.
### Phase 3 — Requirements (3 files)
Three artifacts, one phase.
**`requirements.md`** — hard / soft / non-goals.
Ask each in turn:
- Hard: "If the app doesn't do this, it isn't useful — what falls in that bucket?"
- Soft: "Would-be-nice items, deferable."
- Non-goals: "What will we explicitly say *no* to when it comes up?"
Push back on ambiguous "and" lists. Every conjunction is usually two
requirements pretending to be one.
**`nfr.md`** — non-functional requirements with thresholds.
Ask about: performance budgets, scale targets, availability target, security
posture, accessibility level (WCAG AA is the floor), browser/device support,
offline behavior, data retention, observability needs. Each one needs a
**number or named threshold**, not a vibe. "Fast" is not an NFR; "p95
interaction < 100ms on mid-tier mobile" is.
**`ia.md`** — information architecture.
Identify: top-level concepts (entities), how they relate, how they're
named, and how a user navigates between them. This is the taxonomy file —
it's what mocks and architecture both look up later.
After writing all three, **auto-suggest a council review**:
```
Three artifacts written. Summon Lena (PM), Vera (skeptic), and Marge (end-user)
to review before we move on? [Y/n]
```
If content suggests it, also propose:
- **Femi (legal-triage)** — regulated data, jurisdictions, third parties, IP
- **Camila (privacy)** — PII, multi-user data, biometrics, minors
- **Ingrid (finance)** — money, billing, refunds, subscriptions
### Phases 4–5 — Design & Interaction systems
Delegate to the `ui-system` skill. That skill writes **project-local
skills** to `.claude/skills/<slug>-design-system/` and
`.claude/skills/<slug>-interaction-design/`, plus pointer stubs in
`docs/planning/`. The skills auto-load on UI work; the pointers exist
only for human discoverability of the planning index.
`ui-system` is currently a *placeholder* — it captures the minimum needed
for mocks to proceed, with prominent `<TBD: ...>` markers. Composer
continues to phase 6 once both project skills exist; the user should
revisit `ui-system` to fully specify before mocks are committed.
**After write, tell the user to verify**:
```
Two project skills now installed:
.claude/skills/<slug>-design-system/
.claude/skills/<slug>-interaction-design/
These auto-load whenever UI work is happening in this repo. If you're
in this session, they should be available now (run /agents to confirm).
If you're starting a new session, they'll load on the first UI-related
prompt.
```
### Phase 6 — Flows
Goal: name every primary user journey, step by step.
Read `users.md`'s workflow list. Each top-level workflow becomes a named flow
in `flows.md`. For each flow, capture: actor, trigger, preconditions, the
step-by-step interaction, success state, failure modes.
Don't over-design here — the goal is *naming and sequencing the journeys*,
not specifying every screen. Mocks come next.
### Phase 7 — Mocks
Delegate to the `composer-mocks` skill. It generates one mock per flow and
runs the text feasibility pass.
### Phase 8 — Architecture
Now the spec is complete. Read `concept.md`, `users.md`, `requirements.md`,
`nfr.md`, `ia.md`, `design-system.md`, `interaction-design.md`, `flows.md`,
and skim the mocks. Surface the constraints to the user:
```
Big constraints I'm pulling out:
• [from requirements] hard offline-first
• [from NFR] p95 interaction < 100ms on mid-tier mobile
• [from users] AI agent reads notes — structured data needed
• [from interaction-design] mobile-first, single locale (English) for v1
...
That points at: <stack hypothesis>. Convening a council to pressure-test:
Tomás (architect), Gerald (sr engineer), Priya (DBA), Aisha (DevOps).
```
Run the council. Their synthesis informs ADRs. Draft each ADR (one per major
decision) using `adr/0000-template.md`; user signs off; write to
`adr/NNNN-<slug>.md`. Compose a summary `architecture.md` referencing the ADRs.
### Phase 9 — Stories
Goal: a flat list ready to load into the tracker.
For each flow, decompose into stories. Each story has: title, description,
acceptance criteria, dependencies (other stories), size estimate (S/M/L/XL),
and an epic/cluster tag. Don't over-decompose at this phase — granularity
shifts as the team starts working.
Reference flows.md for the source-of-truth on what each story enables.
### Phase 10 — Roadmap
Cluster stories into epics and sequence them into milestones. The first
milestone is the **smallest version that's still useful** — push back on
including soft requirements, NFR niceties, or scope creep here.
### Phase 11 — Load
See *load mode* below.
## status mode
Read-only. Print:
```
docs/planning/ ✓
concept.md ✓
users.md ✓
requirements.md ✓
nfr.md ✓ (modified after flows.md — flows may be stale)
ia.md ✓
design-system.md ⚠ placeholder (return to flesh out)
interaction-design.md ⚠ placeholder
flows.md ✓
mocks/ ✓ (3 of 5 flows mocked)
architecture.md —
adr/ —
stories.md —
roadmap.md —
Next: phase 8 — architecture.
Council reviews recorded: requirements (2026-04-29).
```
## review mode
When invoked from `/composer-review`:
1. Pick the artifact: argument-named, else current phase's primary artifact.
2. Pick the council: argument-named, else phase default (see CLAUDE.md table)
plus auto-additions when content suggests them.
3. Read the artifact + necessary upstream context.
4. Invoke the `council-of-experts:council` skill with a framed question.
5. Save the synthesis to `docs/planning/reviews/<artifact>-<YYYY-MM-DD>.md`.
6. Output the full council response to the user (the council skill already
formats this — pass through unchanged).
## load mode
When invoked from `/composer-load`:
1. Read `stories.md` and `roadmap.md`.
2. Read the project's `CLAUDE.md` for the tracker integration section. If
missing, exit with `tracker_integration_missing` and tell the user to
either run `/symphony-init` (which writes the section) or add it manually.
3. Build the planned write set:
- 1 milestone per first-cluster (the MVP slice)
- 1 epic/parent issue per cluster (if the tracker supports parents)
- 1 issue per story, linked to its epic, labeled per `stories.md`
4. Print the dry-run plan grouped by cluster. Show the exact tracker commands.
5. Wait for user confirmation.
6. Execute writes. On failure, stop and report — never auto-continue past an
error that might leave partial state.
7. Update `stories.md` with the created issue IDs (e.g.
`- [ ] PROJ-42 — Log a feeding for an active starter`). The file becomes
the local↔tracker map.
8. Suggest `/symphony-init` if the project doesn't have Symphony set up.
## Hard rules
- **One question at a time** during interviews. The user has the floor.
- **Never invent users, requirements, or features the user didn't state.**
Probe to extract; do not auto-complete.
- **Never push to the tracker without a dry run.**
- **Stale-aware.** When an upstream artifact changes, flag downstream
artifacts as `stale` in status; ask the user before silently regenerating.
- **Re-entrant.** Every phase can be re-entered. Re-running on an existing
artifact prompts the user before overwriting.

137
composer/skills/ui-system/SKILL.md Normal file
View File

@@ -0,0 +1,137 @@
---
name: ui-system
description: Interview the user and produce two project-local skills — a design-system skill and an interaction-design skill — that auto-load whenever UI work is in progress. Output goes to .claude/skills/<slug>-design-system/ and .claude/skills/<slug>-interaction-design/, NOT docs/planning/. The skills load themselves into context when anyone codes UI (mock or real); a plain reference doc would not. Currently a placeholder skill that captures the minimum needed for downstream phases to proceed; planned for a fuller specification pass. Use when the composer skill reaches phase 4 or 5, or when the user asks to "set up the design system" or "specify interaction patterns."
---
# UI system (placeholder)
> **Status: PLACEHOLDER.** This skill currently captures the minimum
> design-system and interaction-design content needed for the mocks
> phase to proceed. A fuller specification pass is planned. When the
> user returns to flesh this out, expand the interview sections below
> and the SKILL.md / sidecar templates.
## Why this is a skill, not a doc
A reference document at `docs/planning/design-system.md` gets read once
and then drifts out of context as the conversation grows. UI work that
happens later — generating a mock, writing a component, picking a color —
won't have it loaded.
A **skill** with a description that triggers on UI work is loaded
automatically every time the trigger matches. That's the whole point of
the skill mechanism. The design system and interaction design must be
skills.
## What this skill produces
Two project-local skills, plus their sidecar data files:
```
.claude/skills/<slug>-design-system/
├── SKILL.md ← the skill itself; auto-loads on UI work
├── tokens.ts ← machine-readable color / type / spacing / motion tokens
└── components.md ← component vocabulary with anatomy
.claude/skills/<slug>-interaction-design/
└── SKILL.md ← interaction patterns, state surfaces, input modes, i18n
```
And two stub pointer files in `docs/planning/` so the planning index
finds them:
```
docs/planning/design-system.md ← pointer; tells humans where the skill lives
docs/planning/interaction-design.md ← pointer
```
## Slug
The skills need a project slug for their `name:` frontmatter, so they
don't collide with skills from other projects on the same machine.
Resolution order:
1. If `package.json` has a `name`, slugify it.
2. Else if a git remote exists, slugify the repo name.
3. Else ask the user. Default to the directory name.
Slug rule: lowercase, hyphenated, kebab-case, ASCII only. Example:
`SourdoughTracker` → `sourdough-tracker` → skill `sourdough-tracker-design-system`.
## design-system interview (placeholder pass)
Ask the user, in order, with sensible defaults:
1. **Existing material?** Brand assets, mood boards, screenshots,
"make it look like Linear/Notion/Stripe", or nothing. If material
exists, ingest it before asking the rest.
2. **Color**: brand color(s), neutral scale (warm/cool/true), dark mode
(yes/no/system). Offer to generate accessible contrast pairs.
3. **Typography**: one family or two (display + body), size scale base
and ratio, line-height policy.
4. **Spacing**: scale base (4px / 8px), key spacing tokens.
5. **Radii**: tight / medium / pillowy.
6. **Shadows**: flat / subtle / generous.
7. **Visual motion**: default duration, default easing.
8. **Components**: confirm vocabulary against `ia.md`.
Mark unanswered with `<TBD: ...>` so the return pass has a worklist.
### Write phase — design-system
1. Write `.claude/skills/<slug>-design-system/SKILL.md` from
`templates/design-system/SKILL.md`. Substitute the slug into the
`name:` field and the project name into the `description:`.
2. Write `.claude/skills/<slug>-design-system/tokens.ts` from
`templates/design-system/tokens.ts`. Fill in the values gathered in
the interview; `<TBD>` for unanswered.
3. Write `.claude/skills/<slug>-design-system/components.md` from
`templates/design-system/components.md`.
4. Write `docs/planning/design-system.md` from the pointer template —
one paragraph saying where the skill lives.
## interaction-design interview (placeholder pass)
Ask, in order:
1. **Primary input**: touch / mouse / keyboard / mixed. Primary, supported, not supported.
2. **State surfaces**: pick one pattern per action class.
3. **Motion**: minimal / restrained / expressive. `prefers-reduced-motion` always honored.
4. **Breakpoints**: count, primary design target.
5. **i18n**: locales planned, RTL, string-length budget.
6. **Empty/loading/error/offline**: one declared posture each.
7. **Time formatting**: relative threshold, absolute format.
8. **Keyboard**: global shortcuts, escape behavior.
### Write phase — interaction-design
1. Write `.claude/skills/<slug>-interaction-design/SKILL.md` from
`templates/interaction-design/SKILL.md`.
2. Write `docs/planning/interaction-design.md` pointer.
## Re-entry
When the user returns to flesh this out fully:
- Expand the interviews above.
- Expand the SKILL.md and sidecar templates.
- Both skills are version-controlled in `.claude/skills/` — re-running
this phase shows the user a diff before overwriting.
The downstream contract is: `composer-mocks` reads the **skills**, not
the planning pointer files. That contract does not change as the
templates grow.
## Hard rules even in placeholder mode
- **Always produce both skills with sidecars.** Mocks can't proceed without them.
- **Always slug-namespace** so projects on the same machine don't collide.
- **Mark unknowns with `<TBD: ...>`** rather than inventing — TBDs are the return-pass worklist.
- **Don't pretend.** If the user has nothing and no opinions, say so in the SKILL.md: "No design direction set; defaults applied. Revisit before mocks are committed."
- **Tell the user what just happened.** After write, print:
```
Wrote two project skills:
.claude/skills/<slug>-design-system/SKILL.md
.claude/skills/<slug>-interaction-design/SKILL.md
These auto-load whenever UI work is happening. Verify after restart
with /agents (they should appear as project-local skills).
```