subagent-driven-development
Skill3 starsChanged 6 months agoMITView on GitHub
Use when executing implementation plans with independent tasks. Dispatches fresh delegate_task per task with two-stage review (spec compliance then code quality).
189 other projects use a version of this, 53 of them edited.
Adopted by
Most recently taken up by
- DemonDamon/AgenticXedited, first seen Nov 9, 2026
- roundpilot/superpowers-antigravitytheir own version, first seen Nov 8, 2026
- REPOZY/superpowers-optimizedtheir own version, first seen Nov 8, 2026
- lingyired/status-triotheir own version, first seen Nov 8, 2026
- DJtx001/ai-coding-playbooktheir own version, first seen Nov 8, 2026
- namlxuit056/social-forextheir own version, first seen Nov 8, 2026
Used with
Projects with it also use chinese-code-review, chinese-commit-conventions and 8 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Leodorareluctant259Skillchinese-code-review
中文代码审查规范——在保持专业严谨的同时,用符合国内团队文化的方式给出有效反馈
Also in 8 projects that use this
Leodorareluctant259Skillchinese-commit-conventions
中文 Git 提交规范 — 适配国内团队的 commit message 规范和 changelog 自动化
Also in 8 projects that use this
obraSkilldiagnosing-superpowers
Use when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.
Also in 19 projects that use this
math-incSkillminecraft-modpack-server
Set up a modded Minecraft server from a CurseForge/Modrinth server pack zip. Covers NeoForge/Forge install, Java version, JVM tuning, firewall, LAN config, backups, and launch scripts.
Also in 5 projects that use this
math-incSkillpokemon-player
Play Pokemon games autonomously via headless emulation. Starts a game server, reads structured game state from RAM, makes strategic decisions, and sends button inputs — all from the terminal.
Also in 5 projects that use this
farslabSkillaws-agentic-ai
AWS Bedrock AgentCore comprehensive expert for deploying and managing AI agents at scale. Use when working with any AgentCore service including Gateway, Runtime, Memory, Identity, Code Interpreter, Browser, Observability, Agent Registry, or Evaluations. Covers agent deployment, MCP tool integration, credential management, agent discovery, governance workflows, and automated quality assessment. Essential when user mentions AgentCore, agent runtime, agent registry, agent evaluation, MCP gateway, deploy agent, register MCP server, discover agents, evaluate agent quality, agent credentials, or wants to build, deploy, catalog, or monitor AI agents on AWS.
Also in 3 projects that use this
- +3 more from Leodorareluctant259
- +1 more from math-inc
Other versions189 projects use a version of this.
Word for word · 2
- Tommy-yw/RunbookHermes★ 546100% same
- RedWoodOG/Hermes-Desktop★ 177100% same
Edited · 53
- math-inc/OpenGauss★ 1.3k99% same
- DemonDamon/AgenticX★ 1k13% same
- derHaken/SuperAntigravity★ 43913% same
- Ibrahim-3d/conductor-orchestrator-superpowers★ 38112% same
- Ibrahim-3d/orchestrator-supaconductor★ 37812% same
- Asvarox/allkaraoke★ 26921% same
- totvs/engpro-advpl-tlpp-skills★ 16613% same
- haojing8312/WorkClaw★ 14113% same
- AtlasOmnia/donna-starter★ 13630% same
- ARounder-183/HiFiShifter★ 9313% same
43 more not listed
Wrote their own version · 134
- obra/superpowers★ 314ksame name
- jnMetaCode/superpowers-zh★ 8.4ksame name
- openai/plugins★ 7.8ksame name
- farm-fe/farm★ 5.6ksame name
- lingyired/status-trio★ 1.8ksame name
- GanyuanRan/Aegis★ 1.4ksame name
- pcvelz/superpowers★ 1.3ksame name
- coco-research/coco★ 797same name
- koaning/wigglystuff★ 455same name
- KbWen/agentic-os★ 229same name
124 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository34 other files it gives its agents.
- tool-comparison-heatmapSkill
- ascii-artSkill
- excalidrawSkill
- p5jsSkill
- songwriting-and-ai-musicSkill
- webhook-subscriptionsSkill
- himalayaSkill
- github-authSkill
- github-code-reviewSkill
- github-issuesSkill
- github-pr-workflowSkill
- find-nearbySkill
- native-mcpSkill
- songseeSkill
- youtube-contentSkill
- ai-research-output-publisherSkill
- notionSkill
- ocr-and-documentsSkill
- arxivSkill
- blogwatcherSkill
- comparison-deep-researchSkill
- polymarketSkill
- multi-search-engineSkill
- ai-research-browser-cliSkill
- ai-research-browserSkill
- cross-agent-skill-syncSkill
- oracle-ai-research-e2eSkill
- planSkill
- requesting-code-reviewSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- writing-plansSkill
- telegram-approval-gateSkill
- telegram-channel-posterSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. 0 are common, 13 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 177 edited versions we read keep these.
13
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
Use this skill when:
- Distinctive: line 39
Read the plan file. Extract ALL tasks with their full text and context upfront.
- Distinctive: line 53
Key: Read the plan ONCE. Extract everything.
- Very specific: line 61
Use delegate_task with complete context:
- Distinctive: line 93
After the implementer completes, verify against the original spec:
- Distinctive: line 122
After spec compliance passes:
- Distinctive: line 160
After ALL tasks are complete, dispatch a final integration reviewer:
- Distinctive: line 205
Start implementation without a plan
- Distinctive: line 224
Don't rush them into implementation
- Distinctive: line 231
Don't skip the re-review
- Distinctive: line 236
Don't try to fix manually in the controller session (context pollution)
- Distinctive: line 243
No confusion from prior tasks' code or reasoning
- Distinctive: line 265
Write failing test first
- Distinctive: line 278
If a subagent encounters bugs during implementation:
“Common” is measured: kept by at least 6 in 10 of the 177 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Subagent-Driven Development
Overview
Execute implementation plans by dispatching fresh subagents per task with systematic two-stage review.
Core principle: Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.
When to Use
Use this skill when:
- You have an implementation plan (from writing-plans skill or user requirements)
- Tasks are mostly independent
- Quality and spec compliance are important
- You want automated review between tasks
vs. manual execution:
- Fresh context per task (no confusion from accumulated state)
- Automated review process catches issues early
- Consistent quality checks across all tasks
- Subagents can ask questions before starting work
The Process
1. Read and Parse Plan
Read the plan file. Extract ALL tasks with their full text and context upfront. Create a todo list:
# Read the plan
read_file("docs/plans/feature-plan.md")
# Create todo list with all tasks
todo([
{"id": "task-1", "content": "Create User model with email field", "status": "pending"},
{"id": "task-2", "content": "Add password hashing utility", "status": "pending"},
{"id": "task-3", "content": "Create login endpoint", "status": "pending"},
])Key: Read the plan ONCE. Extract everything. Don't make subagents read the plan file — provide the full task text directly in context.
2. Per-Task Workflow
For EACH task in the plan:
Step 1: Dispatch Implementer Subagent
Use delegate_task with complete context:
delegate_task(
goal="Implement Task 1: Create User model with email and password_hash fields",
context="""
TASK FROM PLAN:
- Create: src/models/user.py
- Add User class with email (str) and password_hash (str) fields
- Use bcrypt for password hashing
- Include __repr__ for debugging
FOLLOW TDD:
1. Write failing test in tests/models/test_user.py
2. Run: pytest tests/models/test_user.py -v (verify FAIL)
3. Write minimal implementation
4. Run: pytest tests/models/test_user.py -v (verify PASS)
5. Run: pytest tests/ -q (verify no regressions)
6. Commit: git add -A && git commit -m "feat: add User model with password hashing"
PROJECT CONTEXT:
- Python 3.11, Flask app in src/app.py
- Existing models in src/models/
- Tests use pytest, run from project root
- bcrypt already in requirements.txt
""",
toolsets=['terminal', 'file']
)Step 2: Dispatch Spec Compliance Reviewer
After the implementer completes, verify against the original spec:
delegate_task(
goal="Review if implementation matches the spec from the plan",
context="""
ORIGINAL TASK SPEC:
- Create src/models/user.py with User class
- Fields: email (str), password_hash (str)
- Use bcrypt for password hashing
- Include __repr__
CHECK:
- [ ] All requirements from spec implemented?
- [ ] File paths match spec?
- [ ] Function signatures match spec?
- [ ] Behavior matches expected?
- [ ] Nothing extra added (no scope creep)?
OUTPUT: PASS or list of specific spec gaps to fix.
""",
toolsets=['file']
)If spec issues found: Fix gaps, then re-run spec review. Continue only when spec-compliant.
Step 3: Dispatch Code Quality Reviewer
After spec compliance passes:
delegate_task(
goal="Review code quality for Task 1 implementation",
context="""
FILES TO REVIEW:
- src/models/user.py
- tests/models/test_user.py
CHECK:
- [ ] Follows project conventions and style?
- [ ] Proper error handling?
- [ ] Clear variable/function names?
- [ ] Adequate test coverage?
- [ ] No obvious bugs or missed edge cases?
- [ ] No security issues?
OUTPUT FORMAT:
- Critical Issues: [must fix before proceeding]
- Important Issues: [should fix]
- Minor Issues: [optional]
- Verdict: APPROVED or REQUEST_CHANGES
""",
toolsets=['file']
)If quality issues found: Fix issues, re-review. Continue only when approved.
Step 4: Mark Complete
todo([{"id": "task-1", "content": "Create User model with email field", "status": "completed"}], merge=True)3. Final Review
After ALL tasks are complete, dispatch a final integration reviewer:
delegate_task(
goal="Review the entire implementation for consistency and integration issues",
context="""
All tasks from the plan are complete. Review the full implementation:
- Do all components work together?
- Any inconsistencies between tasks?
- All tests passing?
- Ready for merge?
""",
toolsets=['terminal', 'file']
)4. Verify and Commit
# Run full test suite
pytest tests/ -q
# Review all changes
git diff --stat
# Final commit if needed
git add -A && git commit -m "feat: complete [feature name] implementation"Task Granularity
Each task = 2-5 minutes of focused work.
Too big:
- "Implement user authentication system"
Right size:
- "Create User model with email and password fields"
- "Add password hashing function"
- "Create login endpoint"
- "Add JWT token generation"
- "Create registration endpoint"
Red Flags — Never Do These
- Start implementation without a plan
- Skip reviews (spec compliance OR code quality)
- Proceed with unfixed critical/important issues
- Dispatch multiple implementation subagents for tasks that touch the same files
- Make subagent read the plan file (provide full text in context instead)
- Skip scene-setting context (subagent needs to understand where the task fits)
- Ignore subagent questions (answer before letting them proceed)
- Accept "close enough" on spec compliance
- Skip review loops (reviewer found issues → implementer fixes → review again)
- Let implementer self-review replace actual review (both are needed)
- Start code quality review before spec compliance is PASS (wrong order)
- Move to next task while either review has open issues
Handling Issues
If Subagent Asks Questions
- Answer clearly and completely
- Provide additional context if needed
- Don't rush them into implementation
If Reviewer Finds Issues
- Implementer subagent (or a new one) fixes them
- Reviewer reviews again
- Repeat until approved
- Don't skip the re-review
If Subagent Fails a Task
- Dispatch a new fix subagent with specific instructions about what went wrong
- Don't try to fix manually in the controller session (context pollution)
Efficiency Notes
Why fresh subagent per task:
- Prevents context pollution from accumulated state
- Each subagent gets clean, focused context
- No confusion from prior tasks' code or reasoning
Why two-stage review:
- Spec review catches under/over-building early
- Quality review ensures the implementation is well-built
- Catches issues before they compound across tasks
Cost trade-off:
- More subagent invocations (implementer + 2 reviewers per task)
- But catches issues early (cheaper than debugging compounded problems later)
Integration with Other Skills
With writing-plans
This skill EXECUTES plans created by the writing-plans skill:
- User requirements → writing-plans → implementation plan
- Implementation plan → subagent-driven-development → working code
With test-driven-development
Implementer subagents should follow TDD:
- Write failing test first
- Implement minimal code
- Verify test passes
- Commit
Include TDD instructions in every implementer context.
With requesting-code-review
The two-stage review process IS the code review. For final integration review, use the requesting-code-review skill's review dimensions.
With systematic-debugging
If a subagent encounters bugs during implementation:
- Follow systematic-debugging process
- Find root cause before fixing
- Write regression test
- Resume implementation
Example Workflow
[Read plan: docs/plans/auth-feature.md]
[Create todo list with 5 tasks]
--- Task 1: Create User model ---
[Dispatch implementer subagent]
Implementer: "Should email be unique?"
You: "Yes, email must be unique"
Implementer: Implemented, 3/3 tests passing, committed.
[Dispatch spec reviewer]
Spec reviewer: ✅ PASS — all requirements met
[Dispatch quality reviewer]
Quality reviewer: ✅ APPROVED — clean code, good tests
[Mark Task 1 complete]
--- Task 2: Password hashing ---
[Dispatch implementer subagent]
Implementer: No questions, implemented, 5/5 tests passing.
[Dispatch spec reviewer]
Spec reviewer: ❌ Missing: password strength validation (spec says "min 8 chars")
[Implementer fixes]
Implementer: Added validation, 7/7 tests passing.
[Dispatch spec reviewer again]
Spec reviewer: ✅ PASS
[Dispatch quality reviewer]
Quality reviewer: Important: Magic number 8, extract to constant
Implementer: Extracted MIN_PASSWORD_LENGTH constant
Quality reviewer: ✅ APPROVED
[Mark Task 2 complete]
... (continue for all tasks)
[After all tasks: dispatch final integration reviewer]
[Run full test suite: all passing]
[Done!]Remember
Fresh subagent per task
Two-stage review every time
Spec compliance FIRST
Code quality SECOND
Never skip reviews
Catch issues earlyQuality is not an accident. It's the result of systematic process.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

