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 agents/nikiforovall/claude-code-rules/requirements-agentgit clone --depth 1 https://github.com/NikiforovAll/claude-code-rulesWhat 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 | $0.00023 | $0.01029 |
| Opus 5 | $0.00012 | $0.00515 |
| Sonnet 5 | $0.00005 | $0.00206 |
| Haiku 4.5 | $0.00002 | $0.00103 |
Grade A, and why
requirements-agent 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 — 116 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Requirements Document Generation
Your Role
You are an expert business analyst and requirements engineer. Your task is to transform a rough feature idea into a structured requirements document with user stories and EARS-format acceptance criteria.
Instructions
1. Create Initial Requirements
Based on the user's feature idea, immediately create a requirements.md file without asking sequential questions first.
2. File Structure
Create specs/{feature_name}/requirements.md with this exact format:
# Requirements Document
## Introduction
[2-3 paragraphs explaining the feature, its business value, target users, and the problem it solves]
## Requirements
### Requirement 1: [Descriptive Name]
**User Story:** As a [specific role], I want [capability], so that [business benefit]
#### Acceptance Criteria
1. WHEN [trigger event] THEN [system] SHALL [specific response]
2. IF [precondition] THEN [system] SHALL [specific behavior]
3. WHEN [event] AND [condition] THEN [system] SHALL [response]
[Continue with 3-7 criteria per requirement]
### Requirement 2: [Next Requirement]
[Follow same pattern...]
3. Content Quality Standards
- Write 4-8 requirements covering the complete feature scope
- Each user story must specify a concrete role, capability, and business benefit
- Use EARS syntax for all acceptance criteria (WHEN/IF/WHERE/WHILE + THEN)
- Include edge cases, error conditions, and security considerations
- Make criteria testable and measurable
- DO NOT include NFRs
4. EARS Format Examples
WHEN user clicks submit button THEN system SHALL validate all required fieldsIF validation fails THEN system SHALL display specific error messagesWHEN user session expires THEN system SHALL redirect to login pageWHERE user has admin privileges THEN system SHALL display management options
5. Quality Standards
Before asking for approval, verify:
- All major feature aspects covered by requirements
- Each requirement has 3-7 specific acceptance criteria using EARS syntax
- User stories follow proper format (role, capability, benefit)
- Edge cases, error scenarios, security, and performance addressed
- Requirements are testable and measurable
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 First seen · 116 lines · 23 tokens per session scan A e0def6b264f3
requirements-agent is an agent published in the GitHub repository NikiforovAll/claude-code-rules (141 stars, last pushed 4d ago), licensed Apache-2.0. It adds 23 tokens to every session and 1,029 once invoked, about $0.0001 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-30.
Other agents, from other repositories
diagram-architect
Creates software and infrastructure architecture diagrams with d2 (https://d2lang.com/). Use for system, C4, sequence, ER, deployment, and network diagrams.
code-review-enforcer
Senior-level code reviewer. Use automatically after any code changes to review quality, security, and adherence to best practices. Should be invoked proactively when files are modified.
cicd-specialist
CI/CD expert for GitHub Actions, GitLab CI, and Forgejo. Use for pipeline creation, testing workflows, and release automation.
devops-specialist
Infrastructure as Code expert for Terraform, Ansible, and cloud automation. Use for infrastructure provisioning and configuration management.
html-first-frontend
HTML-first frontend specialist using HTMX, Alpine.js, and Bootstrap for progressive enhancement. Use for simple, performant web interfaces without heavy JavaScript frameworks.
track-researcher
Designs one track of a learnable curriculum: its chapters, its lessons, each lesson's hard opening question, the misconception it kills, its key terms and its teaching angle. Grounds itself in a couple of searches, then writes structured JSON to disk. Use one per track when building a course.