Fernando Skills
Two skills for spec-driven development: /spec asks questions and saves a document to specs/, /spec-impl implements an approved spec step by step
- 329 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- /spec-impl edits project files and creates a Git branch, and its allowed tools include `git stash` and `git checkout`
- /spec writes Markdown files into specs/ and reads the project memory file
- The installer for Cursor, Codex and Antigravity writes into .cursor/rules, AGENTS.md and the project skill folders
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/fernando-skillsDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- /spec-impl edits project files and creates a Git branch, and its allowed tools include `git stash` and `git checkout`
- /spec writes Markdown files into specs/ and reads the project memory file
- The installer for Cursor, Codex and Antigravity writes into .cursor/rules, AGENTS.md and the project skill folders
This is third-party code. Review the repository files before installing.
What it does
Fernando Skills adds two slash skills for spec-driven development: the spec is the main working document and the code follows it. Both run only on the user's command, since `disable-model-invocation` is set in the SKILL.md header, so the agent never calls them on its own. `/spec` reads the project memory file (the first one found: CLAUDE.md, AGENTS.md, GEMINI.md or README.md) and lists the specs/ folder. It then asks questions in blocks of three to five: scope, data, integrations, persistence, interface states, what could break. Once it is clear which files change, what the first and last step are and how to verify the result, the skill saves specs/NN-slug.md with the status `Draft`. The document holds a one-sentence goal, a scope with an explicit "not in scope" section, a data model, a numbered plan, acceptance criteria and the decisions taken and discarded. If specs/.spec-config.yml does not exist yet, the skill creates it. `/spec-impl NN-slug` finds the spec and stops if its status does not mean "approved". Then it creates the branch spec-NN-slug, shows the goal, scope, plan and criteria and waits for a go-ahead. After that the agent implements the plan step by step, shows the changes after each step and waits for confirmation. The skill never commits.
Who it is for. For developers who build larger features with Claude Code, Cursor or Codex and want to pin decisions down in a document before the first line of code, then review the agent one small step at a time.
Good fit when
- The task touches more than two files or will take more than one session with the agent
- The work includes decisions that are expensive to revert: a data schema, a file format, an API contract
- You need a written contract that another spec, skill or hook will refer to later
- You want to review changes step by step instead of one large diff at the end
- In a week you will forget why you picked this solution, and the record of it should stay in the repository
Not a fit when
- You need to fix one bug or do a mechanical refactor: a plain request to the agent is enough
- The task fits in one prompt and is clear on first read, so a spec only adds paperwork
- You are exploring an idea and do not know the decision yet: the skill is built to carry out decisions already made
- You want a ready template set and a CLI that initializes the project: Spec Kit does that
Example request
/spec export orders to CSV with a period picker. Ask me questions first, then save the spec to specs/Limitations
- Releases are in the zero series, the latest is v0.1.2. The repository has no tests and no finished example specs, only the template.md template.
- Cursor and Codex do not read the `argument-hint` and `disable-model-invocation` header fields. The installer drops them and keeps the body, so the invocation differs: in Cursor the skills are available as @spec and @spec-impl.
- A person approves the spec: the `Approved` status is set by hand, and /spec-impl will not start without it.
- /spec-impl creates the branch on its own by default. If the working tree is not clean, it asks what to do first. To confirm every branch creation, set `AutoCreateBranch: false` in specs/.spec-config.yml.
- The skill texts are in English and the README in English and Spanish; the agent takes its reply language from the first prompt.
- MIT license.
How to disable. Run `npx skills@latest remove Klerith/fernando-skills`. If you installed by hand, delete the spec and spec-impl folders from ~/.claude/skills or .claude/skills. The installer for other agents leaves .cursor/rules/spec.mdc and spec-impl.mdc, the ## Skills block in AGENTS.md and copies in .codex/skills or .antigravity/skills: remove them yourself. The specs/ folder with finished specs stays in the project.
FAQ
Which status values does /spec-impl accept?
The skill looks for the status line near the top of the file and accepts `Approved` and its equivalents in other languages: `Aprobado`, `Aprovado`, `Approuvé`, `Genehmigt`, `Approvato`. Draft, in review, implemented and obsolete stop the run with an error message, and when the value is unclear the skill asks the user.
What language will the spec be in?
Replies follow the language of the first prompt. Before writing, /spec reads at least the two latest specs in specs/ and copies their language, section headings and status words so the new document matches the earlier ones.
What if a new idea comes up mid-implementation?
The documentation says to go back to the spec: stop, update it, leave plan mode and continue. /spec-impl does not implement out-of-scope ideas on that branch and suggests recording them in the next spec.
What does a useful spec contain?
Six parts: a one-sentence goal, scope including what is out, a data model with concrete names, an ordered plan where every step leaves the system working, verifiable acceptance criteria and the decisions taken with their reasons. The author advises splitting any step over 30 to 50 lines of code.
Do I need to create the specs folder by hand?
For a manual install the author suggests creating it with `mkdir specs`. When saving, /spec takes the next number from the folder contents, and if the folder is missing it starts at 01 and adds the .spec-config.yml file.
Discussion
No questions or reviews yet.
Related
SkillsGitHub toolkit for spec-driven development: the specify CLI adds agent commands and skills to a project, from principles to implementation
A plugin with three skills for large development work: project analysis, phased tasks tracked as GitHub Issues, parallel agents and code review
A behavioural specification language and skills: the agent keeps an .allium file beside your code, reconciles it with the code and generates tests
Spec-driven development for coding agents: proposal, requirements, design and tasks come before any code
Kiro-style spec-driven development: a skill set that takes work from idea through requirements and design to autonomous implementation
A Claude Code plugin: spec-driven development over a single SPEC.md file, a loop of seven commands with no sub-agents
Comparison with similar tools
Entries that share the main search query, and how they differ.
README in short
The description, in English and Spanish, opens with a table of the two commands and a one-line install. It then explains the method: how a working spec differs from a document written before coding, the six steps of the procedure on a diagram, the rules few people follow, and two columns on when a spec is needed and when it is not. Three install routes and a phase-by-phase breakdown of each skill with a full-cycle example close it.
README badge
Original SKILL.md
--- name: spec description: Designs and develops specs following the spec-driven method. Asks clarifying questions before proposing structure, and builds the spec section by section. Use it when starting a large feature, before writing code. disable-model-invocation: true argument-hint: 'short feature description or requirement' allowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(ls:*), Bash(cat:*), Bash(date:*) --- # /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. ## Command flow - Follow the four phases in order. **Never skip Phase 2** — the questions are the whole point. If the user wants to go faster, remind them that the cost of a bad spec gets paid later in code. (Phase 3 does have a fast path once Phase 2 is genuinely complete; see below.) - Your replies must be in the same language as the initial prompt. E.g.: if the initial prompt is in Spanish, your replies must be in Spanish; if it is in English, your replies must be in English. ### Phase 1 — Understand the context Before asking questions about the feature, make sure you have project context: 1. Read the project-memory file, if one exists. Try in order and stop at the first hit: `CLAUDE.md`, `AGENTS.md`, `GEMINI.md`, `README.md`. This adapts the skill to whichever agent is running it (Claude Code, Codex, Gemini CLI, etc.). 2. Look at the `specs/` listing in the session context above to see which specs already exist and how they are numbered. 3. If previous specs exist, read at least the two most recent ones to pick up the project's conventions — including the **language** they are written in and the exact wording they use for states and section headings. A new spec must match the existing ones. If the `$ARGUMENTS` argument comes in empty, ask the user for an initial **single-sentence** description of what they want to build. If the description does not fit in one sentence, that is the first signal that the feature is too big — suggest splitting it before continuing. ### Phase 2 — Clarify through questions