foxfitbehind-the-scenesai

PRDs and Sub-Agent Teams

Every feature gets two documents: a PRD defining what to build, and an implementation prompt defining how, complete with team roles the AI adopts.

We don’t just tell Claude Code “build feature X”. That approach produces inconsistent results. Instead, every feature goes through a structured design phase before any code gets written.

Document 1: The PRD

A Product Requirements Document detailing what we’re building, not how. It covers the problem we’re solving, the acceptance criteria that tell us when we’re done, the technical constraints we need to work within, and what we’re explicitly not building.

The PRD is technology-agnostic. It’s about the product not the process. This is the design step and it happens entirely in our heads, not the AI’s, but the AI can still help us build it.

Writing good PRDs is the most important thing we do. A vague PRD produces vague code. A precise PRD with clear acceptance criteria produces code that can be tested against something concrete. The discipline of writing down what “done” looks like before starting is what makes the rest of the process reliable.

Document 2: The Implementation Prompt

This is where we tell Claude Code how to build it. The interesting bit is that we ask it to work as a team, not a single agent:

ORCHESTRATOR (Claude Code)
    ├── TEAM A: iOS (swift-expert, code-simplifier, debugger)
    ├── TEAM B: Mac (swift-expert, code-simplifier, debugger)
    └── TEAM C: Testing (test-automator, debugger)
         ↓
    VALIDATION (product-manager)

These aren’t separate AI instances. They’re roles that Claude Code adopts as parallel subagent teams, each working on different aspects of the task. The swift-expert focuses on correct implementation. The code-simplifier reduces complexity, and the debugger looks for edge cases.

Parallel Work

Teams A and B work in parallel when there are no file conflicts. FoxFit runs on both iOS and Mac, but the platforms have different UI patterns. Having separate teams means platform-specific work doesn’t block on each other.

Team C writes tests after implementation. The product-manager role validates the final result against the PRD’s acceptance criteria.

Breaking work into roles forces more thorough thinking. A swift-expert might write working code that a code-simplifier then improves. A debugger might catch edge cases the expert missed.

← Back to all posts