Guides

Name: Guides
Author: owainlewis

ASecurity

Blueprint has twelve skills. New projects start with `/requirements` and `/architecture`, maintained as long-running documents. New features start with `/spec`, then `/task-to-pr` or `/factory`. Choose additional skills when they improve decisions or proof. | Result | Skill | Output | |---|---|---| | System product needs | [`/requirements`](../skills/requirements/SKILL.md) | Root `REQUIREMENTS.md` | | Intended system design and data model | [`/architecture`](../skills/architecture/SKILL.md) |...

412 stars

0 votes

0 copies

0 views

Added 10/6/2026

developmentgit

Security Analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned 10/6/2026

$npx -y skills add owainlewis/blueprint --skill guides --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Guides?

Add the live security badge to your README — it updates automatically with every re-scan.

[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/owainlewis-guides/badge)](https://www.skillsdirectory.com/skills/owainlewis-guides)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro

Files

README.md

# Choosing the right Blueprint skill

Blueprint has twelve skills. New projects start with `/requirements` and `/architecture`, maintained as long-running documents. New features start with `/spec`, then `/task-to-pr` or `/factory`. Choose additional skills when they improve decisions or proof.

| Result | Skill | Output |
|---|---|---|
| System product needs | [`/requirements`](../skills/requirements/SKILL.md) | Root `REQUIREMENTS.md` |
| Intended system design and data model | [`/architecture`](../skills/architecture/SKILL.md) | Root `ARCHITECTURE.md` |
| One feature or major change | [`/spec`](../skills/spec/SKILL.md) | `docs/<feature-slug>/spec.md`, or the supplied source |
| Independent technical proposal review | [`/architecture-review`](../skills/architecture-review/SKILL.md) | Findings and verdict |
| Several ready delivery tasks | [`/plan`](../skills/plan/SKILL.md) | Tasks in chat; tracker tickets only when asked |
| Passing open pull requests | [`/task-to-pr`](../skills/task-to-pr/SKILL.md) | PRs with tests, independent review, CI, and repairs complete |
| Delivery through merge | [`/factory`](../skills/factory/SKILL.md) | Verified merges, or explicit blockers |
| Large GitHub issue batch in Codex | [`/codex-issue-coordinator`](../skills/codex-issue-coordinator/SKILL.md) | Visible workers and checked PRs |
| Acceptance proof | [`/test`](../skills/test/SKILL.md) | Pass, fail, or unverified evidence |
| Independent implementation review | [`/review`](../skills/review/SKILL.md) | Findings and verdict |
| Simpler code with the same behavior | [`/improve`](../skills/improve/SKILL.md) | Focused change and preservation proof |
| HTML reading view | [`/html-doc`](../skills/html-doc/SKILL.md) | Verified static HTML |

## System documents and feature specs

Requirements define what users need. Architecture defines how the whole system
should work. A feature spec defines one coherent change and its proof. Keep
shared rules in the root documents and link to them from specs.

A spec is the ticket, whether it is Markdown or a GitHub issue. Do not create a
second product spec, technical spec, or tracker item for the same definition.
One spec may produce several tasks and PRs. Small, decided work can use a task
description and checks without formal system documents or a feature spec.

## Delivery authority

`/task-to-pr` includes the full test, independent review, CI, and repair loop.
It leaves passing PRs open unless the user grants merge authority.

Explicit `/factory` use grants authority to merge its supplied work after all
gates and required approvals pass. It reuses `/task-to-pr`; it does not lower the
quality standard. Explicit `/codex-issue-coordinator` use grants the same scoped
authority for its supplied batch. Automatic skill selection grants neither.

Neither merge workflow authorizes deployment or release publication. Report
missing decisions, approvals, or checks as blockers.

Attribution

owainlewis

View source See grades on GitHub More from owainlewis →

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

# Choosing the right Blueprint skill Blueprint has twelve skills. New projects start with `/requirements` and `/architecture`, maintained as long-running documents. New features start with `/spec`, then `/task-to-pr` or `/factory`. Choose additional skills when they improve decisions or proof. | Result | Skill | Output | |---|---|---| | System product needs | [`/requirements`](../skills/requirements/SKILL.md) | Root `REQUIREMENTS.md` | | Intended system design and data model | [`/architecture`](../skills/architecture/SKILL.md) | Root `ARCHITECTURE.md` | | One feature or major change | [`/spec`](../skills/spec/SKILL.md) | `docs/<feature-slug>/spec.md`, or the supplied source | | Independent technical proposal review | [`/architecture-review`](../skills/architecture-review/SKILL.md) | Findings and verdict | | Several ready delivery tasks | [`/plan`](../skills/plan/SKILL.md) | Tasks in chat; tracker tickets only when asked | | Passing open pull requests | [`/task-to-pr`](../skills/task-to-pr/SKILL.md) | PRs with tests, independent review, CI, and repairs complete | | Delivery through merge | [`/factory`](../skills/factory/SKILL.md) | Verified merges, or explicit blockers | | Large GitHub issue batch in Codex | [`/codex-issue-coordinator`](../skills/codex-issue-coordinator/SKILL.md) | Visible workers and checked PRs | | Acceptance proof | [`/test`](../skills/test/SKILL.md) | Pass, fail, or unverified evidence | | Independent implementation review | [`/review`](../skills/review/SKILL.md) | Findings and verdict | | Simpler code with the same behavior | [`/improve`](../skills/improve/SKILL.md) | Focused change and preservation proof | | HTML reading view | [`/html-doc`](../skills/html-doc/SKILL.md) | Verified static HTML | ## System documents and feature specs Requirements define what users need. Architecture defines how the whole system should work. A feature spec defines one coherent change and its proof. Keep shared rules in the root documents and link to them from specs. A spec is the ticket, whether it is Markdown or a GitHub issue. Do not create a second product spec, technical spec, or tracker item for the same definition. One spec may produce several tasks and PRs. Small, decided work can use a task description and checks without formal system documents or a feature spec. ## Delivery authority `/task-to-pr` includes the full test, independent review, CI, and repair loop. It leaves passing PRs open unless the user grants merge authority. Explicit `/factory` use grants authority to merge its supplied work after all gates and required approvals pass. It reuses `/task-to-pr`; it does not lower the quality standard. Explicit `/codex-issue-coordinator` use grants the same scoped authority for its supplied batch. Automatic skill selection grants neither. Neither merge workflow authorizes deployment or release publication. Report missing decisions, approvals, or checks as blockers.