Menu
Execute an implementation plan by dispatching fresh subagents per task with dual-review (spec compliance + code quality). Use when running sdd:5-implement or executing any multi-task implementation plan.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Apply idiomatic, well-structured Python development practices. Use when writing, reviewing, or refactoring Python code. Covers type annotations, package management with uv, Pydantic DTOs, Typer CLIs, pytest patterns, PEP 8 style, architecture, and type-driven design.
How to manage Python dependencies with UV — inline script metadata (PEP 723), project mode, tool running, and when to use each approach. Always use UV; never pip directly.
Use when receiving code review feedback (especially if unclear or technically questionable), when completing tasks or major features requiring review before proceeding, or before making any completion/success claims. Covers four practices — receiving feedback with technical rigor, requesting reviews via code-reviewer subagent, verification gates requiring evidence before claims, and security/API-compat awareness. Essential for subagent-driven development, pull requests, and preventing false completion claims.
Synthesize knowledge from multiple sources into Zettelkasten notes for Logseq. Use when creating wiki pages, integrating academic research, or building interconnected knowledge with [[links]] and
Survey a Google Drive's actual folder structure, apply a PARA-lite organization framework, and produce (then safely execute) a concrete reorganization plan — deduping, sweeping root-level clutter, and fixing misnested folders.
Idiomatic review for Rust — async/Tokio daemon design, ports-and-adapters trait boundaries, and thiserror/anyhow error handling. Use when reviewing or writing Rust code that defines async trait "ports" (dependency-inversion boundaries), runs a single-threaded Tokio daemon (current_thread runtime + LocalSet/spawn_local), or crosses a wire/domain type boundary. Covers async fn in traits vs async-trait, Rc/RefCell vs Arc/Mutex, tokio::select! cancel-safety, blocking calls in async context, thiserror-vs-anyhow error typing, wire/domain type separation, and common anti-patterns (clone in hot loops, overly generic port bounds). NOT for pure performance/profiling work (see rust-profiling, rust-perf-tuning, rust-memory-optimization, rust-parallel-processing) or unsafe/CLI/wasm-bindgen review (no dedicated skill yet — use the sdd:6-verify research-agent fallback for those).
| name | subagent-driven-development |
| description | Execute an implementation plan by dispatching fresh subagents per task with dual-review (spec compliance + code quality). Use when running sdd:5-implement or executing any multi-task implementation plan. |
Execute an implementation plan by dispatching one fresh subagent per task, each reviewed by a spec compliance reviewer and a code quality reviewer before the coordinator moves forward.
Each subagent receives only the context it needs — task description, relevant files, and acceptance criteria. It does not inherit the coordinator's full session history. This prevents context poisoning and keeps each task focused.
The coordinator:
For each task in plan.md:
The coordinator identifies:
Worker receives ONLY:
Task: <task description>
Acceptance criteria:
<list from plan.md>
Files to create/modify:
<exact paths>
Worker must NOT receive: coordinator's full session history, other tasks, or the full plan.
Spec reviewer receives:
Diff:
<git diff of the worker's changes>
Task acceptance criteria:
<list from plan.md>
Check:
1. Are all acceptance criteria demonstrably met?
2. Are there any correctness issues?
3. Are there any security or data integrity gaps?
Output findings with severity: VIOLATION (blocks) or WARNING (noted, doesn't block).
Quality reviewer receives:
Diff:
<git diff of the worker's changes>
Validation plan test cases:
<relevant entries from validation.md>
Check:
1. Are there tests for all new public methods?
2. Do tests cover both happy path and error paths?
3. Are tests named descriptively?
4. Are assertions specific (not just "not null")?