coding-forge

Use this agent for general code quality review as part of the build-loop dual review gate. Checks correctness, error handling, security, concurrency, and performance. Read-only — never modifies code. <example> Context: Implementation passed build and test gates, ready for review user: "Review the Phase 2 changes for code quality issues" assistant: "Dispatching code-reviewer for general quality analysis." <commentary> This runs in parallel with the domain-specific reviewer. Both are read-only. </commentary> </example>

Use this agent to write implementation code that makes failing tests pass. Dispatched by the build-loop orchestrator after the test-writer step. <example> Context: Failing tests exist, orchestrator is ready for implementation user: "Implement the WebSocket reconnection logic to pass the failing tests" assistant: "Dispatching phase-implementer to write the minimal code needed." <commentary> The implementer writes just enough code to make the tests pass, nothing more. </commentary> </example>

Use this agent to explore codebase scope before implementing a build phase. Dispatched by the build-loop orchestrator to read files in scope and report what exists, what's broken, and what's missing. <example> Context: Orchestrator is starting Phase 2 of a build plan user: "Research the current state of the networking layer before we add WebSocket support" assistant: "I'll dispatch the phase-researcher to map out the existing networking code." <commentary> The orchestrator needs context on existing code before dispatching implementation agents. </commentary> </example> <example> Context: Orchestrator needs to understand types and interfaces before TDD user: "Read the auth module and report what types, protocols, and tests exist" assistant: "Dispatching phase-researcher to inventory the auth module." <commentary> Research findings feed directly into the test-writer and phase-implementer prompts. </commentary> </example>

Use this agent to write failing tests before implementation as part of the build-loop TDD cycle. Dispatched by the orchestrator after research completes. <example> Context: Research is done, orchestrator is ready for TDD step user: "Write failing tests for the WebSocket reconnection logic" assistant: "Dispatching test-writer to create tests that define the expected behavior." <commentary> Tests must be written before implementation code. They define the contract. </commentary> </example>

Orchestrate phased software implementation using sub-agents for research, TDD, coding, and dual code review — with hard gates between phases. Use when the user asks to "build this", "implement this feature", "build it phase by phase", "use the build loop", or has a spec/plan to execute incrementally. Do not use for single-file edits, quick bug fixes, or tasks with no build step.