Fernando Skills

Два скилла для разработки от спецификации: /spec задает вопросы и сохраняет документ в specs/, /spec-impl реализует утвержденную спецификацию по шагам

327 ★ репозитория
Последний коммит 8 окт. 2026
MIT

Скилл

klerith/fernando-skillsАвтор:Fernando Herrera

Установка

Работает в: Claude Code
Cursor
Codex
Koda
Coddy

В терминале, через SkillFoxx CLI

npx skillfoxx add skills/fernando-skills

Определит агенты на машине, покажет уровень доступа и зафиксирует версию.

Другие способы установки

Доступ и проверки

Как мы проверяем

Расширенный доступИнструмент запускает код или ходит в сеть, а внешние данные только читает.

/spec-impl правит файлы проекта и создает ветку Git, а при чистке рабочего дерева ему разрешены `git stash` и `git checkout`
/spec пишет Markdown-файлы в specs/ и читает файл памяти проекта
Установщик для Cursor, Codex и Antigravity пишет в .cursor/rules, AGENTS.md и каталоги скиллов проекта

Это чужой код. Посмотрите файлы в репозитории перед установкой.

Что делает

Fernando Skills добавляет агенту два слэш-скилла для разработки от спецификации: главным рабочим документом становится спецификация, а код следует за ней. Оба скилла запускаются только командой пользователя, в заголовке SKILL.md стоит `disable-model-invocation`, поэтому агент сам их не вызывает. `/spec` читает файл памяти проекта (первый из найденных: CLAUDE.md, AGENTS.md, GEMINI.md или README.md) и список папки specs/. Затем задает вопросы блоками по три–пять: объем работ, данные, интеграции, хранение, состояния интерфейса, что может сломаться. Когда понятно, какие файлы изменятся, каким будет первый и последний шаг и как проверить результат, скилл сохраняет specs/NN-slug.md со статусом `Draft`. В документе цель одним предложением, объем с явным разделом «не входит», модель данных, пронумерованный план, критерии приемки и принятые и отброшенные решения. Если файла specs/.spec-config.yml еще нет, скилл создает его. `/spec-impl NN-slug` находит спецификацию и останавливается, если ее статус не означает «утверждена». Затем создает ветку spec-NN-slug, показывает цель, объем, план и критерии и ждет согласия. После него агент реализует план по шагам, после каждого шага показывает изменения и ждет подтверждения. Коммитов скилл не делает.

Для кого. Для разработчиков, которые ведут крупные фичи с Claude Code, Cursor или Codex и хотят зафиксировать решения в документе до первой строки кода, а потом проверять работу агента по небольшим шагам.

Подходит, если

Задача затрагивает больше двух файлов или займет не одну сессию с агентом
В работе есть решения, которые дорого откатывать: схема данных, формат файла, контракт API
Нужен письменный контракт, на который потом сошлются другая спецификация, скилл или хук
Вы хотите смотреть изменения шаг за шагом, а не один большой diff в конце
Через неделю вы забудете, почему приняли такое решение, и записи о нем должны остаться в репозитории

Не подходит, если

Нужно поправить одну ошибку или сделать механический рефакторинг: хватит обычного запроса агенту
Задача умещается в один запрос и понятна с первого прочтения, спецификация добавит лишнюю работу
Вы исследуете идею и сами еще не знаете решения: скилл рассчитан на выполнение уже принятых решений
Нужен готовый набор шаблонов и CLI для инициализации проекта: такое делает Spec Kit

Пример запроса к агенту

/spec экспорт заказов в CSV с выбором периода. Сначала задай мне вопросы, потом сохрани спецификацию в specs/

Ограничения

Релизы нулевой серии, последний v0.1.2. Тестов и готовых примеров спецификаций в репозитории нет, есть только шаблон template.md.
Cursor и Codex не читают поля `argument-hint` и `disable-model-invocation` из заголовка. Установщик отбрасывает их и оставляет текст, поэтому вызов другой: в Cursor скиллы доступны как @spec и @spec-impl.
Утверждает спецификацию человек: статус `Approved` меняется вручную, и пока его нет, /spec-impl не стартует.
/spec-impl по умолчанию сам создает ветку. Если рабочее дерево не пустое, он сначала спрашивает, что делать. Чтобы подтверждать создание ветки каждый раз, поставьте `AutoCreateBranch: false` в specs/.spec-config.yml.
Тексты скиллов написаны на английском, README на английском и испанском; язык ответов агент берет из первого запроса.
Лицензия MIT.

