subagent-driven-development

Name: subagent-driven-development
Author: heymegabyte

18stars4forks

How to install subagent-driven-development?

heymegabyte/claude-skills/subagent-driven-development

$npx -y skills add heymegabyte/claude-skills --skill subagent-driven-development

Installs into the current project.

Summary

Use when executing implementation plans with independent tasks in the current session

Files · 1

View on GitHub

SKILL.md

1	# Subagent-Driven Development
2
3	Execute a plan in ONE session: dispatch a fresh implementer subagent per task → task review (spec + quality) after each → broad whole-branch review at the end. Upstream: <https://github.com/obra/superpowers>.
4
5	Fresh-context briefs, fan-out width, and the per-task economy are governed by `[[parallel-subagent-economy]]`; when to decompose-and-fan-out at all by `[[monitor-orchestration]]`. This file covers only what is SDD-specific: the per-task implementer + two-stage review loop.
6
7	## Contents
8
9	1. When to use vs. alternatives
10	2. The per-task loop
11	3. Model selection
12	4. Handling implementer status
13	5. Constructing reviewer prompts
14	6. File handoffs + durable ledger
15	7. Red flags
16
17	## When to Use
18
19	- Have a plan + tasks mostly independent + staying in THIS session → this skill.
20	- Want a parallel session with human checkpoints → `superpowers:executing-plans` instead.
21	- Tightly-coupled tasks or no plan → brainstorm/manual first.
22	- Continuous execution: do not check in between tasks. Stop only on unresolvable BLOCKED, genuine ambiguity, or all-done. Narrate ≤1 line between tool calls — the ledger and tool results are the record.
23
24	## The Per-Task Loop
25
26	1. Read plan once; note global constraints; create todos + check the ledger (§6).
27	2. Pre-flight: scan the plan for tasks that contradict each other/the constraints, or that mandate something the rubric treats as a defect (test asserting nothing, verbatim-duplicated logic). Batch all findings to the human as one question before Task 1; if clean, proceed silently.
28	3. Per task: `scripts/task-brief PLAN N` → dispatch implementer (`implementer-prompt.md`). Answer its questions before it proceeds.
29	4. On DONE: `scripts/review-package BASE HEAD` → dispatch task reviewer (`task-reviewer-prompt.md`) with the printed path.
30	5. Reviewer returns two verdicts (spec + quality). Critical/Important findings → fix subagent → re-review. Loop until both clean.
31	6. Mark complete in todos + ledger. Next task.
32	7. After all tasks: final whole-branch review via `../requesting-code-review/code-reviewer.md`, then `superpowers:finishing-a-development-branch`.
33
34	## Model Selection
35
36	Least-powerful model that handles the role. Always specify model explicitly — an omitted model inherits the session's (most expensive) model and defeats this.
37
38	- Plan text contains the complete code → transcription → cheapest tier.
39	- Single-file mechanical fix, complete spec → cheap.
40	- Multi-file integration / pattern-matching / debugging → standard (mid-tier is the floor for reviewers and prose-spec implementers).
41	- Design judgment / broad codebase understanding → most capable. The final whole-branch review is always this tier.
42	- Reviewer model scales to the diff's size/risk, not the session default.
43	- Turn count beats token price: cheapest models take 2-3× the turns on multi-step work, costing more overall.
44
45	## Handling Implementer Status
46
47	- DONE → generate review package, dispatch reviewer.
48	- DONE_WITH_CONCERNS → read concerns first. Correctness/scope → resolve before review; observations → note and proceed.
49	- NEEDS_CONTEXT → provide the missing info, re-dispatch.
50	- BLOCKED → diagnose: context gap → re-dispatch same model with more context; needs reasoning → more capable model; too large → split; plan is wrong → escalate to human. Never retry the same model unchanged; never ignore an escalation.
51
52	Reviewer ⚠️ "cannot verify from diff" items — requirements in unchanged code or spanning tasks. Non-blocking for the rest of the review, but YOU resolve each before marking complete (you hold the cross-task context the reviewer lacks). A confirmed gap = failed spec review → back to implementer.
53
54	## Constructing Reviewer Prompts
55
56	Per-task reviews are task-scoped gates; the broad review runs once at the end.
57
58	1. Never pre-judge. No "do not flag X", "at most Minor", "the plan chose this". If you're tempted to spare yourself a loop, stop — let the reviewer raise it and adjudicate in the loop. The plan's example code is a starting point, not proof its weaknesses were chosen.
59	2. BASE is the commit recorded before dispatching the implementer — never `HEAD~1` (drops all but the last commit of a multi-commit task).
60	3. Global-constraints block = the reviewer's attention lens. Copy binding requirements verbatim from the plan: exact values, formats, stated relationships ("same layout as X"). Process rules (YAGNI, test hygiene) are already in the template.
61	4. No open-ended directives ("check all uses", "run race tests if useful") without a concrete task-specific reason. Don't ask it to re-run tests the implementer already ran on the same code.
62	5. Plan-mandated findings (or any finding conflicting with plan text) → the human decides: present finding + plan text, ask which governs. Don't dismiss it; don't dispatch a contradicting fix without ask

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

