Claude Code/build-featureCodex$build-feature
Planning, agents, implementation, and local model building
Local building with Qwen 3.8 27B
The same workflow runs in both environments. Start it with the command for your tool.
I turn an idea into a clear plan, then direct AI workers through small, verified phases. You help shape the result before the build starts; written decisions and checks keep the work reviewable as it grows.
- UnderstandRead the code and agree the need.
- PlanSet scope, design, and checks.
- BuildFresh workers; routine checks in every build.
- ReviewOptional team reviews at milestones.
- ValidateCompare the result with the plan.
Planning with the user
build-feature is an agent skill: written instructions that guide the AI through planning and implementation. It replaces my earlier RPK workflow. I remain the agent director — the person setting direction, making engineering judgments, and taking responsibility for the result. An agent is an AI worker with a bounded task.
Planning begins with the existing code and documentation. We work through one question at a time, settle what belongs in the feature and what stays out, and agree the design of any screens. Likely implementation questions get answered before work starts.
The output is one phased feature plan and a start prompt for the build. A phase is a bounded part of the feature with a clear outcome and verification checks. Planning also creates or updates project memory; it does not launch the build.
Project memory is written into the repository, shared with The Loop, and available to a fresh agent without the previous chat. Existing glossary and decision-record locations remain authoritative. The usual map is:
.docs/PROJECT.mdProject rules and verified facts..docs/CONTEXT.mdThe language and meanings used by the project..docs/adr/Decision records: what was decided and why..docs/features/NNN-slug/plan.mdThe feature plan, phase status, verification evidence, blockers, and next safe action.
How the agents work
Implementation starts in a separate manager session. It asks “Do you want to ask any questions?” and waits for an explicit go. After that, it coordinates the agreed build and records decisions without returning for routine questions.
The manager orchestrates rather than writing feature code. Through the runner, it starts a fresh command-line session for each phase worker, reviewer, fixer, and screen checker. Each reads the plan and project memory, does its assigned job, writes down the result, and stops. Workers do not start or manage other workers.
- The manager assigns one phase on feature/NNN-slug. The worker builds only that phase and runs its named checks.
- Progress, evidence, and questions go back into files. The manager inspects the actual changes and verifies the result, with separate screen checks for changed screens.
- Any required fixes are checked before the manager makes one verified commit and tag for the phase. Then a fresh worker takes the next phase.
Fresh workers reduce accumulated context; they do not guarantee correctness. Hard decisions go to a stronger decider. Unsafe work, missing required tools, or repeated failures can stop the build with the blocker recorded.
Who does what
Roles explain the division of work. Model names below are the configured seats in this workflow, rather than general recommendations for every project.
- Planner Works with the person to settle the feature, design, and phased plan.
- Manager Assigns bounded jobs, checks results, maintains progress, and commits verified phases.
- Builder Implements the assigned phase; a fixer handles a bounded repair.
- Decider Resolves difficult worker questions within the agreed scope.
- Reviewers and screen checker Independently inspect code, risks, behavior, and screens within their assigned roles.
| Role | Claude Code | Codex | Local builder |
|---|---|---|---|
| Planner | Opus or Fable | Current session model, usually Astra | — |
| Manager | Sonnet | Sol (gpt-6.1-sol) | — |
| Builder / fixer | Sonnet 5.5 (sonnet) | Sol (gpt-6.1-sol; sol) | Qwen (qwen3.8:27b-mlx; qwen) for builder work |
| Decider | Opus | Astra (gpt-6-astra) | — |
| Code / Security reviewers | Opus | Astra (gpt-6-astra) | — |
| QA / UX reviewers | Sonnet | Sol (gpt-6.1-sol) | — |
| Screen checker | Sonnet | Sol (gpt-6.1-sol) | — |
The manager family follows the planning host: Claude Code uses the Claude seats; Codex uses the Codex seats. Choosing a builder does not change that family.
Qwen performs builder work locally through Claude Code and the existing local setup, under either manager family. Its phases are smaller. Management and optional reviews still use the selected cloud family, so this is not a fully local pipeline. Qwen does not perform independent reviews or browser screen checks.
Independent reviews
Team mode adds optional reviewers at milestones; phase workers still build in sequence. The standard roles are Code Reviewer, Security, and QA, with UX for screens. A Requirements Reviewer joins only when an ambiguity has been identified. Security reviews the written plan before the build starts.
Code readers may work at the same time. QA and UX use the running app one at a time so their checks do not interfere. Findings go back through bounded fixes and verification before a phase is committed.
Routine checks apply to every build, whether team mode is enabled or not. Review limitations and unresolved findings remain visible in the reports; a blocked review is not a successful review.
What comes back
Final check runs on the finished code after fixes. Validation then compares the result with the phase goals, agreed design, and decisions, and updates project memory to reflect what was actually built. Full-test ownership follows the project’s rules and any later merge gate.
The morning report records results, choices, answers, deviations, and work left undone, including checks that could not run. The plan keeps the execution state and evidence so another session can resume safely.
BuildBoard shows registered builds, and a live progress log lets me follow agent work. These are outputs of the workflow described here. The workflow does not automatically push, merge, or deploy; those remain separate release actions.
Practical examples
These illustrative planning requests choose a builder. Add team to opt into milestone reviews. They produce a plan and handoff prompt before implementation begins.
/build-feature sonnet
Add a contact page with clear success and error states./build-feature qwen team
Add a searchable project list using the existing site styles.$build-feature sol
Explain the development workflow on the existing website.In Claude Code, switch to Sonnet and clear the conversation before pasting the generated start prompt. In Codex, select Sol in your current interface, start a fresh conversation or context, and paste the generated prompt. No separate terminal launch is required. The manager checks the plan, asks the initial question, and waits for go.
A small phase states both the outcome and how to prove it. This example is illustrative, rather than a record of a running build:
### Contact page
Done when: a visitor can submit a valid message
and understands success or failure.
Verify with: validation checks, the production build,
and desktop/mobile checks of both outcomes.