---
name: idea-to-production
description: 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.
license: Apache-2.0
metadata:
  compatibility: Codex, Kimi Code, and Grok Build; requires filesystem and shell access for implementation.
  author: Lei Huang
  version: "0.1.0"
  status: experimental
---

# 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.

1. `shape-spec`: resolve the outcome, constraints, examples, non-goals, and verification plan.
2. `architect-change`: record meaningful boundaries, alternatives, migration, observability, and rollback. For a trivial change, record “no architecture decision required” with a reason.
3. `map-work`: produce thin vertical tasks with explicit dependencies and proof requirements.
4. `build-vertical-slice`: implement one end-to-end user path with test-first evidence.
5. `trace-bug`: invoke only when observed behavior diverges from the acceptance example or a test fails unexpectedly.
6. `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`:

```markdown
# <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.