Implement With Subagents

Implement with subagents

Use this workflow whenever a delivery lead coordinates settled implementation tasks, including one task and sequential work. Assign one worker per supplied work item; do not split a single task into artificial pieces. Reuse a bounded pool of worker checkouts. The lead validates the task graph, dispatches the independent ready frontier with disjoint write sets by default, accepts each task once before integration, and integrates accepted commits in dependency order. After an ordinary integration, rerun affected checks and release dependents without a second lead sign-off. Retire eligible surplus checkouts, preserve task refs, and account for checkout dispositions at completion or interruption. Keep the lead out of task-owned code and return implementation repairs to the original worker.

Select the mode

• Use review only to assess supplied orchestration without running it.
• Use implement only to execute supplied tickets or plan tasks. This mode does not invoke the separate /implement skill.

Check implementation prerequisites

Review mode has no external dependency. For implementation, identify the behavior-changing items and their user-approved test seams before delegation. Their owners use the separately installed tdd skill directly. If a behavior item has no approved seam, obtain agreement before dispatch; if tdd is unavailable, stop before dispatching that item. Documentation and other items without a meaningful test seam use focused validation instead. Never install a dependency implicitly.

Resolve one independent read-only reviewer before delegation. Use a fresh investigator in review mode (or an equivalent runtime role) with a self-contained brief: approved source, plan, repository standards, fixed base, and exact candidate head. Do not inherit the implementation conversation. Require findings with evidence and a ship, fix-first, or rethink verdict against both requirements and standards, with the coverage account under Behavioral review and repair. Apply that reference during implementation for related boundary repairs and browser failure diagnostics; PR feedback remains outside this workflow. No external review skill or tracker setup is required. If independent review cannot run, report the missing capability; never waive final review. Add reviewers only for distinct risks or substantial scope that justify separate assignments.

Review procedure

1. Inspect only permitted repository and orchestration state. Do not start an agent, edit, commit, change branches, perform worktree lifecycle operations, or contact a remote service.
2. Assess the task graph, safe concurrency, implementation ownership, task-scoped commits, owner self-review, focused validation, and controller acceptance before integration. An owner's report alone does not satisfy task acceptance. Separate worktrees do not make shared-file edits or work depending on unintegrated code independent. Check reuse-first allocation, distinct slots for active writers, and existing-checkout access for read-only helpers.
3. Check that each prerequisite is integrated and its affected validation passes at that exact head before releasing a dependent. A passing task branch is insufficient when integration changes relevant inputs. Do not require a second discretionary lead acceptance after an ordinary merge; inspect the joined diff when cross-file interactions, changed shared interfaces, or merge resolutions can change meaning. Reuse passing checks only when their inputs and environment remain unchanged. An accepted item is complete, not assignable again.
4. Report the next action, evidence, and any acceptance gap. Stop before implementation. Check release eligibility, safe retirement, and checkout dispositions without mutating them. For an invalid dependency graph, hold dispatch and return the specific defects to the plan owner; do not invent or remove tasks or dependencies. Name any affected check that must be rerun at the integrated head, even when another blocker also prevents dispatch.