subagent-driven-development

Name: subagent-driven-development
Author: krzysztofsurdy

19installs1forks

How to install subagent-driven-development?

krzysztofsurdy/code-virtuoso/subagent-driven-development

$npx -y skills add krzysztofsurdy/code-virtuoso --skill subagent-driven-development

Installs into the current project.

Summary

Execute a multi-task implementation plan by dispatching one fresh subagent per task with isolated context, then applying a two-stage review (spec compliance and code quality) before advancing. Use when you have a written plan with 3+ tasks, when tasks would otherwise cause contex

Files · 1

View on GitHub

SKILL.md

1	# Subagent-Driven Development
2
3	An orchestration pattern for executing multi-task implementation plans by dispatching one fresh subagent per task, reviewing each task through two gates (spec compliance, then code quality), and advancing only after both gates pass. The orchestrator stays lean - it coordinates, briefs, reviews, and hands off. It never implements.
4
5	## Core Principles
6
7	\| Principle \| Meaning \|
8	\|---\|---\|
9	\| One fresh agent per task \| Each task gets a new subagent with curated context. No inherited conversation history, no accumulated drift. The agent sees only what the brief provides. \|
10	\| Two-stage review \| Every task passes through spec compliance (does it match the brief?) and then code quality (is it correct, clean, and tested?). Both must pass before advancing. \|
11	\| Structured hand-offs \| When task N produces artifacts that task N+1 needs, pass a compressed summary (diff, test manifest, notes) - never raw conversation history. \|
12	\| Orchestrator stays lean \| The orchestrator reads the plan, dispatches agents, reviews output, and decides next steps. It does not implement, debug, or accumulate working-memory bloat. \|
13	\| Fail fast, fix forward \| When a review gate fails, return specific feedback to the subagent for a focused fix cycle. After two failed fix attempts, re-scope or escalate - do not loop indefinitely. \|
14
15	## When to Use
16
17	\| Situation \| Why this pattern fits \|
18	\|---\|---\|
19	\| Written plan with 3+ sequential tasks \| Each task benefits from isolated execution and a review checkpoint \|
20	\| Tasks that build on each other (feature branches, migrations) \| Structured hand-offs prevent context corruption between steps \|
21	\| Long implementation sessions that risk context exhaustion \| Fresh agents per task keep each execution window small and precise \|
22	\| Quality-sensitive work requiring audit trails \| Two-stage review produces documented accept/reject decisions per task \|
23	\| Delegating to less capable models for mechanical work \| Tight briefs and review gates compensate for reduced reasoning capacity \|
24
25	## When NOT to Use
26
27	\| Situation \| Better alternative \|
28	\|---\|---\|
29	\| Single task or trivial change \| Direct execution - the overhead of briefing and review is not justified \|
30	\| Fully independent tasks with no ordering dependency \| `dispatching-parallel-agents` - fan them out simultaneously \|
31	\| Exploratory or research work with unclear scope \| Manual iteration - you need to discover the shape before you can brief it \|
32	\| Tasks that require deep shared state across every step \| Single long-running session with periodic checkpoints \|
33	\| Fewer than 3 tasks \| Execute directly and self-review - the ceremony exceeds the value \|
34
35	## The Loop
36
37	Execute one task at a time through this seven-phase cycle. The orchestrator drives each phase.
38
39	### Phase 1: Brief the Subagent
40
41	Compose a task brief containing everything the subagent needs to execute independently. The brief is the subagent's entire world - anything not in the brief does not exist for it.
42
43	Include:
44	- Task identifier and goal (one sentence)
45	- Input artifacts (file paths, interface signatures, test fixtures)
46	- Context from prior tasks (hand-off summary, not full history)
47	- Acceptance criteria (observable, testable conditions)
48	- Out-of-scope boundaries (what the agent must NOT touch)
49	- Failure handling instructions (what to do when stuck)
50
51	See [Task Brief Template](references/task-brief-template.md) for the full structure.
52
53	### Phase 2: Dispatch with Isolation
54
55	Launch the subagent with a fresh context window. Provide the brief as the initial prompt. If the platform supports worktree isolation, use it - the subagent should not be able to corrupt the main working tree.
56
57	Key rules:
58	- Never paste the full plan into the subagent - only the current task brief
59	- Never let the subagent inherit the orchestrator's conversation history
60	- Preload only the skills the subagent needs for this specific task
61
62	### Phase 3: Receive Artifacts
63
64	The subagent completes work and reports back with one of four statuses:
65
66	\| Status \| Orchestrator action \|
67	\|---\|---\|
68	\| Done \| Proceed to Stage 1 review \|
69	\| **Do

