From issue to production — every step, every gate, every artifact
0
Steps
0
Phases
0
Artifact Types
Five phases from problem to production
Frame
triage, frame
Shape
analyze*, spec
Build
plan, implement, pr
Verify
validate, review, fix*
Ship
promote*, cleanup*
* = conditional step (skipped based on tier or outcome)
Three tiers, one pipeline
≤3 files, no architecture, no risk
Clear scope, single domain
New architecture, unclear requirements, >2 domains
Skip Matrix
| triage | frame | analyze | spec | plan | implement | pr | validate | review | fix | promote | cleanup | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| S | skip | skip | skip | skip | cond | cond | cond | |||||
| F-lite | skip | skip | cond | cond | cond | |||||||
| F-full | skip | cond | cond | cond |
Key insight File count alone doesn't determine tier. A 50-file mechanical change may be S, while a 3-file rate limiter is F-full.
Define the problem
Goal
Categorize and assign the issue
Artifact
GitHub issue with size/priority labels
Gate
Issue exists with clear title and body
Goal
Define the problem, constraints, and scope
Artifact
artifacts/frames/{slug}.mdx
Gate
User approves frame
S-tier skips framing — goes straight to implement
Design the solution
Goal
Deep technical exploration — risks, alternatives, recommendations
Artifact
artifacts/analyses/{N}-{slug}.mdx
Gate
User approves analysis
Goal
Define what we'll build — acceptance criteria, breadboard, slices
Artifact
artifacts/specs/{N}-{slug}.mdx
Gate
User approves spec
F-lite skips analysis — frame is sufficient context for spec
Write the code
Goal
Break spec into tasks, pick agents, define order
Artifact
artifacts/plans/{N}-{slug}.mdx
Gate
User approves plan
Goal
Create worktree, spawn agents, write code
Test-first: RED → GREEN → REFACTOR
Goal
Package work for review
$ gh pr create --base staging
Agent Routing
Frontend
frontend-dev
Backend
backend-dev
CI/CD
devops
Tests
tester
Docs
doc-writer
Test-first: tester writes failing tests, then domain agents implement
Review and fix
Goal
Run all quality gates
Goal
Fresh agents review code they didn't write
No agent reviews code it wrote
Goal
Apply accepted review findings
Auto-apply → /1b1 walkthrough → domain fixers
Fresh agents = no implementation bias
Release and clean up
Goal
Merge staging → main with version bump and changelog
Standalone via /promote — not auto-triggered by /dev
Goal
Remove stale worktrees and branches
$ git worktree remove
$ branch deletion
Promotion batches all staging changes into one release
Artifacts persist — sessions don't have to
Session dies → restart → same progress
Artifact Types
frame
What's the problem?
artifacts/frames/
analysis
How deep is it?
artifacts/analyses/
spec
What will we build?
artifacts/specs/
plan
How do we build it?
artifacts/plans/
Every phase transition requires your approval
Frame
Shape
Build
Verify
Ship
Structured Choices
Every choice presented as structured options — never plain-text questions
Clear Roles
Human decides, Claude orchestrates, agents specialize
Human-in-the-Loop
Not fully autonomous — intentionally human-in-the-loop
Automated Quality Gates
pre-commit
Biome lint + format
commit-msg
Commitlint conventional
pre-push
lint + typecheck + tests + i18n
Git hooks and Claude Code hooks enforce quality at every step — no human action needed
Git Hooks (Lefthook)
Triggered by git operations — block bad code before it reaches the repo
pre-commitBiome check — lint + format every staged file
commit-msgCommitlint — enforce conventional commit format
pre-pushFull suite — lint, typecheck, tests, i18n validation, license check
Claude Code Hooks
Triggered by tool use — enforce patterns during AI-assisted development
PostToolUseAuto-format files after every Write/Edit with Biome
PreToolUseBlock 'bun test' (must use 'bun run test'), warn on sensitive file access
Key insight: Hooks run automatically — they don't require human attention. They catch mistakes before they compound.
Formal notation rewrite for skills and agents
## Step 1 — Parse Input First, look at the arguments. If an issue number is provided (like #42), fetch the GitHub issue using the gh CLI tool to get the title and body. If the issue does not exist, stop execution and inform the user that the issue was not found. If free text is provided instead of an issue number, search for matching issues using the gh issue list command with the search parameter. If a matching issue is found, ask the user if they want to use it. If not, create a new issue or proceed without one.
## S0 — Parse
#N ⇒ `gh issue view N --json title,body`
¬∃ issue ⇒ halt
Free text ⇒ `gh issue list --search "{text}"`
∃ match ⇒ AskUserQuestion: Use #{N} | Create | Skip## Step 1 — Parse Input First, look at the arguments. If an issue number is provided (like #42), fetch the GitHub issue using the gh CLI tool to get the title and body. If the issue does not exist, stop execution and inform the user that the issue was not found. If free text is provided instead of an issue number, search for matching issues using the gh issue list command with the search parameter. If a matching issue is found, ask the user if they want to use it. If not, create a new issue or proceed without one.
Every skill and agent in this project is compressed
Explore the Docs
Full guides and standards
Fork the Repo
Start from a proven foundation
Try /dev #1
One command to start the full lifecycle
We use cookies to improve your experience. You can accept all, reject all, or customize your preferences.