subagent-driven-development

18stars4forks

View on GitHub

How to install subagent-driven-development?

heymegabyte/claude-skills/subagent-driven-development

$npx -y skills add heymegabyte/claude-skills --skill subagent-driven-development

Installs into the current project.

Summary

Use when executing implementation plans with independent tasks in the current session

Files · 1

View on GitHub

SKILL.md

1	# Subagent-Driven Development
2
3	Execute a plan in ONE session: dispatch a fresh implementer subagent per task → task review (spec + quality) after each → broad whole-branch review at the end. Upstream: <https://github.com/obra/superpowers>.
4
5	Fresh-context briefs, fan-out width, and the per-task economy are governed by `[[parallel-subagent-economy]]`; when to decompose-and-fan-out at all by `[[monitor-orchestration]]`. This file covers only what is SDD-specific: the per-task implementer + two-stage review loop.
6
7	## Contents
8
9	1. When to use vs. alternatives
10	2. The per-task loop
11	3. Model selection
12	4. Handling implementer status
13	5. Constructing reviewer prompts
14	6. File handoffs + durable ledger
15	7. Red flags
16
17	## When to Use
18
19	- Have a plan + tasks mostly independent + staying in THIS session → this skill.
20	- Want a parallel session with human checkpoints → `superpowers:executing-plans` instead.
21	- Tightly-coupled tasks or no plan → brainstorm/manual first.
22	- Continuous execution: do not check in between tasks. Stop only on unresolvable BLOCKED, genuine ambiguity, or all-done. Narrate ≤1 line between tool calls — the ledger and tool results are the record.
23
24	## The Per-Task Loop
25
26	1. Read plan once; note global constraints; create todos + check the ledger (§6).
27	2. Pre-flight: scan the plan for tasks that contradict each other/the constraints, or that mandate something the rubric treats as a defect (test asserting nothing, verbatim-duplicated logic). Batch all findings to the human as one question before Task 1; if clean, proceed silently.
28	3. Per task: `scripts/task-brief PLAN N` → dispatch implementer (`implementer-prompt.md`). Answer its questions before it proceeds.
29	4. On DONE: `scripts/review-package BASE HEAD` → dispatch task reviewer (`task-reviewer-prompt.md`) with the printed path.
30	5. Reviewer returns two verdicts (spec + quality). Critical/Important findings → fix subagent → re-review. Loop until both clean.
31	6. Mark complete in todos + ledger. Next task.
32	7. After all tasks: final whole-branch review via `../requesting-code-review/code-reviewer.md`, then `superpowers:finishing-a-development-branch`.
33
34	## Model Selection
35
36	Least-powerful model that handles the role. Always specify model explicitly — an omitted model inherits the session's (most expensive) model and defeats this.
37
38	- Plan text contains the complete code → transcription → cheapest tier.
39	- Single-file mechanical fix, complete spec → cheap.
40	- Multi-file integration / pattern-matching / debugging → standard (mid-tier is the floor for reviewers and prose-spec implementers).
41	- Design judgment / broad codebase understanding → most capable. The final whole-branch review is always this tier.
42	- Reviewer model scales to the diff's size/risk, not the session default.
43	- Turn count beats token price: cheapest models take 2-3× the turns on multi-step work, costing more overall.
44
45	## Handling Implementer Status
46
47	- DONE → generate review package, dispatch reviewer.
48	- DONE_WITH_CONCERNS → read concerns first. Correctness/scope → resolve before review; observations → note and proceed.
49	- NEEDS_CONTEXT → provide the missing info, re-dispatch.
50	- BLOCKED → diagnose: context gap → re-dispatch same model with more context; needs reasoning → more capable model; too large → split; plan is wrong → escalate to human. Never retry the same model unchanged; never ignore an escalation.
51
52	Reviewer ⚠️ "cannot verify from diff" items — requirements in unchanged code or spanning tasks. Non-blocking for the rest of the review, but YOU resolve each before marking complete (you hold the cross-task context the reviewer lacks). A confirmed gap = failed spec review → back to implementer.
53
54	## Constructing Reviewer Prompts
55
56	Per-task reviews are task-scoped gates; the broad review runs once at the end.
57
58	1. Never pre-judge. No "do not flag X", "at most Minor", "the plan chose this". If you're tempted to spare yourself a loop, stop — let the reviewer raise it and adjudicate in the loop. The plan's example code is a starting point, not proof its weaknesses were chosen.
59	2. BASE is the commit recorded before dispatching the implementer — never `HEAD~1` (drops all but the last commit of a multi-commit task).
60	3. Global-constraints block = the reviewer's attention lens. Copy binding requirements verbatim from the plan: exact values, formats, stated relationships ("same layout as X"). Process rules (YAGNI, test hygiene) are already in the template.
61	4. No open-ended directives ("check all uses", "run race tests if useful") without a concrete task-specific reason. Don't ask it to re-run tests the implementer already ran on the same code.
62	5. Plan-mandated findings (or any finding conflicting with plan text) → the human decides: present finding + plan text, ask which governs. Don't dismiss it; don't dispatch a contradicting fix without ask

People who liked this also viewed

6 picks

Type