dev-workflow

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:

1. Ask 6 forcing questions about the real pain, not the feature request
2. Challenge the framing — "You said X but you actually need Y"
3. Generate 3 implementation approaches with effort estimates
4. Recommend the narrowest wedge to ship tomorrow
5. Write DESIGN.md with 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:

1. Architecture diagram (ASCII)
2. Data flow and state machines
3. File structure and module boundaries
4. Test strategy and failure modes
5. 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:

1. Implements each milestone in order
2. Writes tests alongside code (aim for >80% coverage)
3. Commits atomically per milestone
4. 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:

1. Reads the diff against main/develop
2. Catches logic errors, race conditions, edge cases
3. Auto-fixes obvious issues (formatting, unused imports)
4. Flags completeness gaps and security concerns
5. 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:

1. Opens the app in a real browser (use browser tool)
2. Clicks through every user flow
3. Tests edge cases and error states
4. Reports bugs with reproduction steps
5. 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:

1. Sync with remote (git pull/rebase)
2. Run full test suite
3. Audit test coverage
4. Push and open PR
5. 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:

1. Create feature branches for each sprint
2. Spawn subagents per branch
3. Each subagent works in isolation
4. 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 phase
• PLAN.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.