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 agentmods add skills/getappz/agentflare/requirements-specificationnpx skills add getappz/agentflare --skill requirements-specificationgit clone --depth 1 https://github.com/getappz/agentflareWrote 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/getappz/agentflare/requirements-specification)<a href="https://agentmods.dev/skills/getappz/agentflare/requirements-specification"><img src="https://agentmods.dev/badge/skills/getappz/agentflare/requirements-specification.svg" alt="Measured on agentmods" 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.00096 | $0.01016 |
| Opus 5 | $0.00048 | $0.00508 |
| Sonnet 5 | $0.00019 | $0.00203 |
| Haiku 4.5 | $0.00010 | $0.00102 |
Grade A, and why
requirements-specification 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 5d 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 — 112 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Requirements Specification
Write requirements precisely enough that two different people implementing from the same spec would build the same thing. A vague spec doesn't save time — it just moves the ambiguity (and the rework) later.
When to use
- The ask is underspecified: "add notifications," "make search better," "support teams" — before any architecture or code, pin down what these actually mean.
- Multiple stakeholders (or a stakeholder and an implementer) could reasonably disagree about scope.
- Skip when the change is small and unambiguous (a one-line bug fix, a well-scoped refactor) — writing a formal spec for those is pure overhead.
Process
1. Requirements gathering
Split every requirement into functional (what the system does) and non-functional (how well it does it — latency, availability, security). Each one needs an id, a priority, and criteria specific enough to fail a "is this actually done?" test:
FR-001: System shall authenticate users via OAuth2
priority: high
acceptance:
- Users can log in with Google/GitHub
- Session persists for 24 hours
- Refresh tokens auto-renew
NFR-001 (performance): API p95 latency <200ms
NFR-002 (security): All data encrypted in transit and at rest
"Fast" and "user-friendly" are not requirements — they're not testable. Replace them with a number and a measurement method.
2. Constraint analysis
Separate constraints by kind, since each kind trades off differently:
- Technical — must use existing DB, must run on current infra, language/ framework version floors.
- Business — deadline, budget, team size.
- Regulatory — compliance regimes (GDPR, SOC2), accessibility (WCAG).
3. Use cases
For anything with a nontrivial flow, write the actor, preconditions, the numbered step-by-step flow, postconditions, and — critically — the exceptions (what happens when a step fails). Most spec gaps live in the exceptions nobody wrote down.
4. Acceptance criteria (Gherkin)
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.
- 5d ago First seen · 112 lines · 96 tokens per session scan A f21122cf2ab0
requirements-specification is a skill published in the GitHub repository getappz/agentflare (2 stars, last pushed 3d ago), licensed Apache-2.0. It adds 96 tokens to every session and 1,016 once invoked, about $0.0005 per session on Opus 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-08-31.
Other skills, from other repositories
coordinate-recover
Diagnose and safely resume Coordinate Agents Tasks after executable failure, non-zero exit, timeout, stale claim, processing message, or Implementer ERROR. Recovery is explicit and never an automatic retry loop.
twining-verify
Runs pre-completion verification — checks unresolved warnings, decision hygiene, and drift. Recommended for complex tasks; for simple tasks a status post via twiningpost is sufficient.
error-handling
Debug and recover from agent team errors including common errors, hooks for quality gates, known limitations, and recovery strategies. Use when encountering team errors, enforcing quality gates with hooks, understanding limitations, or debugging agent issues.
think-react
ReAct reasoning — explicit reason-act-observe cycle for investigation and debugging. Use when you need to interleave reasoning with tool actions systematically.
swarm-deepdive
Forensic inspection of swarm activity - reconstruct timelines, debug stuck or failed agents, audit task/message/KV/file-lock/UI command history, and correlate daemon logs. Use when the user asks "what happened in the swarm", "why did agent X stop", "trace this task", "show message history", "why is swarm-ui stuck", or…
debug-optimize-lcp
Guides debugging and optimizing Largest Contentful Paint (LCP) using Chrome DevTools MCP tools. Use this skill whenever the user asks about LCP performance, slow page loads, Core Web Vitals optimization, or wants to understand why their page's main content takes too long to appear. Also use when the user mentions…