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>
22 lines
1.3 KiB
Markdown
22 lines
1.3 KiB
Markdown
---
|
|
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.
|