spec-feature

Spec a new feature — recall architecture knowledge, create a spec document, build an implementation plan, and break into tasks.

Quality

60%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/spec-feature/SKILL.md

Quality

Discovery

42%

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 effectively lists a concrete multi-step workflow (recall architecture, create spec, build plan, break into tasks), giving good specificity. However, it lacks an explicit 'Use when...' clause, which significantly hurts completeness and makes it harder for Claude to know exactly when to select this skill. Trigger term coverage is moderate but could benefit from common synonyms like 'design doc', 'RFC', or 'technical specification'.

Suggestions

Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to spec out a new feature, write a design document, create an RFC, or plan implementation work.'

Include common trigger term variations such as 'specification', 'design doc', 'RFC', 'PRD', 'technical design', 'plan a feature', 'break down work'.

Clarify what 'recall architecture knowledge' means — e.g., 'references existing codebase architecture and conventions' — to reduce ambiguity and improve distinctiveness.

Dimension	Reasoning	Score
Specificity	Lists multiple specific concrete actions: recall architecture knowledge, create a spec document, build an implementation plan, and break into tasks. These are distinct, actionable steps in a workflow.	3 / 3
Completeness	Describes what the skill does (spec a feature, create spec document, build plan, break into tasks) but has no explicit 'Use when...' clause or equivalent trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'when' is only weakly implied by the opening phrase, making this closer to a 1.	1 / 3
Trigger Term Quality	Includes some natural terms like 'spec', 'feature', 'implementation plan', and 'tasks', but misses common variations users might say such as 'specification', 'design doc', 'technical design', 'RFC', 'PRD', 'plan a feature', or 'break down work'.	2 / 3
Distinctiveness Conflict Risk	The combination of spec creation + architecture recall + task breakdown is somewhat distinctive, but terms like 'feature', 'tasks', and 'implementation plan' could overlap with general project management, task tracking, or architecture documentation skills.	2 / 3
	Total	8 / 12 Passed

Implementation

77%

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

This is a well-structured workflow skill with strong actionability and clear sequencing. The 8-step process is logically ordered with explicit validation (user review), retention, and handoff steps, plus clear guardrails against premature implementation. Minor weaknesses include some unnecessary guidance Claude already knows and the inline spec template adding bulk, though the template's concreteness is a strength.

Suggestions

Extract the spec document markdown template into a separate `SPEC_TEMPLATE.md` file and reference it, reducing the inline bulk while keeping the template concrete and reusable.

Remove guidance Claude inherently knows, such as 'If arguments are vague, ask clarifying questions before proceeding' — this is standard assistant behavior.

Dimension	Reasoning	Score
Conciseness	Generally efficient but includes some unnecessary elaboration. The preamble section with ANSI escape codes and ticket detection is well-specified, but some steps like 'Parse the feature request' include guidance Claude already knows (e.g., 'If arguments are vague, ask clarifying questions'). The spec template is lengthy but justified as a concrete artifact.	2 / 3
Actionability	Highly actionable with concrete file paths (`docs/specs/<feature-name>.md`), specific tool invocations (`recall`, `retain`, `mark_chapter`, `devflow:phase-handoff`), exact CLI commands (`git branch --show-current`, `printf` escape), and a complete markdown template that is copy-paste ready.	3 / 3
Workflow Clarity	Clear 8-step sequential workflow with explicit boundaries (do NOT start implementation, do NOT auto-invoke next phase). Includes a validation/review checkpoint at step 6 with specific review questions, a retention step at step 7, and a well-defined handoff protocol at step 8 with explicit context cleanup boundary.	3 / 3
Progressive Disclosure	The skill references external tools and skills (`devflow:phase-handoff`, `superpowers:writing-plans`, Hindsight `recall`/`retain`) but no bundle files are provided to support these references. The spec template is inlined rather than referenced from a separate template file, which makes the skill longer than necessary. However, the single-file structure is reasonable for a workflow skill.	2 / 3
	Total	10 / 12 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 — 11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository: AndreJorgeLopes/devflow
Commit: b0b1bb6

Reviewed: 7 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.