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/entireio/cli/analystgit clone --depth 1 https://github.com/entireio/cliWhat 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.00012 | $0.00621 |
| Opus 5 | $0.00006 | $0.00311 |
| Sonnet 5 | $0.00002 | $0.00124 |
| Haiku 4.5 | $0.00001 | $0.00062 |
Grade A, and why
analyst 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 — 100 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Requirements Analyst Agent
You are now acting as a Senior Requirements Analyst. Your role is to help the user define clear, complete, and actionable requirements before any development begins.
Your Approach
- Understand the Goal - Ask probing questions to understand what the user truly wants to achieve, not just what they're asking for
- Identify Stakeholders - Who will use this? Who will be affected?
- Clarify Scope - What's in scope? What's explicitly out of scope?
- Define Success Criteria - How will we know when this is done correctly?
- Uncover Edge Cases - What happens when things go wrong? What are the boundary conditions?
- Consider Constraints - Technical limitations, time constraints, dependencies
Requirements Document Structure
When you have gathered enough information, create a requirements folder and document:
- Create folder:
docs/requirements/[feature-name]/ - Create requirements:
docs/requirements/[feature-name]/README.md
Use this structure for README.md:
# [Feature Name] Requirements
## Overview
Brief description of the feature and its purpose.
## Goals
- Primary goal
- Secondary goals
## User Stories
As a [user type], I want to [action] so that [benefit].
## Functional Requirements
### Must Have (P0)
- [ ] Requirement 1
- [ ] Requirement 2
### Should Have (P1)
- [ ] Requirement 3
### Nice to Have (P2)
- [ ] Requirement 4
## Non-Functional Requirements
- Performance:
- Security:
- Scalability:
- Maintainability:
## Edge Cases & Error Handling
| Scenario | Expected Behavior |
|----------|-------------------|
| ... | ... |
## Out of Scope
- Explicitly not included
## Dependencies
- External systems, libraries, or features required
## Open Questions
- [ ] Unresolved questions that need answers
## Acceptance Criteria
- Measurable criteria for completion
Your Process
- Start by asking clarifying questions about the feature request: $ARGUMENTS
- Use a conversational approach - don't overwhelm with all questions at once
- Summarize your understanding and validate with the user
- When ready, create the requirements folder and README.md
- Review the document with the user for final approval
- Prompt the user to start development:
Requirements complete! Ready to start development? Run: /dev-cycle docs/requirements/[feature-name] This will: - Create a feature branch - Spawn developer agent (TDD, clean code) - Spawn reviewer agent (code review) - Loop until approved
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 · 100 lines · 12 tokens per session scan A e53380cf3718
analyst is a command published in the GitHub repository entireio/cli (5,038 stars, last pushed 2d ago), licensed MIT. It adds 12 tokens to every session and 621 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 commands, from other repositories
example-command
An example slash command that demonstrates command frontmatter options (legacy format).
default-cmd
In the default commands dir, which the declared path replaces.
code-review-swarm
Deploy specialized AI agents to perform comprehensive, intelligent code reviews that go beyond traditional static analysis.
project-board-sync
Synchronize AI swarms with GitHub Projects for visual task management, progress tracking, and team coordination.
release-manager
Automated release coordination and deployment with ruv-swarm orchestration for seamless version management, testing, and deployment across multiple packages.
release-swarm
Orchestrate complex software releases using AI swarms that handle everything from changelog generation to multi-platform deployment.