Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add owainlewis/blueprint --skill requirementsgit clone --depth 1 https://github.com/owainlewis/blueprintWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/owainlewis/blueprint/requirements)<a href="https://agentmods.dev/skills/owainlewis/blueprint/requirements"><img src="https://agentmods.dev/badge/skills/owainlewis/blueprint/requirements/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/owainlewis/blueprint/requirements"><img src="https://agentmods.dev/badge/skills/owainlewis/blueprint/requirements.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00037 | $0.00594 |
| Opus 5.5 | $0.00015 | $0.00238 |
| Sonnet 5.5 | $0.00007 | $0.00119 |
| Haiku 4.5 | $0.00004 | $0.00059 |
Grade A, and why
requirements scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 43 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago Changed · +1 lines 201ce65c0588
- 9d ago First seen · 42 lines · 37 tokens per session scan A bbccbfff0a56
requirements is a skill published in the GitHub repository owainlewis/blueprint (415 stars, last pushed 3d ago), licensed MIT. It adds 37 tokens to every session and 594 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-07.
Other skills, from other repositories
speckit-status
Before the first runner call, resolve and keep the caller's working directory per Installed runner transport.
working-days-get-working-days
Calculate the number of working days between two dates, optionally accounting for country-specific holidays.
speckit.backlog
Backlog Manager - Manage Ideas, Pending Requests and scan TODO/FIXME from codebase.
speckit.roadmap
Roadmap Strategist - Maintain evidence-backed milestones, dependencies, risks, and phase transitions.
speckit.status
Progress Dashboard - Calculate phase and task progress from tasks.md with evidence and risk visibility.
speckit.taskstoissues
Issue Tracker Syncer - Convert tasks.md into deterministic, import-ready issue artifacts without remote mutation.