Blueprint — скилл
Одиннадцать скиллов, которые ведут идею через требования, спецификацию и план к проверенному pull request с независимым ревью
- 426 ★ репозитория
- Последний коммит
- MIT
Расширенный доступ
Почему такой уровень
- `/task-to-pr` создает ветку, коммитит, отправляет изменения и открывает pull request в вашем репозитории
- `/review` запускает тесты и код изменения, поэтому недоверенные ветки открывайте с осторожностью
- Слияние pull request возможно, но только по вашей прямой просьбе или вызову `/codex-issue-coordinator`
Установка
- Работает в
В терминале, через SkillFoxx CLI
npx skillfoxx add skills/blueprintОпределит агенты на машине, покажет уровень доступа и зафиксирует версию.
Другие способы установки
Доступ и проверки
Как мы проверяемРасширенный доступИнструмент запускает код или ходит в сеть, а внешние данные только читает.
- `/task-to-pr` создает ветку, коммитит, отправляет изменения и открывает pull request в вашем репозитории
- `/review` запускает тесты и код изменения, поэтому недоверенные ветки открывайте с осторожностью
- Слияние pull request возможно, но только по вашей прямой просьбе или вызову `/codex-issue-coordinator`
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
Blueprint — набор из одиннадцати коротких скиллов Оуэна Льюиса для Claude Code и Codex. Они повторяют путь инженера от замысла до слияния: `/requirements` пишет `REQUIREMENTS.md` в виде пользовательских историй с проверяемыми исходами, `/architecture` создает `ARCHITECTURE.md` со схемой потока данных, `/spec` готовит спецификацию одной функции, `/plan` режет большую спецификацию на небольшие задачи. Скилл `/task-to-pr` реализует задачу, прогоняет проверки до зеленого состояния, запрашивает независимое ревью, дожидается CI и оставляет pull request открытым. Слияние выполняется только по вашей просьбе или при вызове `/codex-issue-coordinator`. `/review` читает и запускает код, ничего не меняя: сверяет изменение со спецификацией, пробует десять плохих входных данных и проверяет, что новые тесты падают при откате кода. Есть еще `/test`, `/improve`, `/architecture-review` и `/html-doc`. Скиллы вызываются только вами: в Claude Code это закреплено флагом `disable-model-invocation`, в Codex файлом `agents/openai.yaml`.
Для кого. Разработчикам и небольшим командам, которые поручают агенту целые функции и хотят, чтобы каждая заканчивалась тестами, независимым ревью и аккуратным pull request.
Подходит, если
- Новый продукт начинается с идеи, и сначала нужен документ с пользовательскими историями и проверяемыми критериями
- Функция требует решений заранее, и вы просите спецификацию с диаграммой и техническим дизайном
- Готовая спецификация или задача должна стать pull request, прошедшим проверки и CI
- Накопилась пачка задач в GitHub, и Codex должен разобрать каждую в отдельном pull request
- Изменение уже написано, и ему нужен свежий взгляд без правок и коммитов
Не подходит, если
- Нужна быстрая правка без процесса: фраза «исправь баг» запускает обычное поведение агента, а полный путь включают явным вызовом
- В репозитории нет тестов и CI, а скиллы ждут проверок: сначала настройте проверку по руководству `guides/verification.md`
- Нужен трекер задач или система релизов: автор говорит, что проект не заменяет ни трекер, ни рантайм агента, ни выпуск версий
- Ревью должно идти без другого агента: скилл `/review` без постороннего ревьюера сообщает, что проверка заблокирована
Пример запроса к агенту
Используй /requirements для CRM, которая помогает небольшой консалтинговой фирме вести лиды и напоминанияОграничения
Скиллы короткие и опираются на ваши проверки: качество результата зависит от тестов, линтеров и CI в репозитории. Для независимого ревью нужен второй агент, например `codex exec` или `claude -p` в режиме чтения, или свежий субагент. Без них `/review` останавливается. Слияние pull request возможно только при просьбе слить или при вызове `/codex-issue-coordinator`, и только при зеленом CI, одобренном ревью и соблюдении защиты веток. Выпуск и деплой скиллы не выполняют. Каталог `examples/` показывает результат на одном учебном проекте, потребностей вашего стека он не покрывает.
Как отключить. Удалите папки скиллов из `.agents/skills/` и `.claude/skills/`.
Частые вопросы
В какой последовательности вызывать скиллы Blueprint?
Для нового продукта: `/requirements`, `/architecture`, `/spec`, затем `/plan` и `/task-to-pr`. Маленькую правку можно отдать сразу в `/task-to-pr`, этапы можно пропускать.
Почему `/task-to-pr` не сливает pull request сам?
По правилам скилла PR остается открытым. Слияние разрешено при просьбе вроде «и слей» или при вызове `/codex-issue-coordinator` и только при зеленом CI и одобренном ревью.
Что проверяет `/review` кроме соответствия спецификации?
Скилл запускает тесты, вызывает код через настоящую точку входа, пробует десять плохих входных данных и откатывает код за главными тестами, чтобы убедиться, что они падают. Отдельно смотрит безопасность там, где есть ввод, SQL или оболочка.
Работает ли Blueprint только в Claude Code?
Нет, автор подтверждает работу в Claude Code и Codex. В Claude Code закрытие от самовольного запуска задает `disable-model-invocation`, в Codex это `agents/openai.yaml`.
Где посмотреть результат работы скиллов?
В папке `examples/consulting-crm` лежат `REQUIREMENTS.md`, `ARCHITECTURE.md`, спецификация `docs/capture-lead/spec.md` и план для учебной CRM. Руководства `guides/` разбирают проверку и выбор скилла.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
СкиллыСкилл расспрашивает про проект и пишет requirements.md, design.md и tasks.md, чтобы Claude Code и Cursor работали по одному плану
lencx skills
lencx-skills
Два скилла для Claude Code и Codex: keel решает вопросы архитектуры, coding-protocol держит правки кода в границах задачи
kyy-logs code-review-skill
code-review-skill
Скилл ревью кода: четыре независимых прохода, замечания с доказательствами и допуск к слиянию из JSON
Goal Workflow
goal-workflow
19 скиллов для Claude Code: PRD, спецификация, задачи в GitHub Issues, пакетная реализация с ревью и слияние pull request, плюс рефакторинг и диаграммы
Плагин Claude Code для разработки по большой спецификации: требования с доказательствами, ходячий скелет и спринты с аудитом
22 скилла на весь цикл проекта в Claude Code: от настройки и границ задачи до код-ревью, проверки перед пушем и заметок сессий.
Сравнение с похожими
Карточки с тем же главным запросом: чем они отличаются.
| Инструмент | Официальный | Звезды репозитория | Главное отличие |
|---|---|---|---|
| Blueprint (эта карточка) | нет | 426 | |
| Spec Kit | нет | 147 764 | CLI GitHub с шаблонами спецификаций, а здесь короткие скиллы и этап независимого ревью |
| OpenSpec | нет | 74 038 | система спецификаций с отдельными папками изменений, а здесь путь доходит до pull request и CI |
| BMad Method | нет | 55 033 | метод с набором ролей-агентов, а здесь одиннадцать скиллов по этапам без ролей |
Коротко о README
Описание сначала излагает взгляд автора: чем умнее модели, тем проще скиллы, и каждому нужны шаблон, критерий доказательства и второй взгляд. Затем идут быстрый старт из трех шагов, схема «проектирование, план, сборка, проверка», таблицы скиллов по этапам, правило явного вызова и ссылки на руководства.
Бейдж для README
Исходный SKILL.md
--- name: task-to-pr description: "Delivers a spec, issue, or decided task as a pull request that passes its checks, CI, and an independent review. Leaves the PR open unless merging was explicitly authorized." user-invocable: true argument-hint: "<specs, tasks, issues, PRs, or milestone>" disable-model-invocation: true --- # Task to PR Deliver each task as one focused pull request that passes CI and an independent review. The spec, issue, or task is the ticket; do not write another one. When a step names [test](../test/SKILL.md), [review](../review/SKILL.md), [spec](../spec/SKILL.md), or [plan](../plan/SKILL.md), read that file and follow it. ## Steps 1. Read the ticket, the repository instructions, and the code it touches. If a decision that changes behavior is missing, ask the user or return to spec. Split large work with plan. 2. Branch from the latest default branch, or continue the existing branch and PR. 3. Build the change with tests. Update `REQUIREMENTS.md`, `ARCHITECTURE.md`, or the spec if the change makes them wrong. 4. Follow test until every check passes. 5. Commit with a Conventional Commit message, push, and open the PR. Use the repository's PR template, or What, Why, What changed, Verification, and Risk if it has none. 6. Follow review. Wait for CI and any review bot on the latest commit. 7. Fix each real finding and failure, and reply on each review thread with the fix or the reason for no change. Go back to step 4. After three rounds on the same problem, stop and report it. 8. Link the PR and its proof in the ticket. ## Dependent tasks Start a task that depends on another once that task has an open PR with an `Approve` review. Branch from it, and update your branch when it changes or merges. ## Merge Leave the PR open. Merge only when the user asks (for example "/task-to-pr and merge it") or `/codex-issue-coordinator` was invoked by name, and only when: - CI passes on the latest commit. - The latest review verdict is `Approve` and no finding is open. - Every approval the repository requires is given. - The PR is up to date with its base. Never bypass branch protection. After merging, update the ticket and delete any worktree you created. Merging never includes deploying or releasing. ## Return Each PR link with its check results, review verdict, CI state, and anything blocked.