CtrlK
BlogDocsLog inGet started
Tessl Logo

subagent-driven-development

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

51

Quality

56%

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 actionable and well-sequenced process document with real validation gates, feedback loops, and failure-mode-driven guidance. Its two weaknesses are the ~75 lines of DOT graphs duplicating the prose workflow, and three referenced prompt-template files missing from the bundle, which breaks progressive disclosure at its most important delegation points.

Suggestions

Cut or drastically compress the two DOT digraphs (the 'when to use' decision fits in three lines of prose; the process graph restates the Setup/Task Loop/Final Review sections verbatim) — this alone removes ~75 lines of duplicated workflow.

Ship the three referenced prompt templates (implementer-prompt.md, task-reviewer-prompt.md, re-review-prompt.md) in the bundle, or inline their key contracts, so the dispatch/review steps are not blocked on missing files.

Tighten the recurring restatements of the spec-as-authority ruling rule (it appears in Rulings, Setup, the fix loop, and the breaker) into one canonical statement plus back-references.

DimensionReasoningScore

Conciseness

Most of the body is dense, non-obvious operational guidance that earns its tokens (model-selection heuristics, ledger recovery, fix-loop policy, the rationalizations table), and it assumes competence rather than explaining basics. But the two DOT digraphs (~75 lines) restate what the following prose sections (Setup, The Task Loop, Final Review, Finish) already specify — the process graph duplicates the per-task loop nearly statement-for-statement — which is a padded section that could be cut entirely. Fits anchor 3 ('mostly efficient but could be tightened') more than 4, which would require only 'minor instances' of trimmable material.

3 / 5

Actionability

Guidance is fully executable: exact script invocations ('bash scripts/sdd-workspace PLAN_FILE', 'bash scripts/review-package PLAN_FILE BASE HEAD'), a concrete BASE-recording rule with the HEAD~1 failure mode named, exact ledger line formats ('Task <N>: fix round <R>/5 (...)'), a four-value implementer status taxonomy with a handling rule per value, an enumerated dispatch contract (1)-(5), and a worked example workflow covering the common path including a fix round. Fits anchor 5 ('copy-paste ready commands; specific examples cover the common cases').

5 / 5

Workflow Clarity

The multi-step process is explicitly sequenced (Setup → task loop steps 1-5 → final review → finish) with validation checkpoints throughout: every task gates on a two-verdict review, fixes get scoped re-reviews with per-finding ADDRESSED/NOT ADDRESSED verdicts, a 5-round breaker with adjudication rules, and destructive operations (rm -rf workspace, git clean -fdx) are explicitly fenced behind a clean final review. Feedback loops, error recovery routes, and a rationalizations checklist are all present — anchor 5 exactly.

5 / 5

Progressive Disclosure

The structure is conceptually right: SKILL.md is the overview, per-role prompt templates are offloaded to separate files, and the three referenced scripts (scripts/sdd-workspace, scripts/task-brief, scripts/review-package) exist in the bundle. However, three of the most load-bearing referenced files — implementer-prompt.md, task-reviewer-prompt.md, and re-review-prompt.md — are absent from the bundle, so the disclosure chain is broken exactly where the skill delegates its detailed contracts. That drops it below anchor 4's 'minor organization gaps' to anchor 3's 'could be better organized' territory, though the references that do exist are clearly signaled and one level deep.

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 clean, explicit trigger clause but is only half a description: it says when to use the skill and nothing about what the skill does. The absence of 'subagent' language both weakens specificity and creates overlap risk with the closely related inline plan-execution skill.

Suggestions

Add a 'what' clause naming the concrete actions, e.g. 'Execute an implementation plan by dispatching a fresh implementer subagent per task, reviewing each task for spec compliance and code quality, and running a final whole-branch review.'

Include the distinguishing keyword 'subagent(s)' in the description so it cannot collide with a sibling inline plan-execution skill on the same trigger.

Broaden trigger coverage with natural synonyms users would say, such as 'run/execute/carry out this plan' and 'independent plan tasks'.

DimensionReasoningScore

Specificity

The description names the domain ("executing implementation plans with independent tasks") but names zero concrete actions — nothing about dispatching subagents, per-task review, or final whole-branch review, all of which are the skill's actual work. It matches anchor 2 ('Names the domain but actions are minimal or generic', e.g. 'Processes PDF files') and is above anchor 1 only because the domain itself is specific rather than 'entirely vague'.

2 / 5

Completeness

Only the 'when' half is present ("Use when executing implementation plans with independent tasks in the current session"); the 'what' — what the skill actually does — is entirely absent. This is exactly anchor 2 ('only "when" is present without "what"'): the 'when' clause itself is clear, so it is not anchor 1, but a clear 'what' would be required for anchor 3+.

2 / 5

Trigger Term Quality

"executing implementation plans", "independent tasks", and "current session" are phrases a user might plausibly say, but common variations and synonyms are missing — nothing like "run the plan", "carry out the tasks", "execute this plan", or "subagent(s)", which is the skill's defining mechanism. Fits anchor 3 ('Some relevant keywords but missing common variations or synonyms'), not 4 (which needs the variations covered) or 2 (keywords are domain-relevant, not generic like 'works with files').

3 / 5

Distinctiveness Conflict Risk

The description is domain-specific (plan execution, not generic help), but it does not mention subagents — the feature that distinguishes this skill from the sibling inline 'executing-plans' skill it explicitly contrasts with in the body, so the same trigger could fire either skill. Fits anchor 3 ('Somewhat specific but could still overlap with similar skills'); anchor 4 would require the distinguishing mechanism to be visible in the description itself.

3 / 5

Total

10

/

20

Passed

Validation

87%

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

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (569 lines); consider splitting into references/ and linking

Warning

relative_links

Relative link issues: 4 missing, 1 suspicious

Warning

Total

14

/

16

Passed

Repository
obra/superpowers
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.