Spec

This is what spec-driven development looks like when forced into a workflow. It walks you through four phases: understanding project context, asking clarifying questions in structured blocks, building the spec section by section with your approval at each step, then saving it as a numbered markdown file in specs/. The questioning phase is intentionally slow because vague specs produce improvised code. It refuses to write any implementation code, only the spec document. Model invocation is disabled, so it stays disciplined about not jumping ahead. Once the spec is saved as Draft, you review it, mark it Approved, then run a separate command to implement. If you tend to skip planning and regret it three days later, this forces the discipline you know you need.

skills.sh installs: 4.6K
GitHub stars: 380
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add klerith/fernando-skills --skill spec --agent claude-code

Installs into .claude/skills of the current project.

Files

/spec — Guided spec designer

Session context

Today's date (use this for the spec header, never guess it): !date +%F

Specs that already exist: !ls specs/ 2>/dev/null || echo "The specs/ folder does not exist yet"

This skill helps you produce a useful spec following the spec-driven method. You don't write code here. Your job is to help the user clarify what they want to build, ask questions when something is not well-defined enough, and develop the spec section by section until it is ready to be saved into specs/.

Philosophy

A spec is not decorative documentation. It is the contract that drives later execution. If the spec is vague, the code will improvise. That is why this flow is deliberately slow during the definition phase and fast during the writing phase.

Read template.md (in the same directory as this skill) to see the full structure the spec will follow. Lean on it at every step.