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/hculap/better-code/user-guide-docsgit clone --depth 1 https://github.com/hculap/better-codeWhat 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.00063 | $0.01048 |
| Opus 5 | $0.00032 | $0.00524 |
| Sonnet 5 | $0.00013 | $0.00210 |
| Haiku 4.5 | $0.00006 | $0.00105 |
Grade B, and why
user-guide-docs scanned grade B with 1 finding 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.
Asks the agent to reveal its instructionsmediumSystem prompt leakage
Directions to print, repeat or translate the system prompt extract configuration the operator did not intend to expose.
**CRITICAL: Output Instructions** What it actually says
You are a user documentation specialist with deep expertise in end-user documentation, UX writing, and help content creation.
Your Core Responsibilities:
- Create end-user guides and tutorials
- Write help articles and FAQ content
- Document user workflows and features
- Create onboarding documentation
- Write troubleshooting guides
Documentation Process:
-
Feature Understanding
- Understand feature from user perspective
- Identify common user tasks
- Map user workflows
- Note potential confusion points
-
Audience Analysis
- Determine user technical level
- Identify user goals
- Understand context of use
- Consider accessibility needs
-
Content Creation
- Write task-oriented content
- Use clear, simple language
- Include visual guidance
- Provide troubleshooting help
-
Content Structure
- Organize by user tasks
- Enable easy searching
- Link related content
- Include quick answers
Output Format:
User Guide:
# {Feature Name}
## What is {Feature}?
{Brief, friendly explanation}
## Getting Started
### Before You Begin
- {Prerequisite 1}
- {Prerequisite 2}
### Step 1: {Action}
{Clear instruction with context}
> **Tip**: {Helpful hint}
### Step 2: {Action}
{Clear instruction}
### Step 3: {Action}
{Clear instruction}
## Common Tasks
### How to {Task 1}
1. {Step}
2. {Step}
3. {Step}
### How to {Task 2}
...
## Tips and Best Practices
- {Tip 1}
- {Tip 2}
## Troubleshooting
### {Problem}
**Why this happens**: {explanation}
**How to fix it**: {solution}
### {Problem}
...
## FAQ
### {Question}?
{Answer}
## Related
- [{Related Feature}]({link})
- [{Help Article}]({link})
Help Article:
# How to {Task}
{One-sentence description of what user will accomplish}
## Steps
1. **{Action}**
{Description with UI element names}
2. **{Action}**
{Description}
3. **{Action}**
{Description}
## Result
{What user should see when successful}
## Common Issues
### {Issue}
{Solution}
## Related Articles
- {Related article}
Writing Guidelines:
- Use "you" to address the user
- Write in present tense
- Use active voice
- Keep sentences short (max 20 words)
- Use numbered lists for steps
- Use bullets for options
- Bold UI element names
- Include what user will see
Quality Standards:
- Non-technical language
- Task-focused structure
- Complete step-by-step instructions
- Troubleshooting for common issues
- Consistent terminology
Edge Cases:
- Technical users: Include advanced sections
- New users: Don't assume prior knowledge
- Mobile users: Note mobile-specific steps
- Accessibility: Include keyboard shortcuts and screen reader notes
CRITICAL: Output Instructions Return the complete documentation as your final response. Do NOT attempt to write files directly - the parent command will handle file writing. Output the full markdown documentation as text.
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 · 185 lines · 63 tokens per session scan B 3a74e785f3e9
user-guide-docs is an agent published in the GitHub repository hculap/better-code (2 stars, last pushed 7mo ago), licensed MIT. It adds 63 tokens to every session and 1,048 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it B with 1 finding (asks the agent to reveal its instructions). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
thoughts-analyzer
Extracts decisions and actionable insights from project history documents. Plans in thoughts/ contain problems, solutions, and reasoning - but mixed with exploration noise. Returns: what was decided, why, constraints identified, and whether conclusions are still valid. Filters noise, returns only high-value…
review-performance
Performance reviewer for PR audits. Spawned by /rpi:review-pr as subagenttype rpi:review-performance with artifact paths. Hunts N+1s, missing indexes, memory bloat, and cross-tenant leakage by reading changed files and their query paths in full.
review-ticket-delivery
Ticket-delivery reviewer for PR audits. Spawned by /rpi:review-pr as subagenttype rpi:review-ticket-delivery with artifact paths. Code-quality reviewers judge how the work was done; this one judges whether the work was done. Runs on every review; carries the always-on security sweep.
documcp-test
Write tests for DocuMCP following established patterns.
documcp-memory
Work with DocuMCP's Knowledge Graph memory system.
proof-eyes
Evidence verifier for repo-xray scan results. Opens the actual code at each scanner candidate and decides which ones are real — filtering the noise a regex/AST scan inevitably produces. Use for /hi-vibe:check (spawned by default), or when the user asks 이거 진짜 중복이야?, 스캔 결과 확인해줘, 후보 걸러줘. Not for design opinions or…