Idea to Production
Deliver the smallest user-visible slice that proves the idea, with evidence at every handoff.
Definition of done
The journey is complete only when it has:
- an approved or safely inferred specification with explicit non-goals;
- an architecture decision proportional to the change;
- a dependency-aware work map;
- an end-to-end reproduction or acceptance test that initially fails;
- a working vertical slice using real boundaries where practical;
- focused unit and integration coverage;
- a review of the final diff in repository context;
- a proof packet listing changes, commands, outcomes, limits, and next action.
Route
Use the focused skills in this order. Skip a stage only when its artifact already exists and is adequate.
shape-spec: resolve the outcome, constraints, examples, non-goals, and verification plan.architect-change: record meaningful boundaries, alternatives, migration, observability, and rollback. For a trivial change, record “no architecture decision required” with a reason.map-work: produce thin vertical tasks with explicit dependencies and proof requirements.build-vertical-slice: implement one end-to-end user path with test-first evidence.trace-bug: invoke only when observed behavior diverges from the acceptance example or a test fails unexpectedly.review-change: inspect the complete diff and its context, then resolve critical findings.
Do not paste all supporting skills into context at once. Load each when its stage begins and preserve only its handoff artifact.
Risk-priced autonomy
Discover repository facts without asking. Proceed with reversible, in-scope local work. Ask one concrete question when a product choice changes user behavior, data ownership, security, or public presentation. Pause for destructive actions, external writes, credentials, access challenges, or scope expansion.
Handoff ledger
Maintain .workshop/journeys/<slug>/ledger.md:
# <journey>
## Outcome
## Stage ledger
| Stage | Artifact | Decision | Verification | Status |
| --- | --- | --- | --- | --- |
## Acceptance evidence
## Limits
## Next action
Status values are pending, passed, failed, blocked, or skipped-with-reason.
Stop rules
- Stop implementation when the product outcome is materially ambiguous.
- Stop release claims when an acceptance path cannot be exercised.
- Never substitute mocked success for a real boundary without labeling it.
- Never call the result production-ready unless deployment, observability, rollback, security, and accessibility evidence support that claim.
Final response
Lead with the shipped user outcome. Link the spec, ledger, important diff, and acceptance evidence. List exact verification commands and outcomes. State untested paths and why. Recommend one next action only when it adds value.
1---2name: idea-to-production3description: Turn an ambiguous software idea into one verified, review-ready vertical slice by composing specification, architecture, planning, TDD implementation, debugging, and review. Use for end-to-end feature delivery or “build this” requests. Do not use for a narrow bug, review-only request, or research-only task.4license: Apache-2.05---67# Idea to Production89Deliver the smallest user-visible slice that proves the idea, with evidence at every handoff.1011## Definition of done1213The journey is complete only when it has:1415- an approved or safely inferred specification with explicit non-goals;16- an architecture decision proportional to the change;17- a dependency-aware work map;18- an end-to-end reproduction or acceptance test that initially fails;19- a working vertical slice using real boundaries where practical;20- focused unit and integration coverage;21- a review of the final diff in repository context;22- a proof packet listing changes, commands, outcomes, limits, and next action.2324## Route2526Use the focused skills in this order. Skip a stage only when its artifact already exists and is adequate.27281. `shape-spec`: resolve the outcome, constraints, examples, non-goals, and verification plan.292. `architect-change`: record meaningful boundaries, alternatives, migration, observability, and rollback. For a trivial change, record “no architecture decision required” with a reason.303. `map-work`: produce thin vertical tasks with explicit dependencies and proof requirements.314. `build-vertical-slice`: implement one end-to-end user path with test-first evidence.325. `trace-bug`: invoke only when observed behavior diverges from the acceptance example or a test fails unexpectedly.336. `review-change`: inspect the complete diff and its context, then resolve critical findings.3435Do not paste all supporting skills into context at once. Load each when its stage begins and preserve only its handoff artifact.3637## Risk-priced autonomy3839Discover repository facts without asking. Proceed with reversible, in-scope local work. Ask one concrete question when a product choice changes user behavior, data ownership, security, or public presentation. Pause for destructive actions, external writes, credentials, access challenges, or scope expansion.4041## Handoff ledger4243Maintain `.workshop/journeys/<slug>/ledger.md`:4445```markdown46# <journey>4748## Outcome49## Stage ledger50| Stage | Artifact | Decision | Verification | Status |51| --- | --- | --- | --- | --- |52## Acceptance evidence53## Limits54## Next action55```5657Status values are `pending`, `passed`, `failed`, `blocked`, or `skipped-with-reason`.5859## Stop rules6061- Stop implementation when the product outcome is materially ambiguous.62- Stop release claims when an acceptance path cannot be exercised.63- Never substitute mocked success for a real boundary without labeling it.64- Never call the result production-ready unless deployment, observability, rollback, security, and accessibility evidence support that claim.6566## Final response6768Lead with the shipped user outcome. Link the spec, ledger, important diff, and acceptance evidence. List exact verification commands and outcomes. State untested paths and why. Recommend one next action only when it adds value.
leihuang23