{“content”:”---\nname: subagent-driven-development\ndescription: Use when executing implementation plans with independent tasks. Dispatches fresh delegate_task per task with two-stage review (spec compliance then code quality).\nversion: 1.1.0\nauthor: Hermes Agent (adapted from obra/superpowers)\nlicense: MIT\nmetadata:\n hermes:\n tags: [delegation, subagent, implementation, workflow, parallel]\n related_skills: [writing-plans, requesting-code-review, test-driven-development]\n---\n\n# Subagent-Driven Development\n\n## Overview\n\nExecute implementation plans by dispatching fresh subagents per task with systematic two-stage review.\n\nCore principle: Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.\n\n## When to Use\n\nUse this skill when:\n- You have an implementation plan (from writing-plans skill or user requirements)\n- Tasks are mostly independent\n- Quality and spec compliance are important\n- You want automated review between tasks\n\nvs. manual execution:\n- Fresh context per task (no confusion from accumulated state)\n- Automated review process catches issues early\n- Consistent quality checks across all tasks\n- Subagents can ask questions before starting work\n\n## The Process\n\n### 1. Read and Parse Plan\n\nRead the plan file. Extract ALL tasks with their full text and context upfront. Create a todo list:\n\npython\n# Read the plan\nread_file(\"docs/plans/feature-plan.md\")\n\n# Create todo list with all tasks\ntodo([\n {\"id\": \"task-1\", \"content\": \"Create User model with email field\", \"status\": \"pending\"},\n {\"id\": \"task-2\", \"content\": \"Add password hashing utility\", \"status\": \"pending\"},\n {\"id\": \"task-3\", \"content\": \"Create login endpoint\", \"status\": \"pending\"},\n])\n\n\nKey: Read the plan ONCE. Extract everything. Don’t make subagents read the plan file — provide the full task text directly in context.\n\n### 2. Per-Task Workflow\n\nFor EACH task in the plan:\n\n#### Step 1: Dispatch Implementer Subagent\n\nUse delegate_task with complete context:\n\npython\ndelegate_task(\n goal=\"Implement Task 1: Create User model with email and password_hash fields\",\n context=\"\"\"\n TASK FROM PLAN:\n - Create: src/models/user.py\n - Add User class with email (str) and password_hash (str) fields\n - Use bcrypt for password hashing\n - Include __repr__ for debugging\n\n FOLLOW TDD:\n 1. Write failing test in tests/models/test_user.py\n 2. Run: pytest tests/models/test_user.py -v (verify FAIL)\n 3. Write minimal implementation\n 4. Run: pytest tests/models/test_user.py -v (verify PASS)\n 5. Run: pytest tests/ -q (verify no regressions)\n 6. Commit: git add -A && git commit -m \"feat: add User model with password hashing\"\n\n PROJECT CONTEXT:\n - Python 3.11, Flask app in src/app.py\n - Existing models in src/models/\n - Tests use pytest, run from project root\n - bcrypt already in requirements.txt\n \"\"\",\n toolsets=['terminal', 'file']\n)\n\n\n#### Step 2: Dispatch Spec Compliance Reviewer\n\nAfter the implementer completes, verify against the original spec:\n\npython\ndelegate_task(\n goal=\"Review if implementation matches the spec from the plan\",\n context=\"\"\"\n ORIGINAL TASK SPEC:\n - Create src/models/user.py with User class\n - Fields: email (str), password_hash (str)\n - Use bcrypt for password hashing\n - Include __repr__\n\n CHECK:\n - [ ] All requirements from spec implemented?\n - [ ] File paths match spec?\n - [ ] Function signatures match spec?\n - [ ] Behavior matches expected?\n - [ ] Nothing extra added (no scope creep)?\n\n OUTPUT: PASS or list of specific spec gaps to fix.\n \"\"\",\n toolsets=['file']\n)\n\n\nIf spec issues found: Fix gaps, then re-run spec review. Continue only when spec-compliant.\n\n#### Step 3: Dispatch Code Quality Reviewer\n\nAfter spec compliance passes:\n\npython\ndelegate_task(\n goal=\"Review code quality for Task 1 implementation\",\n context=\"\"\"\n FILES TO REVIEW:\n - src/models/user.py\n - tests/models/test_user.py\n\n CHECK:\n - [ ] Follows project conventions and style?\n - [ ] Proper error handling?\n - [ ] Clear variable/function names?\n - [ ] Adequate test coverage?\n - [ ] No obvious bugs or missed edge cases?\n - [ ] No security issues?\n\n OUTPUT FORMAT:\n - Critical Issues: [must fix before proceeding]\n - Important Issues: [should fix]\n - Minor Issues: [optional]\n - Verdict: APPROVED or REQUEST_CHANGES\n \"\"\",\n toolsets=['file']\n)\n\n\nIf quality issues found: Fix issues, re-review. Continue only when approved.\n\n#### Step 4: Mark Complete\n\npython\ntodo([{\"id\": \"task-1\", \"content\": \"Create User model with email field\", \"status\": \"completed\"}], merge=True)\n\n\n### 3. Final Review\n\nAfter ALL tasks are complete, dispatch a final integration reviewer:\n\npython\ndelegate_task(\n goal=\"Review the entire implementation for consistency and integration issues\",\n context=\"\"\"\n All tasks from the plan are complete. Review the full implementation:\n - Do all components work together?\n - Any inconsistencies between tasks?\n - All tests passing?\n - Ready for merge?\n \"\"\",\n toolsets=['terminal', 'file']\n)\n\n\n### 4. Verify and Commit\n\nbash\n# Run full test suite\npytest tests/ -q\n\n# Review all changes\ngit diff --stat\n\n# Final commit if needed\ngit add -A && git commit -m \"feat: complete [feature name] implementation\"\n\n\n## Task Granularity\n\nEach task = 2-5 minutes of focused work.\n\nToo big:\n- “Implement user authentication system”\n\nRight size:\n- “Create User model with email and password fields”\n- “Add password hashing function”\n- “Create login endpoint”\n- “Add JWT token generation”\n- “Create registration endpoint”\n\n## Red Flags — Never Do These\n\n- Start implementation without a plan\n- Skip reviews (spec compliance OR code quality)\n- Proceed with unfixed critical/important issues\n- Dispatch multiple implementation subagents for tasks that touch the same files\n- Make subagent read the plan file (provide full text in context instead)\n- Skip scene-setting context (subagent needs to understand where the task fits)\n- Ignore subagent questions (answer before letting them proceed)\n- Accept “close enough” on spec compliance\n- Skip review loops (reviewer found issues → implementer fixes → review again)\n- Let implementer self-review replace actual review (both are needed)\n- Start code quality review before spec compliance is PASS (wrong order)\n- Move to next task while either review has open issues\n\n## Handling Issues\n\n### If Subagent Asks Questions\n\n- Answer clearly and completely\n- Provide additional context if needed\n- Don’t rush them into implementation\n\n### If Reviewer Finds Issues\n\n- Implementer subagent (or a new one) fixes them\n- Reviewer reviews again\n- Repeat until approved\n- Don’t skip the re-review\n\n### If Subagent Fails a Task\n\n- Dispatch a new fix subagent with specific instructions about what went wrong\n- Don’t try to fix manually in the controller session (context pollution)\n\n## Efficiency Notes\n\nWhy fresh subagent per task:\n- Prevents context pollution from accumulated state\n- Each subagent gets clean, focused context\n- No confusion from prior tasks’ code or reasoning\n\nWhy two-stage review:\n- Spec review catches under/over-building early\n- Quality review ensures the implementation is well-built\n- Catches issues before they compound across tasks\n\nCost trade-off:\n- More subagent invocations (implementer + 2 reviewers per task)\n- But catches issues early (cheaper than debugging compounded problems later)\n\n## Integration with Other Skills\n\n### With writing-plans\n\nThis skill EXECUTES plans created by the writing-plans skill:\n1. User requirements → writing-plans → implementation plan\n2. Implementation plan → subagent-driven-development → working code\n\n### With test-driven-development\n\nImplementer subagents should follow TDD:\n1. Write failing test first\n2. Implement minimal code\n3. Verify test passes\n4. Commit\n\nInclude TDD instructions in every implementer context.\n\n### With requesting-code-review\n\nThe two-stage review process IS the code review. For final integration review, use the requesting-code-review skill’s review dimensions.\n\n### With systematic-debugging\n\nIf a subagent encounters bugs during implementation:\n1. Follow systematic-debugging process\n2. Find root cause before fixing\n3. Write regression test\n4. Resume implementation\n\n## Example Workflow\n\n\n[Read plan: docs/plans/auth-feature.md]\n[Create todo list with 5 tasks]\n\n--- Task 1: Create User model ---\n[Dispatch implementer subagent]\n Implementer: \"Should email be unique?\"\n You: \"Yes, email must be unique\"\n Implementer: Implemented, 3/3 tests passing, committed.\n\n[Dispatch spec reviewer]\n Spec reviewer: ✅ PASS — all requirements met\n\n[Dispatch quality reviewer]\n Quality reviewer: ✅ APPROVED — clean code, good tests\n\n[Mark Task 1 complete]\n\n--- Task 2: Password hashing ---\n[Dispatch implementer subagent]\n Implementer: No questions, implemented, 5/5 tests passing.\n\n[Dispatch spec reviewer]\n Spec reviewer: ❌ Missing: password strength validation (spec says \"min 8 chars\")\n\n[Implementer fixes]\n Implementer: Added validation, 7/7 tests passing.\n\n[Dispatch spec reviewer again]\n Spec reviewer: ✅ PASS\n\n[Dispatch quality reviewer]\n Quality reviewer: Important: Magic number 8, extract to constant\n Implementer: Extracted MIN_PASSWORD_LENGTH constant\n Quality reviewer: ✅ APPROVED\n\n[Mark Task 2 complete]\n\n... (continue for all tasks)\n\n[After all tasks: dispatch final integration reviewer]\n[Run full test suite: all passing]\n[Done!]\n\n\n## Remember\n\n\nFresh subagent per task\nTwo-stage review every time\nSpec compliance FIRST\nCode quality SECOND\nNever skip reviews\nCatch issues early\n\n\nQuality is not an accident. It’s the result of systematic process.\n”}