Как отключить. Выполните `npx skills@latest remove Klerith/fernando-skills`. Если ставили вручную, удалите папки spec и spec-impl из ~/.claude/skills или .claude/skills. Установщик для других агентов оставляет файлы .cursor/rules/spec.mdc и spec-impl.mdc, блок ## Skills в AGENTS.md и копии в .codex/skills или .antigravity/skills: удалите их сами. Папка specs/ с готовыми спецификациями останется в проекте.

Частые вопросы

Какие значения статуса принимает /spec-impl?

Скилл ищет строку статуса в начале файла и принимает `Approved` и его аналоги на других языках: `Aprobado`, `Aprovado`, `Approuvé`, `Genehmigt`, `Approvato`. Черновик, ревью, «реализовано» и «устарело» останавливают работу с сообщением об ошибке, а если значение непонятно, скилл спрашивает пользователя.

На каком языке будет спецификация?

Ответы идут на языке первого запроса. Перед записью /spec читает минимум две последние спецификации из specs/ и повторяет их язык, названия разделов и слова для статусов, чтобы новый документ совпал с прежними.

Что делать, если посреди реализации появилась новая идея?

По правилам из документации нужно вернуться к спецификации: остановиться, обновить ее, выйти из режима планирования и продолжить. Идеи, которых нет в спецификации, /spec-impl не берет в эту ветку и предлагает записать в следующую.

Из чего состоит полезная спецификация?

Из шести частей: цель в одном предложении, объем вместе с тем, что не входит, модель данных с конкретными именами, упорядоченный план, где каждый шаг оставляет систему рабочей, проверяемые критерии приемки и принятые решения с причинами. Шаг больше 30–50 строк кода автор советует делить.

Нужно ли для скиллов заводить папку specs вручную?

При установке вручную автор советует создать ее командой `mkdir specs`. Сам /spec при сохранении документа берет следующий номер из ее содержимого, а если папки нет, начинает с 01 и добавляет файл .spec-config.yml.

Обсуждение

Вопросов и отзывов пока нет.

Скиллы

Spec Kit

Выбор редакции

Набор GitHub для разработки от спецификации: CLI specify ставит в проект команды и скиллы для агента, от принципов до реализации

CLIРасширенный доступ142,5 тыс.

Spec-Driven Develop

Плагин из трех скиллов для крупных задач разработки: анализ проекта, разбивка на фазы с задачами в GitHub Issues, параллельные агенты и ревью кода

ПлагинШирокий доступ991

Allium

Язык поведенческих спецификаций и набор скиллов: агент ведет .allium-файл рядом с кодом, сверяет с ним реализацию и генерирует тесты

СкиллРасширенный доступ518

OpenSpec

Выбор редакции

Разработка по спецификациям для кодовых агентов: сначала предложение, требования, дизайн и задачи, потом код

ВоркфлоуРасширенный доступ72,8 тыс.

cc-sdd

Разработка по спецификациям в стиле Kiro: набор скиллов ведет задачу от идеи через требования и дизайн к автономной реализации

СкиллРасширенный доступ3,7 тыс.

cavekit

Плагин для Claude Code: разработка через спецификацию по одному файлу SPEC.md, цикл из семи команд без под-агентов

ПлагинРасширенный доступ1,2 тыс.

Сравнение с похожими

Записи с тем же главным запросом: чем они отличаются.

Запись	Официальный	Звезды репозитория	Главное отличие
Fernando Skills (эта запись)	нет	327
Spec Kit	нет	142 487	полный набор GitHub с CLI specify, принципами проекта и шаблонами на каждый этап
cc-sdd	нет	3 736	17 скиллов в стиле Kiro с отдельным ревью и отладкой на этапе реализации

Коротко о README

Описание на английском и испанском начинается с таблицы двух команд и установки одной строкой. Дальше идет объяснение метода: чем рабочая спецификация отличается от документа «перед кодом», шесть шагов процедуры на схеме, правила, которые соблюдают редко, и два столбца о том, когда спецификация нужна, а когда нет. Завершают три способа установки и разбор фаз каждого скилла с примером полного цикла.

Бейдж для README

Исходный 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

Сообщить о проблеме