People who liked this also viewed

6 picks

Type

subagent-driven-development

19installs1forks

View on GitHub

How to install subagent-driven-development?

krzysztofsurdy/code-virtuoso/subagent-driven-development

$npx -y skills add krzysztofsurdy/code-virtuoso --skill subagent-driven-development

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Subagent-Driven Development
2
3	An orchestration pattern for executing multi-task implementation plans by dispatching one fresh subagent per task, reviewing each task through two gates (spec compliance, then code quality), and advancing only after both gates pass. The orchestrator stays lean - it coordinates, briefs, reviews, and hands off. It never implements.
4
5	## Core Principles
6
7	\| Principle \| Meaning \|
8	\|---\|---\|
9	\| One fresh agent per task \| Each task gets a new subagent with curated context. No inherited conversation history, no accumulated drift. The agent sees only what the brief provides. \|
10	\| Two-stage review \| Every task passes through spec compliance (does it match the brief?) and then code quality (is it correct, clean, and tested?). Both must pass before advancing. \|
11	\| Structured hand-offs \| When task N produces artifacts that task N+1 needs, pass a compressed summary (diff, test manifest, notes) - never raw conversation history. \|
12	\| Orchestrator stays lean \| The orchestrator reads the plan, dispatches agents, reviews output, and decides next steps. It does not implement, debug, or accumulate working-memory bloat. \|
13	\| Fail fast, fix forward \| When a review gate fails, return specific feedback to the subagent for a focused fix cycle. After two failed fix attempts, re-scope or escalate - do not loop indefinitely. \|
14
15	## When to Use
16
17	\| Situation \| Why this pattern fits \|
18	\|---\|---\|
19	\| Written plan with 3+ sequential tasks \| Each task benefits from isolated execution and a review checkpoint \|
20	\| Tasks that build on each other (feature branches, migrations) \| Structured hand-offs prevent context corruption between steps \|
21	\| Long implementation sessions that risk context exhaustion \| Fresh agents per task keep each execution window small and precise \|
22	\| Quality-sensitive work requiring audit trails \| Two-stage review produces documented accept/reject decisions per task \|
23	\| Delegating to less capable models for mechanical work \| Tight briefs and review gates compensate for reduced reasoning capacity \|
24
25	## When NOT to Use
26
27	\| Situation \| Better alternative \|
28	\|---\|---\|
29	\| Single task or trivial change \| Direct execution - the overhead of briefing and review is not justified \|
30	\| Fully independent tasks with no ordering dependency \| `dispatching-parallel-agents` - fan them out simultaneously \|
31	\| Exploratory or research work with unclear scope \| Manual iteration - you need to discover the shape before you can brief it \|
32	\| Tasks that require deep shared state across every step \| Single long-running session with periodic checkpoints \|
33	\| Fewer than 3 tasks \| Execute directly and self-review - the ceremony exceeds the value \|
34
35	## The Loop
36
37	Execute one task at a time through this seven-phase cycle. The orchestrator drives each phase.
38
39	### Phase 1: Brief the Subagent
40
41	Compose a task brief containing everything the subagent needs to execute independently. The brief is the subagent's entire world - anything not in the brief does not exist for it.
42
43	Include:
44	- Task identifier and goal (one sentence)
45	- Input artifacts (file paths, interface signatures, test fixtures)
46	- Context from prior tasks (hand-off summary, not full history)
47	- Acceptance criteria (observable, testable conditions)
48	- Out-of-scope boundaries (what the agent must NOT touch)
49	- Failure handling instructions (what to do when stuck)
50
51	See [Task Brief Template](references/task-brief-template.md) for the full structure.
52
53	### Phase 2: Dispatch with Isolation
54
55	Launch the subagent with a fresh context window. Provide the brief as the initial prompt. If the platform supports worktree isolation, use it - the subagent should not be able to corrupt the main working tree.
56
57	Key rules:
58	- Never paste the full plan into the subagent - only the current task brief
59	- Never let the subagent inherit the orchestrator's conversation history
60	- Preload only the skills the subagent needs for this specific task
61
62	### Phase 3: Receive Artifacts
63
64	The subagent completes work and reports back with one of four statuses:
65
66	\| Status \| Orchestrator action \|
67	\|---\|---\|
68	\| Done \| Proceed to Stage 1 review \|
69	\| **Do

People who liked this also viewed

6 picks

Type