Spec-Driven Development
addyosmani/agent-skills
Writes a structured specification before any code, moving through gated specify, plan, tasks and implement phases, with an optional capability map for multi-part requests.
Creates or updates a long-running REQUIREMENTS.md that defines a system's users, outcomes, capabilities, business rules, scope and acceptance conditions.
Install Product Requirements Document
$ npx skills add owainlewis/blueprint --skill requirements -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install owainlewis/blueprint requirements --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/owainlewis/blueprint.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/requirements .claude/skills/requirements && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "requirements" agent skill from https://github.com/owainlewis/blueprint/tree/main/skills/requirements into .claude/skills/requirements/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "requirements", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/owainlewis/blueprint/tree/main/skills/requirementsType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add owainlewis/blueprint --skill requirements -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install owainlewis/blueprint requirements --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/owainlewis/blueprint.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/requirements .agents/skills/requirements && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "requirements" agent skill from https://github.com/owainlewis/blueprint/tree/main/skills/requirements into .agents/skills/requirements/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "requirements", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add owainlewis/blueprint --skill requirements -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install owainlewis/blueprint requirements --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/owainlewis/blueprint.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/requirements .cursor/skills/requirements && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "requirements" agent skill from https://github.com/owainlewis/blueprint/tree/main/skills/requirements into .cursor/skills/requirements/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "requirements", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/owainlewis/blueprint.git --path skills/requirements--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add owainlewis/blueprint --skill requirements -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install owainlewis/blueprint requirements --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/owainlewis/blueprint.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/requirements .gemini/skills/requirements && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "requirements" agent skill from https://github.com/owainlewis/blueprint/tree/main/skills/requirements into .gemini/skills/requirements/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "requirements", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install owainlewis/blueprint requirementsInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add owainlewis/blueprint --skill requirements -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/owainlewis/blueprint.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/requirements .github/skills/requirements && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "requirements" agent skill from https://github.com/owainlewis/blueprint/tree/main/skills/requirements into .github/skills/requirements/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "requirements", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add owainlewis/blueprint --skill requirements -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install owainlewis/blueprint requirements --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/owainlewis/blueprint.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/requirements .opencode/skills/requirements && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "requirements" agent skill from https://github.com/owainlewis/blueprint/tree/main/skills/requirements into .opencode/skills/requirements/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "requirements", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
requirements- GitHub stars
- 412
- Token cost
- ~766 tokens
- SKILL.md length
- 384 words
- Files
- 1
- Skills in repo
- 11
- Repo updated
- First seen
- Licence
- MIT
At a glance
Creates or updates a long-running REQUIREMENTS.md that defines a system's users, outcomes, capabilities, business rules, scope and acceptance conditions.
- Works in 5 steps: Read the request, repository… → Identify the users, problem, desired… → Write the requirements using the shape… → …
- Defining a new service or system before design starts
- SKILL.md covers Process, Document shape and Return
- Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
What it does
The agent maintains a single root `REQUIREMENTS.md` describing what the product does and its key features. It reads the request, repository instructions, existing requirements and any supplied evidence, then identifies users, problem, desired outcome, scope and constraints, separating stated needs from assumptions and asking you only for product decisions that would change the result. Each requirement gets a stable `REQ-n` ID that is never reused or renumbered.
The document can include purpose and users, a user journey, evidence and assumptions, key features and non-goals, requirements, constraints with measurable thresholds where known, acceptance conditions, success measures and open decisions, using only the sections that help. Before stopping, the agent checks that requirements agree, cover failure behavior and can be tested. It stops at a document ready for human review and does not design the implementation, plan tasks or write code. Single features go to `/spec` and technical decisions to `/architecture`.
When your agent uses it
- Defining a new service or system before design starts
- Updating product expectations after a change in scope
- Turning scattered notes and feedback into numbered, testable requirements
- Recording open product decisions and their effect on delivery
Example prompts
- “Write REQUIREMENTS.md for a customer invoicing service based on the notes in ./docs/discovery.”
- “Update our requirements to add team accounts and mark the pricing question as an open decision.”
- “Review REQUIREMENTS.md for gaps in failure behavior and requirements that cannot be tested.”
Workflow steps
5 steps, taken from the first numbered list in SKILL.md.
- Read the request, repository instructions, existing requirements, and relevant evidence. Reuse decisions already made.
- Identify the users, problem, desired outcome, scope, and constraints. Separate stated needs from assumptions. Inspect the repo for facts…
- Write the requirements using the shape below. Give each requirement a stable REQ-n ID. Never reuse or renumber existing IDs.
- Check that the requirements agree, cover relevant failure behavior, and can be tested. Record unresolved decisions and whether they block…
- Stop with the document ready for human review. Do not design the implementation, plan tasks, or write code.
What it can do on your machine
Read from SKILL.md and the folder at commit 1d74745. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
No scripts in the folder and no shell commands in SKILL.md.
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Product Requirements Document loads about 766 tokens when it runs. Until then it costs about 48 tokens; SKILL.md has 384 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from owainlewis/blueprint at commit 1d74745, republished under its MIT licence (© owainlewis). 384 words, ~766 tokens.
Download SKILL.mdSave it as
.claude/skills/requirements/SKILL.md (or your agent's skills folder).- name
- requirements
- description
- Defines system product requirements: users, outcomes, capabilities, business rules, scope, and acceptance. Use for a new service or system, or a change to its product expectations.
- user-invocable
- true
- argument-hint
- <system, brief, or REQUIREMENTS.md>
Requirements
Create or update root REQUIREMENTS.md. Describe the product, what it does, and its key features. Keep this as a long-running product document.
Use /spec for one feature and /architecture for system technical decisions.
Process
- Read the request, repository instructions, existing requirements, and relevant evidence. Reuse decisions already made.
- Identify the users, problem, desired outcome, scope, and constraints. Separate stated needs from assumptions. Inspect the repo for facts; ask the user for missing product decisions that could change the result.
- Write the requirements using the shape below. Give each requirement a stable
REQ-nID. Never reuse or renumber existing IDs. - Check that the requirements agree, cover relevant failure behavior, and can be tested. Record unresolved decisions and whether they block architecture or delivery.
- Stop with the document ready for human review. Do not design the implementation, plan tasks, or write code.
Document shape
- Purpose and users: the problem, who has it, and the outcome they need.
- User journey: when several capabilities need connecting, show one realistic path from the problem to the desired result.
- Evidence and assumptions: link supplied research, feedback, or existing behavior that supports the problem. Label consequential assumptions and how to validate them. Do not invent evidence.
- Key features and scope: the main capabilities, their value, and explicit non-goals.
- Requirements: observable behavior, business rules, permissions, and user-visible failure and recovery. Define domain concepts when needed.
- Constraints: required compatibility, security, privacy, operational, and performance limits. Use measurable thresholds when known; mark unknown targets as open decisions.
- Acceptance: observable conditions for the system capabilities. Leave detailed feature scenarios and checks to its spec.
- Success measures: how to judge value after delivery, when evidence supports a measure. Keep these separate from implementation acceptance.
- Open decisions: each missing answer, recommended default when justified, and its effect on further work.
Show full SKILL.md (81 more words)Show less
Use only sections that help define this product. Combine related points and omit sections that add no useful information.
Update this document when the product, key features, scope, or business rules change. Keep it current; preserve feature decision history in specs. Keep feature implementation detail in specs.
Keep implementation choices out of requirements. Include an imposed technology only as a stated constraint. Do not invent user research, targets, or business rules.
Return
Report the path, decisions made, and any blocking question.
© owainlewis, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
Just SKILL.md in skills/requirements of owainlewis/blueprint.
Open the folder on GitHubat commit 1d74745
Compare with similar skills
Product Requirements Document next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Product Requirements Document this skillowainlewis/blueprint | 412 | — | ~766 | Automated safety check: Pass | MIT | |
| Spec-Driven Developmentaddyosmani/agent-skills | 103k | 1 repos | ~3.2k | Automated safety check: Pass | MIT | |
| User Alignment and Agent-Ready PRDstryproduck/produck-skills | 510 | — | ~5.3k | Automated safety check: Pass | Apache-2.0 | |
| CCPM Project Managementautomazeio/ccpm | 8.4k | — | ~1.1k | Automated safety check: Pass | MIT | |
| Code to PRDalirezarezvani/claude-skills | 28k | 1 repos | ~4.9k | Automated safety check: Pass | MIT | |
| Grilling Ideasopsmill/infrahub | 533 | — | ~3.8k | Automated safety check: Pass | Apache-2.0 |
Similar skills
User Alignment and Agent-Ready PRDs
tryproduck/produck-skills
Turns a vague feature request into a written spec with scope, phases, acceptance criteria and do-not-do limits that a coding agent can follow without guessing.
CCPM Project Management
automazeio/ccpm
Runs a spec-driven workflow from PRD to epic to GitHub issues to parallel agents, with status, standup and blocked-work reports from bundled scripts.
Code to PRD
alirezarezvani/claude-skills
Reverse-engineers a frontend, backend or fullstack codebase into a product requirements document with per-page docs, an enum dictionary and an API inventory.
Grilling Ideas
opsmill/infrahub
Stress-tests a fuzzy or vague feature idea before any PRD, spec, or ticket is written.
Spec Workflow
hashgraph-online/awesome-codex-plugins
This skill should be used when the user asks to "create a spec", "write requirements", "design a feature", "plan implementation", "use EARS notation", "create user stories", "break down tasks"…
More from owainlewis/blueprint
All 11 skills in this repoMarkdown PRD to HTML Renderer
owainlewis/blueprint
Converts a complete Markdown PRD or technical design into one verified, static HTML reading page without changing what it says.
Codex Issue Coordinator
owainlewis/blueprint
Lets one Codex thread run a batch of GitHub issues through separate worker threads, each with its own worktree, branch, tested pull request and gated merge.
Vertical-Slice Task Planner
owainlewis/blueprint
Breaks a reviewed spec into ordered, vertical-slice tasks that each fit one agent run and one pull request, grouped into milestones when useful.
Independent Implementation Review
owainlewis/blueprint
Has a separate agent review a code change without editing it, checking behavior, security, regressions, complexity, tests and docs before merge.
Architecture
owainlewis/blueprint
Designs and maintains root ARCHITECTURE.md for the intended system, including its data model and shared technical rules.
Architecture Review
owainlewis/blueprint
Reviews a technical proposal before implementation through an independent subagent, returning findings, open questions and a verdict without rewriting it.
Related
Categories
Questions about Product Requirements Document
What does Product Requirements Document do?
Creates or updates a long-running REQUIREMENTS.md that defines a system's users, outcomes, capabilities, business rules, scope and acceptance conditions. md` describing what the product does and its key features. It reads the request, repository instructions, existing requirements and any supplied evidence, then identifies users, problem, desired outcome, scope and constraints, separating stated needs from assumptions and asking you only for product decisions that would change the result.
When should I use Product Requirements Document?
Product Requirements Document fits situations like: defining a new service or system before design starts; updating product expectations after a change in scope; turning scattered notes and feedback into numbered, testable requirements; recording open product decisions and their effect on delivery.
How do I install Product Requirements Document in Claude Code?
Run `npx skills add owainlewis/blueprint --skill requirements -a claude-code`. Or copy the skill folder (skills/requirements in owainlewis/blueprint) into .claude/skills/requirements in your project. Claude Code loads it when a task matches its description.
How do I install Product Requirements Document in Codex?
Run `npx skills add owainlewis/blueprint --skill requirements -a codex`. Or copy the skill folder (skills/requirements in owainlewis/blueprint) into .agents/skills/requirements in your project. Codex loads it when a task matches its description.
Can I use Product Requirements Document in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add owainlewis/blueprint --skill requirements -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/requirements, .gemini/skills/requirements, .github/skills/requirements and .opencode/skills/requirements in your project.
What does Product Requirements Document need to run?
SKILL.md names no scripts, command-line tools or credentials: Product Requirements Document is instructions for the agent only.
Does Product Requirements Document access the network?
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Is Product Requirements Document safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Product Requirements Document use?
Product Requirements Document is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Product Requirements Document use?
About 766 tokens (SKILL.md is roughly 3.1k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Product Requirements Document?
Skills that share tags, products or a category with Product Requirements Document: Spec-Driven Development (addyosmani/agent-skills, 103k stars), User Alignment and Agent-Ready PRDs (tryproduck/produck-skills, 510 stars), CCPM Project Management (automazeio/ccpm, 8.4k stars) and Code to PRD (alirezarezvani/claude-skills, 28k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Product Requirements Document?
owainlewis (a GitHub user) maintains it in owainlewis/blueprint, which has 412 GitHub stars. The repository holds 11 skills in this directory. The repository was last updated on October 6, 2026.
Source: owainlewis/blueprint on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.