Blueprint skill
Eleven skills that take an idea through requirements, spec and plan to a verified pull request with an independent review
- 426 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- `/task-to-pr` creates a branch, commits, pushes and opens a pull request in your repository
- `/review` runs the tests and the change's code, so open untrusted branches with care
- Merging a pull request is possible, but only on your direct request or when `/codex-issue-coordinator` is invoked
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/blueprintDetects 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.
- `/task-to-pr` creates a branch, commits, pushes and opens a pull request in your repository
- `/review` runs the tests and the change's code, so open untrusted branches with care
- Merging a pull request is possible, but only on your direct request or when `/codex-issue-coordinator` is invoked
This is third-party code. Review the repository files before installing.
What it does
Blueprint is a set of eleven short skills by Owain Lewis for Claude Code and Codex. They follow an engineer's path from idea to merge: `/requirements` writes `REQUIREMENTS.md` as user stories with checkable outcomes, `/architecture` creates `ARCHITECTURE.md` with a data flow diagram, `/spec` prepares a one-feature specification, and `/plan` slices a big spec into small tasks. `/task-to-pr` implements a task, runs checks until they pass, asks for an independent review, waits for CI and leaves the pull request open. Merging happens only when you ask or when `/codex-issue-coordinator` is invoked. `/review` reads and runs code without changing it: it checks the change against the spec, tries ten bad inputs and confirms that new tests fail when the code is reverted. There are also `/test`, `/improve`, `/architecture-review` and `/html-doc`. The skills run only when you call them: Claude Code enforces this with the `disable-model-invocation` flag, Codex with the `agents/openai.yaml` file.
Who it is for. Developers and small teams who hand whole features to an agent and want each to end with tests, an independent review and a clean pull request.
Good fit when
- A new product starts as an idea and first needs a document of user stories and checkable criteria
- A feature calls for decisions up front and you ask for a spec with a diagram and technical design
- A finished spec or task has to become a pull request that passes checks and CI
- A batch of GitHub issues piled up and Codex should handle each in its own pull request
- A change is already written and needs a fresh read with no edits or commits
Not a fit when
- You want a quick fix without ceremony: "fix this bug" gives the agent's normal behavior, and the full flow needs an explicit call
- The repository has no tests or CI while the skills expect checks: first set up verification per `guides/verification.md`
- You need an issue tracker or release system: the author says the project replaces neither a tracker, an agent runtime nor releases
- Review has to run without a second agent: `/review` without an outside reviewer reports that it is blocked
Example request
Use /requirements for a CRM that helps a small consulting firm track leads and follow-upsLimitations
The skills are short and rely on your checks: result quality depends on tests, linters and CI in the repository. Independent review needs a second agent, such as `codex exec` or `claude -p` in read-only mode, or a fresh subagent. Without them `/review` stops. A pull request merges only when you ask for a merge or invoke `/codex-issue-coordinator`, and only with green CI, an approved review and branch protection respected. The skills do not release or deploy. The `examples/` directory shows one demo project, not your stack's needs.
How to disable. Delete the skill folders from `.agents/skills/` and `.claude/skills/`.
FAQ
In what order should I call the Blueprint skills?
For a new product: `/requirements`, `/architecture`, `/spec`, then `/plan` and `/task-to-pr`. A small fix can go straight to `/task-to-pr`, and any stage can be skipped.
Why doesn't `/task-to-pr` merge the pull request itself?
By the skill's rules the PR stays open. Merging is allowed when you ask, for example "and merge it", or when `/codex-issue-coordinator` is invoked, and only with green CI and an approved review.
What does `/review` check beyond the spec?
The skill runs the tests, calls the code through its real entry point, tries ten bad inputs and reverts the code behind the main tests to confirm they fail. It also checks security wherever there is input, SQL or a shell.
Does Blueprint work only in Claude Code?
No, the author confirms Claude Code and Codex. In Claude Code the `disable-model-invocation` flag blocks self-launch, in Codex it is `agents/openai.yaml`.
Where can I see the skills' output?
The `examples/consulting-crm` folder holds `REQUIREMENTS.md`, `ARCHITECTURE.md`, the `docs/capture-lead/spec.md` spec and a plan for a demo CRM. The `guides/` folder covers verification and skill choice.
Discussion
No questions or reviews yet.
Related
SkillsA skill that interviews you and writes requirements.md, design.md and tasks.md so Claude Code and Cursor work from one plan
lencx skills
lencx-skills
Two skills for Claude Code and Codex: keel works through architecture questions, coding-protocol keeps code edits inside the task
kyy-logs code-review-skill
code-review-skill
A code review skill with four independent probes, evidence-backed findings and a merge gate derived from JSON
Goal Workflow
goal-workflow
19 skills for Claude Code: PRD, spec, GitHub Issues, batch implementation with review and pull request merging, plus refactoring and diagrams
A Claude Code plugin for large specs: requirements with proof obligations, a walking skeleton and audited sprints
22 skills for the full Claude Code project lifecycle: setup and task scope, code review, pre-push checks and session notes.
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Repository stars | Main difference |
|---|---|---|---|
| Blueprint (this card) | no | 426 | |
| Spec Kit | no | 148,171 | GitHub's CLI with spec templates, while this has short skills and an independent review stage |
| OpenSpec | no | 74,038 | a spec system with separate change folders, while this path reaches a pull request and CI |
| BMad Method | no | 55,080 | a method with a cast of role agents, while this is eleven stage skills with no roles |
README in short
The description opens with the author's view: the smarter the models, the simpler the skills, and each needs a template, a standard of proof and a second pair of eyes. Then come a three-step quick start, a design-plan-build-verify map, tables of skills by stage, the explicit-invocation rule and links to guides.
README badge
Original 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.