97 lines
3.8 KiB
Markdown
97 lines
3.8 KiB
Markdown
---
|
|
name: subagent-driven-development
|
|
description: Execute a plan by dispatching one coder task at a time with ordered spec and quality gates
|
|
permalink: opencode-config/skills/subagent-driven-development/skill
|
|
---
|
|
|
|
# Subagent-Driven Development
|
|
|
|
Use this skill to execute an existing plan from `plans/*` by delegating **one implementation task at a time** to a fresh `coder`, then running ordered quality gates before moving to the next task.
|
|
|
|
## Core Workflow Value
|
|
|
|
1. Dispatch a fresh `coder` for exactly one task.
|
|
2. Run **spec-compliance review first**.
|
|
3. Run **code-quality review second**.
|
|
4. Run `tester` functional validation for user-visible behavior.
|
|
5. Only then mark the task done and continue.
|
|
|
|
Do not run multiple coder implementations in parallel for the same branch/worktree.
|
|
|
|
## When to Use
|
|
|
|
Use when you already have a concrete plan note (usually under `plans/`) and want controlled, high-signal execution with clear review loops.
|
|
|
|
Prefer this over ad-hoc execution when tasks are independent enough to complete sequentially and verify individually.
|
|
|
|
## Execution Loop (Per Task)
|
|
|
|
1. **Load task from plan**
|
|
- Read `plans/<plan-note>` once.
|
|
- Extract the exact task text and acceptance criteria.
|
|
- Prepare any architectural/context notes the coder needs.
|
|
|
|
2. **Dispatch coder with full context (no rediscovery)**
|
|
- Paste the **full task text** directly into the coder delegation.
|
|
- Paste relevant context (paths, constraints, discovered values, dependencies).
|
|
- Do not ask coder to rediscover the plan.
|
|
|
|
3. **Handle coder status explicitly**
|
|
- `DONE`: proceed to spec-compliance review.
|
|
- `PARTIAL`: resolve stated gaps, then re-dispatch remaining scope.
|
|
- `BLOCKED`: unblock (context/scope/approach) before retrying.
|
|
|
|
4. **Reviewer pass 1 — spec compliance (required first)**
|
|
- `reviewer` checks implementation against task requirements only:
|
|
- missing requirements
|
|
- extra/unrequested scope
|
|
- requirement misinterpretations
|
|
- If issues exist, send fixes back to `coder`, then re-run this pass.
|
|
|
|
5. **Reviewer pass 2 — code quality (only after spec pass)**
|
|
- `reviewer` checks maintainability and correctness quality:
|
|
- clarity of structure/responsibilities
|
|
- consistency with local conventions
|
|
- risk hotspots and change quality
|
|
- If issues exist, send fixes to `coder`, then re-run this pass.
|
|
|
|
6. **Tester pass — functional verification**
|
|
- `tester` validates behavior through real execution paths per local quality pipeline.
|
|
- If tester fails, return to `coder`, then re-run reviewer/tester as needed.
|
|
|
|
7. **Record and continue**
|
|
- Update the relevant `plans/*` checklist/note with concise implementation outcomes.
|
|
- Move to the next task only when all gates for the current task pass.
|
|
|
|
## Dispatch Guidance
|
|
|
|
When delegating to `coder`, include:
|
|
|
|
- Task name and goal
|
|
- Full task text from the plan
|
|
- Exact constraints ("only this feature", target files, forbidden scope)
|
|
- Discovered values that must be used verbatim
|
|
- Required output format/status expectations
|
|
|
|
Keep delegations narrow. One coder dispatch should correspond to one task outcome.
|
|
|
|
## Red Flags
|
|
|
|
Never:
|
|
|
|
- skip spec-compliance review
|
|
- run code-quality review before spec-compliance passes
|
|
- mark a task done with open reviewer/tester findings
|
|
- make the coder re-read the entire plan for context already available
|
|
- batch multiple independent tasks into one coder implementation dispatch
|
|
|
|
## Local Integration
|
|
|
|
- Plan source of truth: basic-memory notes under `plans/`
|
|
- Implementation agent: `coder`
|
|
- Review agent: `reviewer` (spec pass, then quality pass)
|
|
- Functional validation agent: `tester`
|
|
- Overall gate order: `coder` → `reviewer(spec)` → `reviewer(quality)` → `tester`
|
|
|
|
This skill complements the repository's mandatory review/test pipeline by enforcing per-task execution discipline and ordered review loops.
|