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 commands/clchinkc/document-mcp/2-specgit clone --depth 1 https://github.com/clchinkc/document-mcpWhat 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.00000 | $0.02601 |
| Opus 5 | $0.00000 | $0.01300 |
| Sonnet 5 | $0.00000 | $0.00520 |
| Haiku 4.5 | $0.00000 | $0.00260 |
Grade A, and why
2-spec 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 yesterday.
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 — 179 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Requirements Gathering Generation
Workflow Stage: Requirements Gathering
First, generate an initial set of requirements in EARS format based on the feature idea, then iterate with the user to refine them until they are complete and accurate.
Don't focus on code exploration in this phase. Instead, just focus on writing requirements which will later be turned into a design.
Constraints:
- The model MUST create a '.claude/specs/{feature_name}/requirements.md' file if it doesn't already exist
- The model MUST generate an initial version of the requirements document based on the user's rough idea WITHOUT asking sequential questions first
- The model MUST format the initial requirements.md document with:
- A clear introduction section that summarizes the feature
- A hierarchical numbered list of requirements where each contains:
- A user story in the format "As a [role], I want [feature], so that [benefit]"
- A numbered list of acceptance criteria in EARS format (Easy Approach to Requirements Syntax)
- Associated use cases that demonstrate how the user story will be fulfilled
- Test cases that validate the acceptance criteria and use cases
- Example format: [includes example format here]
- The model SHOULD apply PRD thinking methodology when generating requirements: identify user personas, define problem statements, consider success metrics, and think through user journeys to create comprehensive requirements
- The model SHOULD consider edge cases, user experience, technical constraints, and success criteria in the initial requirements
- After updating the requirement document, the model MUST ask the user "Do the requirements look good? If so, I can optionally create behavioral scenarios, or we can move on to the design." using the 'userInput' tool.
- The 'userInput' tool MUST be used with the exact string 'spec-requirements-review' as the reason
- The model MUST make modifications to the requirements document if the user requests changes or does not explicitly approve
- The model MUST ask for explicit approval after every iteration of edits to the requirements document
- The model MUST NOT proceed to the design document until receiving clear approval (such as "yes", "approved", "looks good", etc.)
- The model MUST continue the feedback-revision cycle until explicit approval is received
- The model SHOULD suggest specific areas where the requirements might need clarification or expansion
- The model MAY ask targeted questions about specific aspects of the requirements that need clarification
- The model MAY suggest options when the user is unsure about a particular aspect
- The model MUST proceed to behavioral scenario generation if requested, or directly to the design phase after the user accepts the requirements
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.
- yesterday First seen · 179 lines · 0 tokens per session scan A 5f1709d3d4bb
2-spec is a command published in the GitHub repository clchinkc/document-mcp (0 stars, last pushed 3mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,601 tokens. 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 commands, from other repositories
validate-dependencies
Validate all task dependencies for issues.
flow-nexus-neural
Train and deploy neural networks in distributed sandboxes.
flow-nexus-auth
Flow Nexus authentication and user management.
validate-prd
Validate an existing PRD against BMAD standards - comprehensive review for completeness, clarity, and quality.
editorial-review-structure
Structural editor that proposes cuts, reorganization, and simplification while preserving comprehension.
add-tool
Scaffold a new FreeAgent MCP tool (handler + registration + test) following the repo pattern.