594fccc80a
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>
56 lines
1.4 KiB
Markdown
56 lines
1.4 KiB
Markdown
# Users & workflows
|
|
|
|
<!--
|
|
Every actor that touches the system. Humans AND non-humans:
|
|
- other humans (collaborators, viewers, admins)
|
|
- AI agents
|
|
- integrations / webhooks
|
|
- scheduled jobs
|
|
- the data / export format itself
|
|
- future-self
|
|
- backups
|
|
Workflows extracted by asking "what do you do?" and then "who or what
|
|
is on the other side of each verb?"
|
|
-->
|
|
|
|
## Primary user
|
|
|
|
**<Name or role>**
|
|
- **Context**: <what they're doing when they reach for this app>
|
|
- **Job to be done**: <what success looks like for them>
|
|
- **Frequency**: <daily / weekly / occasional>
|
|
|
|
## Other user-classes
|
|
|
|
<!--
|
|
List every other actor surfaced by the workflow probe. One block each.
|
|
Non-human classes (agents, integrations, format) get the same treatment
|
|
as humans.
|
|
-->
|
|
|
|
### <user-class name>
|
|
- **Type**: <human / agent / integration / system / format>
|
|
- **Reads**: <what they read>
|
|
- **Writes**: <what they write, if anything>
|
|
- **Notes**: <anything special about their access pattern or constraints>
|
|
|
|
## Anti-personas
|
|
|
|
<!--
|
|
Who this app is NOT for. Naming these saves stories later, because
|
|
"can't we also support X?" gets a clean answer.
|
|
-->
|
|
|
|
- <type of user/use case explicitly excluded>
|
|
- <another>
|
|
|
|
## Workflows
|
|
|
|
<!--
|
|
Verb-keyed list. Each workflow is short. Detailed step-by-step lives
|
|
in flows.md.
|
|
-->
|
|
|
|
- **<verb>** — <one-line description, who's on each side>
|
|
- **<verb>** — …
|