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#

#PhaseRoleOutput1ThinkYC Office Hours CoachDESIGN.md2PlanEng ManagerPLAN.md3BuildImplementerCode + Tests4ReviewStaff EngineerReview Report5TestQA LeadBug Report + Fixes6ShipRelease EngineerPR / Deploy

How to Use#

Full Sprint (recommended for new features)#

bash

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

PhaseModelWhyThinkSonnetNeeds judgment to reframe problemsPlanSonnetArchitecture decisions need reasoningBuildHaiku/SonnetSimple features → Haiku, complex → SonnetReviewSonnetBug detection needs deep analysisTestSonnetBrowser interaction needs contextShipHaikuMechanical 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.