CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

subagent-driven-development

Use when executing implementation plans with independent tasks in the current session

Quality

64%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/subagent-driven-development/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

77%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is an exceptionally well-engineered orchestration procedure: concrete commands, per-task review gates, a capped fix loop with scoped re-reviews, and compaction-safe ledger bookkeeping. Its weaknesses are repetition of the same warnings across sections and a bundle defect: the implementer, task-reviewer, and re-review prompt templates it repeatedly points to are missing files.

Suggestions

Add the missing template files (implementer-prompt.md, task-reviewer-prompt.md, re-review-prompt.md) or inline minimal versions of them — every task dispatch currently dead-ends at a nonexistent path.

State each recurring warning once and reference it: the 'never HEAD~1' rule and the ledger/compaction rationale each appear 2-3 times across sections.

Trim the Model Selection section by merging the 'Turn count beats token price' guidance and the 'Task complexity signals' list, which restate the same tier choices.

DimensionReasoningScore

Conciseness

Mostly dense and operational, but with real repetition that could be tightened: the 'never HEAD~1' warning is stated verbatim twice (Handle the report and Review the task), the ledger-survives-compaction rationale appears three times (Setup, Task Loop intro, Common Rationalizations), 'never pause between tasks' recurs in three sections, and Model Selection overlaps with the complexity-signals list. This fits anchor 3 ('mostly efficient but includes some unnecessary explanation or could be tightened') rather than anchor 4, where over-explanation would be only minor instances.

3 / 5

Actionability

Fully executable throughout: exact commands with arguments ('bash scripts/sdd-workspace PLAN_FILE', 'bash scripts/task-brief PLAN_FILE N', 'bash scripts/review-package PLAN_FILE BASE HEAD'), exact ledger line formats ('Task <N>: complete (commits <base7>..<head7>, review clean)'), a five-part dispatch composition recipe, a four-status report taxonomy, and even a no-bash fallback ('git log --oneline, git diff --stat, and git diff -U10 ... redirected to one uniquely named file'). This matches anchor 5 — copy-paste ready commands covering the common cases.

5 / 5

Workflow Clarity

The sequence is explicit and graphed (Setup → per-task loop → final review), with validation gates at every task (spec ✅ AND quality, never skipped), a fix loop with a round cap, a breaker, and a scoped re-review every round, explicit four-stop conditions, ledger recovery, and a resumption procedure. This matches anchor 5 exactly: clear sequence, explicit validation steps, feedback loops for error recovery, and checklists — the destructive/batch cap does not apply because validation is pervasive.

5 / 5

Progressive Disclosure

The split itself is good — seven clearly signaled one-level-deep references (fix-loop, preflight, final-review, etc.) plus three scripts, loaded at point of need. But scoring against the actual bundle: three referenced paths do not exist — 'implementer-prompt.md' and 'task-reviewer-prompt.md' are cited from the body ('Template: [implementer-prompt.md](implementer-prompt.md)' and inside the process graph) and 're-review-prompt.md' is cited from fix-loop.md/final-review.md. Navigation dead-ends at the per-task templates the whole workflow depends on, which is more than anchor 4's 'minor organization gaps'; anchor 3's 'some structure but could be better organized' is the closest fit.

3 / 5

Total

16

/

20

Passed

Description

36%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is a bare trigger clause: it says when to use the skill but never what the skill does, omitting its core mechanism (fresh implementer subagent per task, task reviews, final whole-branch review). This hurts discoverability for users who describe the outcome rather than the process, and leaves it underdistinguished from an inline plan-execution skill.

Suggestions

Add a 'what' clause stating the concrete mechanism, e.g. 'Dispatches a fresh implementer subagent per task, reviews each task for spec compliance and code quality, and runs a whole-branch final review.'

Include natural trigger keywords users would actually say — 'subagent', 'delegate tasks', 'execute the plan', 'spec-driven' — to improve both completeness and trigger-term coverage.

Differentiate from inline plan execution in the description itself (e.g. mention that tasks are delegated to isolated subagents), so it does not fire for tightly-coupled plans better served by inline execution.

DimensionReasoningScore

Specificity

The description names the domain ("executing implementation plans with independent tasks in the current session") but contains no concrete actions whatsoever — nothing about dispatching fresh subagents per task, per-task reviews, or a whole-branch final review. It fits anchor 2 (domain named, actions absent/minimal); it is not anchor 3 because no 1-2 concrete actions are listed, and not anchor 1 because "executing implementation plans" is a concrete domain, not pure abstraction.

2 / 5

Completeness

Only a 'when' clause is present ("Use when executing...") with no statement of what the skill does — the dispatch-per-task/review/final-review mechanism appears nowhere. This exactly matches anchor 2 ('only when is present without what', e.g. "Use when working with documents"); it cannot be 3 because a clear 'what' is absent, and not 1 because the 'when' is concrete rather than extremely vague.

2 / 5

Trigger Term Quality

"executing implementation plans", "independent tasks", and "current session" are phrases a user would plausibly say, but coverage is thin — missing "subagent", "delegate/dispatch", "spec", and "run the plan" variants. Anchor 3 (some relevant keywords, missing common variations) is the closest fit; it does not reach anchor 4's 'good keyword coverage'.

3 / 5

Distinctiveness Conflict Risk

The trigger is moderately specific, but the body itself names a sibling skill ('executing-plans', inline execution) that would fire on the same phrase, and the description omits the differentiator (per-task subagent dispatch). Anchor 3 ('somewhat specific but could still overlap with similar skills') fits; anchor 4 would require distinct triggers that clearly separate it from the closely related inline-execution skill.

3 / 5

Total

10

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 2 missing

Warning

Total

15

/

16

Passed

Repository

obra/superpowers

Path

skills/subagent-driven-development/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.