claude-plugins/composer/commands/composer-mock.md at 187863fa163f355a01fde5bed8f4d246b91ca52b

Files

movq 594fccc80a 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>

2026-04-29 21:03:40 -05:00

1.3 KiB

Raw Blame History

description, arguments

description

arguments

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.

name	description	required
flow	The flow to mock (must exist in flows.md). If omitted, lists available flows.	false

Invoke the composer-mocks skill with $ARGUMENTS.

Prerequisites the skill checks before generating:

docs/planning/flows.md exists and names the flow.
docs/planning/design-system.md exists (tokens, type, components vocabulary).
docs/planning/interaction-design.md exists (state surfaces, motion, input, i18n, breakpoints).
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.

1.3 KiB Raw Blame History

1.3 KiB

Raw Blame History