>-
79
79%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly communicates specific capabilities, includes rich natural trigger terms, and explicitly defines both when to trigger and when not to trigger. The inclusion of negative trigger conditions is particularly strong for avoiding conflicts. The description is detailed yet focused, covering a distinct niche without being verbose.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: turning objectives into step-by-step plans, creating self-contained context briefs, adversarial review gate, dependency graph, parallel step detection, anti-pattern catalog, and plan mutation protocol. | 3 / 3 |
Completeness | Clearly answers both 'what' (turn objectives into step-by-step construction plans with context briefs, dependency graphs, etc.) and 'when' (explicit TRIGGER and DO NOT TRIGGER clauses with specific conditions). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'plan', 'blueprint', 'roadmap', 'complex multi-PR task', 'multiple sessions'. Also includes negative triggers ('just do it', 'single PR') which help with disambiguation. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche focused on multi-session, multi-agent engineering project planning. The explicit DO NOT TRIGGER clause for single-PR tasks and the specific features (adversarial review gate, plan mutation protocol) make it very unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides a good conceptual overview of the Blueprint pipeline and its key features, but falls short on actionability — it describes what the system does without specifying the concrete formats, templates, and decision rules Claude would need to execute it. There is significant redundancy between the 'How It Works' and 'Key Features' sections, and the installation/source sections consume tokens without adding operational value. Critical details like the plan file schema, anti-pattern catalog, review checklist, and mutation protocol are mentioned but never defined or linked.
Suggestions
Add a concrete example of a complete plan step showing the exact Markdown format including context brief, task list, verification commands, exit criteria, and dependency metadata.
Either inline or link to the anti-pattern catalog, review checklist, and mutation protocol — these are referenced but never defined, leaving Claude to improvise critical components.
Remove or drastically shorten the Installation, Requirements, and Source sections — these don't help Claude execute the skill and consume ~25% of the content.
Consolidate 'How It Works' and 'Key Features' into a single section to eliminate redundancy (e.g., cold-start execution, adversarial review, and parallel detection are described twice).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content includes some unnecessary sections like installation instructions (vendored standalone install, ECC install verification) and a 'Source' section that don't add actionable value. The 'When to Use' section partially repeats the trigger/no-trigger logic from the description. The 'How It Works' section is reasonably efficient but the 'Key Features' section largely restates what was already covered in 'How It Works'. | 2 / 3 |
Actionability | The skill describes what Blueprint does at a high level but lacks concrete, executable details. The examples show invocation syntax and sample output step titles, but there's no actual plan file format, no template structure, no concrete Markdown schema for steps, no example of what a 'context brief' or 'exit criteria' actually looks like. Claude would need to invent the plan format rather than follow a specification. | 2 / 3 |
Workflow Clarity | The 5-phase pipeline is clearly sequenced and the adversarial review gate serves as a validation checkpoint. However, the workflow lacks explicit validation/feedback loops within phases (e.g., what happens if Research finds no git? What if the step count exceeds 12? What if review finds critical issues — how many iterations?). The mutation protocol is mentioned but not specified. | 2 / 3 |
Progressive Disclosure | The content is structured with clear sections and headers, but it's somewhat monolithic — the anti-pattern catalog, plan mutation protocol, review checklist, and plan file format are all mentioned but never linked to separate reference files. These would benefit from being split out. No references to supplementary files are provided despite the skill's complexity warranting them. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents