SpeedyFoxAi/hermes-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

tools-update-cron: sync 2026-08-09 — 37 skill(s) updated

Browse Source
This commit is contained in:
Hermes Agent
2026-08-09 01:01:38 -05:00
parent 94ac068425
commit 004feddf0a
37 changed files with 5386 additions and 760 deletions
Download Patch File Download Diff File Expand all files Collapse all files
subagent-driven-development/SKILL.md
+67 -315
View File
@@ -1,356 +1,108 @@
---
name: subagent-driven-development
description: "Execute plans via delegate_task subagents (2-stage review)."
version: 1.1.0
description: "Execute plans with fresh subagents per task and review."
version: 1.0.0
author: Hermes Agent (adapted from obra/superpowers)
license: MIT
platforms: [linux, macos, windows]
platforms: [linux]
metadata:
hermes:
tags: [delegation, subagent, implementation, workflow, parallel]
related_skills: [writing-plans, requesting-code-review, test-driven-development]
tags: [subagent, delegation, review, execution, sdd]
related_skills: [create-plan, brainstorming, verification-before-completion]
---
# Subagent-Driven Development
## Overview
Execute plan by dispatching a fresh implementer subagent per task, a task review (spec compliance + code quality) after each, and a broad whole-branch review at the end.
Execute implementation plans by dispatching fresh subagents per task with systematic two-stage review.
**Why subagents:** You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
**Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.
**Core principle:** Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration
**Continuous execution:** Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping. The only reasons to stop are: BLOCKED status you cannot resolve, ambiguity that genuinely prevents progress, or all tasks complete.
## 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
- You have an implementation plan with independent tasks
- Tasks can be worked on without shared state
- You want review gates between tasks
- Same session execution (vs dispatching to separate sessions)
## The Process
### 1. Read and Parse Plan
### Setup
Read the plan file. Extract ALL tasks with their full text and context upfront. Create a todo list:
- Read the plan once, note its context and Global Constraints
- Create a todo per task
- Before dispatching Task 1, scan the plan for conflicts: tasks that contradict each other, anything the plan mandates that the review would flag as a defect
- Present conflicts to the user as one batched question before execution begins
```python
# Read the plan
read_file("docs/plans/feature-plan.md")
### Model Selection
# 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"},
])
```
Use the least powerful model that can handle each role:
**Key:** Read the plan ONCE. Extract everything. Don't make subagents read the plan file — provide the full task text directly in context.
- Mechanical implementation (isolated functions, clear specs, 1-2 files): cheap model
- Integration and judgment (multi-file coordination, pattern matching): standard model
- Architecture and design: most capable model
- Review tasks: scaled to diff size, complexity, and risk
- Fix-loop rounds 4-5: model at least one tier above the implementer
### 2. Per-Task Workflow
Always specify the model explicitly when dispatching a subagent.
For EACH task in the plan:
### 1. Dispatch the Implementer
#### Step 1: Dispatch Implementer Subagent
- Task brief: extract the task's full text, make it the single source of requirements
- Compose dispatch with: (1) one line on where this task fits, (2) the brief path, (3) interfaces from earlier tasks, (4) resolution of any ambiguity, (5) report-file path
- Never make a subagent read the whole plan file
- Never dispatch multiple implementation subagents in parallel (conflicts)
Use `delegate_task` with complete context:
### 2. Handle the Report
```python
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
Implementer subagents report one of four statuses:
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"
- DONE: Generate review package, dispatch task reviewer
- DONE_WITH_CONCERNS: Read concerns before proceeding. If about correctness/scope, address before review. If observations, note and proceed.
- NEEDS_CONTEXT: Provide missing context and re-dispatch
- BLOCKED: Assess — context problem (re-dispatch), needs more reasoning (more capable model), too large (break into pieces), plan wrong (escalate to user)
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']
)
```
### 3. Review the Task
#### Step 2: Dispatch Spec Compliance Reviewer
Per-task reviews are task-scoped gates. Two verdicts required: spec compliance AND task quality.
After the implementer completes, verify against the original spec:
- Hand the reviewer a diff file (never paste diffs into context)
- Reviewer inputs: brief file, report file, review package, global constraints
- Do not pre-judge findings — never instruct a reviewer to ignore a specific issue
- The reviewer may report "Cannot verify from diff" items — resolve these yourself
```python
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__
### 4. The Fix Loop
CHECK:
- [ ] All requirements from spec implemented?
- [ ] File paths match spec?
- [ ] Function signatures match spec?
- [ ] Behavior matches expected?
- [ ] Nothing extra added (no scope creep)?
Triggers when review reports spec failure, Critical, or Important findings. Five rounds maximum per task:
OUTPUT: PASS or list of specific spec gaps to fix.
""",
toolsets=['file']
)
```
- Rounds 1-3: Resume the original implementer with open findings verbatim
- Rounds 4-5: Fresh implementer on a more capable model
- Every round: implementer fixes, re-runs tests, appends fix report
- Re-review is scoped: only verify findings were addressed, flag new breakage in fix diff
- Minor findings go to the ledger, never enter the loop
**If spec issues found:** Fix gaps, then re-run spec review. Continue only when spec-compliant.
**The breaker (round 5):** Adjudicate each open finding:
- Reviewer wrong or contestable: park with ruling
- Real but nothing downstream builds on it: park with ruling
- Real and load-bearing: STOP, report BLOCKED to user
#### Step 3: Dispatch Code Quality Reviewer
### 5. Complete the Task
After spec compliance passes:
When review is clean or all open findings are parked at the cap, mark complete and move to next task.
```python
delegate_task(
goal="Review code quality for Task 1 implementation",
context="""
FILES TO REVIEW:
- src/models/user.py
- tests/models/test_user.py
## Final Review
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?
After all tasks: dispatch final whole-branch review on the most capable model. If findings: ONE fix subagent with complete findings list, then ONE scoped re-review. Adjudicate residuals. No second fix wave.
OUTPUT FORMAT:
- Critical Issues: [must fix before proceeding]
- Important Issues: [should fix]
- Minor Issues: [optional]
- Verdict: APPROVED or REQUEST_CHANGES
""",
toolsets=['file']
)
```
## Common Rationalizations
**If quality issues found:** Fix issues, re-review. Continue only when approved.
#### Step 4: Mark Complete
```python
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:
```python
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
```bash
# 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:
1. User requirements → writing-plans → implementation plan
2. Implementation plan → subagent-driven-development → working code
### With test-driven-development
Implementer subagents should follow TDD:
1. Write failing test first
2. Implement minimal code
3. Verify test passes
4. 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:
1. Follow systematic-debugging process
2. Find root cause before fixing
3. Write regression test
4. 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 early
```
**Quality is not an accident. It's the result of systematic process.**
## Further reading (load when relevant)
When the orchestration involves significant context usage, long review loops, or complex validation checkpoints, load these references for the specific discipline:
- **`references/context-budget-discipline.md`** — Four-tier context degradation model (PEAK / GOOD / DEGRADING / POOR), read-depth rules that scale with context window size, and early warning signs of silent degradation. Load when a run will clearly consume significant context (multi-phase plans, many subagents, large artifacts).
- **`references/gates-taxonomy.md`** — The four canonical gate types (Pre-flight, Revision, Escalation, Abort) with behavior, recovery, and examples. Load when designing or reviewing any workflow that has validation checkpoints — use the vocabulary explicitly so each gate has defined entry, failure behavior, and resumption rules.
Both references adapted from gsd-build/get-shit-done (MIT © 2025 Lex Christopherson).
## Pre-commit verification pipeline
The two-stage review in this skill uses a systematic 8-step pre-commit verification pipeline. See `references/pre-commit-verification-pipeline.md` for the full recipe: static security scan, baseline tests and linting, self-review checklist, independent reviewer subagent template, and auto-fix loop. This was previously the `requesting-code-review` skill (v2.0.0), absorbed here as a canonical quality gate.
| Excuse | Reality |
|--------|---------|
| "Close enough on spec compliance" | Reviewer found spec gaps = not done |
| "I'll fix it myself" | Controller fixes pollute context and skip review |
| "One more round will converge" | Past the cap, rounds don't converge — failure is structural |
| "This finding is obviously wrong, I'll drop it" | Adjudicate only at the cap, every ruling is a ledger entry |
| "The fix was small, skip the re-review" | Unreviewed fixes are how regressions land |