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

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>

composer/commands/composer-load.md

@@ -0,0 +1,21 @@
+---
+description: Push stories from docs/planning/stories.md into the project's issue tracker. Reads the project's CLAUDE.md to learn how to write to whatever tracker the project uses (GitHub Issues, Gitea, tracker CLI, Linear, etc.). Always shows a dry run before creating anything.
+---
+
+Invoke the `composer` skill in *load* mode. It will:
+
+1. Read `docs/planning/stories.md` and `docs/planning/roadmap.md`.
+2. Read the project's `CLAUDE.md` for the tracker integration section. If
+   no tracker section is documented, exit with `tracker_integration_missing`
+   and point the user at `/symphony-init` (which can write the section) or
+   suggest adding one manually.
+3. Build the planned write set — milestones, epics/parents, stories, labels.
+4. **Show a dry run.** Print every command the skill would run, grouped by
+   epic. Wait for user confirmation.
+5. On confirmation, execute the writes. On any failure, stop and report —
+   do not auto-continue past errors that might leave a partial write.
+6. Record the created issue IDs back into `stories.md` so the file becomes the
+   source-of-truth map between local plan and tracker reality.
+
+After load, suggest `/symphony-init` if the project doesn't already have
+Symphony configured. Composer's job ends here; Symphony's begins.

composer/commands/composer-mock.md

@@ -0,0 +1,28 @@
+---
+description: Generate or revise a JSX/TSX mock for a named user flow. Mocks are high-fidelity but non-functional, reference the design system and interaction design, and pass a text feasibility audit before being committed.
+arguments:
+  - name: flow
+    description: The flow to mock (must exist in flows.md). If omitted, lists available flows.
+    required: false
+---
+
+Invoke the `composer-mocks` skill with `$ARGUMENTS`.
+
+Prerequisites the skill checks before generating:
+
+1. `docs/planning/flows.md` exists and names the flow.
+2. `docs/planning/design-system.md` exists (tokens, type, components vocabulary).
+3. `docs/planning/interaction-design.md` exists (state surfaces, motion, input, i18n, breakpoints).
+4. `docs/planning/mocks/tokens.ts` is current with `design-system.md`.
+
+If any prerequisite is missing the skill stops and points at it. The mock is
+only as good as the systems it references.
+
+After generation the skill runs a **text feasibility pass**: every visible
+string is categorized (static, computed, authored), computed strings are
+traced to source data and transformations, and any string that implies an
+unspecified feature is flagged for the user to either spec properly or remove
+from the mock.
+
+After a clean text pass, the skill optionally summons Marge (end-user) and
+Maya (a11y) for a review.

composer/commands/composer-review.md

@@ -0,0 +1,27 @@
+---
+description: Summon a Council of Experts to review the current planning artifact. Defaults to a phase-appropriate council; accepts an explicit council list. Use when you want a stress-test of what you've drafted before moving on.
+arguments:
+  - name: artifact
+    description: Optional artifact name (e.g. "scope", "requirements", "architecture", "log-feeding"). Defaults to whatever Composer thinks the current phase is.
+    required: false
+  - name: council
+    description: Optional explicit comma-separated council member names (e.g. "Vera,Lena,Femi"). Overrides the phase default.
+    required: false
+---
+
+Invoke the `composer` skill in *review* mode with `$ARGUMENTS`.
+
+The skill will:
+
+1. Identify which artifact to review — the one named, or the current phase's artifact.
+2. Pick a council. Defaults from the phase boundary (see `CLAUDE.md`); user
+   override accepted. Composer also auto-adds members when content suggests
+   their domain (PII → Camila, money → Ingrid, regulated data flows → Femi).
+3. Read the artifact and any upstream context the council needs.
+4. Hand off to the `council-of-experts:council` skill with the question framed
+   for the artifact under review.
+5. Record the synthesis and suggested takeaways in
+   `docs/planning/reviews/<artifact>-<date>.md` so future phases see prior feedback.
+
+The output is the council's standard format: each member in their own voice,
+then agreements, disagreements, and prioritized takeaways.

composer/commands/composer-status.md

@@ -0,0 +1,13 @@
+---
+description: Show progress on the current Composer project — what's done, what's next, what artifacts may be stale relative to upstream changes.
+---
+
+Invoke the `composer` skill in *status* mode. It will:
+
+1. Read `docs/planning/` and report which artifacts exist.
+2. Compare modification times — if `requirements.md` was updated after
+   `flows.md`, flow content may be stale.
+3. Show the next phase Composer would resume on.
+4. List any council reviews that have been recorded vs. recommended.
+
+Read-only — no interview, no writes.

composer/commands/composer.md

@@ -0,0 +1,17 @@
+---
+description: Continue product discovery for this project. State-aware — reads docs/planning/ and picks up at the first missing or stale artifact. Run on a fresh project to start from "I want an app that…"; run again later to resume.
+---
+
+Invoke the `composer` skill. It will:
+
+1. Look for `docs/planning/` in the project root. Create it if absent.
+2. Detect which phase artifacts exist (`concept.md`, `users.md`, `requirements.md`, etc.).
+3. Resume at the first missing or stale phase.
+4. Run the appropriate interview, write the artifact, sign off with the user, advance.
+
+Phases that touch the design or interaction system delegate to the `ui-system`
+skill. The mock phase delegates to `composer-mocks`.
+
+The skill is conversational — it asks one focused question at a time and waits
+for the user. To skip ahead or jump back, use `/composer-status` or one of the
+phase-specific commands (`/composer-mock`, `/composer-load`).