CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

subagent-driven-development

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

Quality

61%

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 ./.agents/skills/subagent-driven-development/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

62%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 content's core strength is an exceptionally clear, gated workflow with enforced review loops — the strongest part of the skill. Its weaknesses are the missing prompt-template files the process depends on, duplicated content in the process graph and Advantages section, and a description-body mismatch where the operational detail never surfaces in the frontmatter. Restoring or inlining the three templates would resolve the biggest executability gap in one step.

Suggestions

Add the three referenced prompt template files (implementer-prompt.md, spec-reviewer-prompt.md, code-quality-reviewer-prompt.md) to the bundle, or inline their content — the dispatch steps currently point at artifacts that do not exist.

Remove the duplicated edge list in the process dot graph (lines 68-86 repeat every edge already declared in the node/subgraph section), roughly halving that block.

Trim the Advantages section to points not already covered (drop the restated fresh-context, two-stage-review, and same-session bullets) and cut the example workflow to one full task cycle instead of two plus ellipsis.

DimensionReasoningScore

Conciseness

The body is mostly operational with no explanations of concepts Claude already knows, but it carries real redundancy: the process dot graph declares its edges and then repeats the entire edge list verbatim (lines 68-86), the ~30-line "Advantages" section restates points already made (fresh context, two-stage review, same session) as persuasive rationale, and the 72-line example workflow re-walks the same loop as the graph. This matches anchor 3 ("mostly efficient but... could be tightened"); it exceeds 2's "several unnecessary explanations" because the bulk is genuinely non-obvious guidance, and misses 4 because the duplication goes beyond minor instances.

3 / 5

Actionability

In-body guidance is concrete — the four-status taxonomy (DONE/DONE_WITH_CONCERNS/NEEDS_CONTEXT/BLOCKED) with explicit handling rules, model-selection heuristics, and a worked dialogue example — but the three referenced prompt templates (./implementer-prompt.md, ./spec-reviewer-prompt.md, ./code-quality-reviewer-prompt.md) that the process instructs Claude to dispatch with are absent from the bundle, and execution further depends on external skills (git-worktree, writing-plans, requesting-code-review, branch-finish). This matches anchor 3 ("missing key details"); the missing dispatch prompts are the skill's core executable artifact, so it cannot reach 4's "minor gaps".

3 / 5

Workflow Clarity

The process is fully sequenced (extract tasks → per-task dispatch loop → final review → branch-finish) with explicit validation gates ("Start code quality review before spec compliance is ✅" is forbidden; "Never... Move to next task while either review has open issues") and explicit feedback loops ("Implementer (same subagent) fixes them → Reviewer reviews again → Repeat until approved → Don't skip the re-review"), plus a Never-rules checklist. This matches anchor 5 ("Clear sequence with explicit validation steps; feedback loops for error recovery; checklists"); it is not 4 because checkpoints are not merely present but enforced with rules and loop-back edges.

5 / 5

Progressive Disclosure

In-body section organization is clean and the three prompt-template references are clearly signaled in a dedicated "Prompt Templates" section and kept one level deep, but the actual bundle contains no such files — all three referenced paths are broken, so the content split is aspirational rather than real, and long inline sections (Advantages, the 72-line example) could be trimmed or externalized. This matches anchor 3; it is not 4 because absent referenced files are more than a "minor organization gap", and not 2 because the references are clearly signaled, not buried, and the body itself has genuine structure.

3 / 5

Total

14

/

20

Passed

Description

40%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 well-scoped trigger clause with sharp disambiguation from its sibling skill, but it answers only "when" and not "what" — the skill's actual mechanism (fresh subagent per task, two-stage spec-then-quality review) is invisible from the description alone. Adding a concise capability clause would fix both the completeness and specificity gaps at once.

Suggestions

Add a "what" clause before the "Use when" clause, e.g. "Executes implementation plans by dispatching a fresh subagent per task with two-stage review (spec compliance, then code quality). Use when executing implementation plans with independent tasks in the current session."

Name the concrete capabilities (subagent dispatch, spec compliance review, code quality review loops, model selection by task complexity) so the description scores on specificity, not just domain.

Include natural trigger variations such as "run the plan", "implement the plan tasks", or "work through the plan" to broaden keyword coverage.

DimensionReasoningScore

Specificity

The description names the domain precisely ("executing implementation plans", "independent tasks") but lists no concrete actions — nothing about subagent dispatch, two-stage review, or task loops. It matches anchor 2 ("Names the domain but actions are minimal or generic"); it is not 3 because no specific capability is stated, and not 1 because the domain is named clearly rather than being pure abstraction.

2 / 5

Completeness

Only a "when" clause is present ("Use when executing implementation plans...") while the "what" — dispatching a fresh subagent per task with two-stage spec and quality review — is entirely absent. This is exactly anchor 2 ("only 'when' is present without 'what'", e.g. "Use when working with documents"); it is not 3 because the "what" is not even weakly implied, and not 1 because the "when" clause itself is clear and specific.

2 / 5

Trigger Term Quality

"executing implementation plans" is the natural core phrase a user would say, with "independent tasks" as a genuine qualifier, but there are no synonyms or common variations (e.g. "run the plan", "work the tasks", "implement the plan"). This matches anchor 3 ("Some relevant keywords but missing common variations or synonyms"); it falls short of 4's "good keyword coverage" because only one trigger concept is covered.

3 / 5

Distinctiveness Conflict Risk

"independent tasks in the current session" sharply disambiguates from the sibling executing-plans skill (parallel session), giving a mostly distinct niche with only minor overlap risk against generic plan-execution skills. It is not 5 because distinctness rests entirely on when-clause qualifiers — with no capability description, "executing implementation plans" still overlaps the plan-execution skill family.

4 / 5

Total

11

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

phatblat/dotfiles

Path

.agents/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.