- name
- dev-workflow
- description
- Structured development workflow inspired by Garry Tan's gstack. Use when the user wants to build a feature, start a project, do a code review, or ship code with a disciplined Think → Plan → Build → Review → Test → Ship process. Triggers on phrases like "start a project", "build a feature", "dev workflow", "ship code", "code review workflow", "plan and build", "structured development". Also useful when the user wants to run a disciplined development process with role-based subagents for analysis, design, review, QA, and release.
Dev Workflow — Structured Development Sprint
A 6-phase development process that turns a vague idea into shipped code. Each phase has a clear role, a defined output, and feeds into the next. Run phases sequentially or skip ahead when context is clear.
Phases
| # | Phase | Role | Output |
|---|---|---|---|
| 1 | Think | YC Office Hours Coach | DESIGN.md |
| 2 | Plan | Eng Manager | PLAN.md |
| 3 | Build | Implementer | Code + Tests |
| 4 | Review | Staff Engineer | Review Report |
| 5 | Test | QA Lead | Bug Report + Fixes |
| 6 | Ship | Release Engineer | PR / Deploy |
How to Use
Full Sprint (recommended for new features)
# Start from scratch
"I want to build X" → run all 6 phases
# Or ask me:
"Run dev-workflow on [feature description]"I will walk through each phase, spawning a focused subagent per phase with the right model and prompt.
Partial Sprint
Skip phases when you already have context:
- "Skip think, I have DESIGN.md" → start from Plan
- "Just review and ship this branch" → run Review → Test → Ship
- "I need a design review" → run Phase 2 (Plan) only
Single Phase
Any phase can run standalone:
/think— Reframe the problem, challenge assumptions, write DESIGN.md/plan— Architecture, data flow, test strategy, write PLAN.md/build— Implement from PLAN.md/review— Code review with auto-fix for obvious issues/test— Browser testing, regression tests, bug reports/ship— Sync, test, push, open PR
Phase Details
Phase 1: Think (YC Office Hours)
Goal: Reframe the problem before writing code.
Spawn a subagent (Sonnet) with the Think prompt from references/prompts.md. It will:
- Ask 6 forcing questions about the real pain, not the feature request
- Challenge the framing — "You said X but you actually need Y"
- Generate 3 implementation approaches with effort estimates
- Recommend the narrowest wedge to ship tomorrow
- Write
DESIGN.mdwith the distilled product vision
Key rule: Listen to the pain, not the feature request. The user says "daily briefing app" but means "personal chief of staff AI."
Phase 2: Plan (Eng Manager)
Goal: Lock architecture before building.
Spawn a subagent (Sonnet) with the Plan prompt. It reads DESIGN.md and produces PLAN.md containing:
- Architecture diagram (ASCII)
- Data flow and state machines
- File structure and module boundaries
- Test strategy and failure modes
- Milestone breakdown (what ships first)
Key rule: No code until the plan is approved. Challenge scope ruthlessly.
Phase 3: Build (Implementer)
Goal: Write code from PLAN.md.
Use the main session or spawn a subagent (Haiku for simple, Sonnet for complex). It reads PLAN.md and:
- Implements each milestone in order
- Writes tests alongside code (aim for >80% coverage)
- Commits atomically per milestone
- Updates PLAN.md with implementation notes
Key rule: Follow the plan. If the plan is wrong, update PLAN.md first, then code.
Phase 4: Review (Staff Engineer)
Goal: Find bugs that pass CI but blow up in production.
Spawn a subagent (Sonnet) with the Review prompt. It:
- Reads the diff against main/develop
- Catches logic errors, race conditions, edge cases
- Auto-fixes obvious issues (formatting, unused imports)
- Flags completeness gaps and security concerns
- Writes a review report
Key rule: Be paranoid. Assume the code will be hit by edge cases tomorrow.
Phase 5: Test (QA Lead)
Goal: Test like a user, not like a developer.
Spawn a subagent (Sonnet) with the Test prompt. It:
- Opens the app in a real browser (use
browsertool) - Clicks through every user flow
- Tests edge cases and error states
- Reports bugs with reproduction steps
- Auto-fixes and generates regression tests
Key rule: The user doesn't read code. Click the buttons. Break things.
Phase 6: Ship (Release Engineer)
Goal: One command to production.
Run in main session:
- Sync with remote (git pull/rebase)
- Run full test suite
- Audit test coverage
- Push and open PR
- Update project docs
Key rule: If tests fail, don't ship. Fix first.
Model Selection
| Phase | Model | Why |
|---|---|---|
| Think | Sonnet | Needs judgment to reframe problems |
| Plan | Sonnet | Architecture decisions need reasoning |
| Build | Haiku/Sonnet | Simple features → Haiku, complex → Sonnet |
| Review | Sonnet | Bug detection needs deep analysis |
| Test | Sonnet | Browser interaction needs context |
| Ship | Haiku | Mechanical execution |
Parallel Sprints
For large projects, run multiple sprints on different branches:
- Create feature branches for each sprint
- Spawn subagents per branch
- Each subagent works in isolation
- Review and merge sequentially
Max practical parallelism: 3-5 sprints (limited by context management).
Output Files
All phase outputs go to the project root:
DESIGN.md— Product vision from Think phasePLAN.md— Architecture and milestones from Plan phase- Review reports are written to stdout (capture in conversation)
- Test reports are written to stdout
Clean up output files after shipping if not needed long-term.