fill-the-gaps

Assumption-first planning and design gap analysis. Use when user is in PLANNING mode, explicitly asks to plan or discuss, asks for a gap analysis / design review / stress-test of a spec or design document, or when agent faces open decisions — including headless tasks where the deliverable is proposals and open questions as files. Instead of interrogating the user, the agent proposes concrete tagged answers in small verify-style rounds (or directly in the output documents when no user is in the loop), surfaces contradictions as questions, and asks only the questions that genuinely fork the design.

1.05x

Quality

75%

Does it follow best practices?

Impact

56%

1.05x

Average score across 1 eval scenario

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/fill-the-gaps/SKILL.md

Quality

Content

67%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.

A thorough, well-sequenced methodology document with concrete, actionable rules and clear validation checkpoints. Its main weakness is mild redundancy — the Key Principles section restates the Process — and length that could be tightened without losing signal.

Suggestions

Collapse the 'Key Principles' section into the Process steps or trim it to only principles not already covered, since most entries restate earlier rules and inflate the token budget.

Tighten the 'Core Inversion' framing: keep the inversion statement but drop the explanatory elaboration that restates it ('The review is brought to the user, in small bites...').

Make the implicit validation gates explicit where possible — e.g., restate 'Implementation starts only after every theme has had its veto pass' as a concrete checkpoint within the Process sequence rather than burying it under Marker hygiene.

Dimension	Reasoning	Score
Conciseness	The body is dense and substantive rather than padded with concepts Claude already knows, but the "Key Principles" section largely restates the Process steps and the rhetorical framing of "Core Inversion" could be trimmed, leaving it mostly efficient with some tightening needed.	3 / 5
Actionability	Concrete, specific guidance throughout for an instruction-only skill — exact literal `Assumption:`, tier tags (safe default / judgment call), "(builds on #N)", "3–7 proposals per round", ADR path `docs/adr/NNNN-slug.md`, and a copyable marker example block — with only minor gaps.	4 / 5
Workflow Clarity	A clearly sequenced 12-step Process with explicit checkpoints (veto pass before writing, re-ask-once, re-triage budget, implementation gated on every theme's veto pass) and feedback loops (veto cascade → rewrite → re-show); not a clean 5 because some validation gates are stated implicitly rather than as explicit verify/retry steps.	4 / 5
Progressive Disclosure	Well-organized into clearly headed sections with no nested or buried references and no bundle files to misnavigate; the doc is self-contained but runs long, so it sits just below the top anchor for a single-file skill.	4 / 5
	Total	15 / 20 Passed

Description

83%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.

A strong, well-structured description that clearly states what the skill does and when to use it with concrete, natural trigger phrases. It is specific and distinctive, with only minor gaps in action enumeration and slight overlap risk from the broadest triggers.

Dimension	Reasoning	Score
Specificity	Names the domain and several concrete actions — "proposes concrete tagged answers in small verify-style rounds", "surfaces contradictions as questions", "asks only the questions that genuinely fork the design" — but the actions are process-level rather than a comprehensive enumeration of capabilities, so it sits just below the top anchor.	4 / 5
Completeness	Explicitly answers both what ("Assumption-first planning and design gap analysis") and when with a concrete "Use when..." clause listing multiple specific trigger conditions, matching the top anchor.	5 / 5
Trigger Term Quality	Good coverage of natural trigger phrases a user would actually say — "plan", "discuss", "gap analysis", "design review", "stress-test of a spec or design document", "PLANNING mode", "open decisions" — with only minor synonym gaps keeping it below 5.	4 / 5
Distinctiveness Conflict Risk	Mostly a distinct niche (assumption-first design gap analysis, spec stress-testing) with clear triggers, but "plan or discuss" and "open decisions" are broad enough to risk minor overlap with general planning skills, so not a clean 5.	4 / 5
	Total	17 / 20 Passed

Validation

100%

Warnings & errors only

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: idrevnii/perks
Path: skills/fill-the-gaps/SKILL.md
Commit: 1674a50

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.