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/stephengpope/thepopebot/update-docsgit clone --depth 1 https://github.com/stephengpope/thepopebotWrote 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/commands/stephengpope/thepopebot/update-docs)<a href="https://agentmods.dev/commands/stephengpope/thepopebot/update-docs"><img src="https://agentmods.dev/badge/commands/stephengpope/thepopebot/update-docs.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 | $0.00014 | $0.00545 |
| Opus 5 | $0.00007 | $0.00272 |
| Sonnet 5 | $0.00003 | $0.00109 |
| Haiku 4.5 | $0.00001 | $0.00055 |
Grade A, and why
update-docs 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 4d 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 — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Enter plan mode first. Do NOT edit any files — this command only produces an analysis and a prioritized todo list. The user will decide what to implement.
Follow these steps IN ORDER. The sequence matters — you must understand the product before you can judge the docs.
Step 1 — Understand the current product
Read the codebase to build a picture of what thepopebot actually does today. Look at features, commands, config options, workflows, integrations, and user-facing behavior. Start from the code, not the docs — you need an independent understanding of the product's current state.
Step 2 — Find what's changed recently
Use git to find significant changes since the docs were last touched. For each doc file, check when it was last modified and what code has changed in its relevant area since then.
Build a list of:
- New — features, commands, config options, integrations that didn't exist before
- Changed — behavior, APIs, workflows, defaults that work differently now
- Removed — things that no longer exist but might still be documented
Step 3 — Read all existing docs
Read README.md and everything in docs/. For each file, judge:
- Is the content still accurate?
- Is this still needed as its own doc, or should it be folded into another?
- Should this be split, merged, renamed, or deleted?
- Does it describe things that no longer exist?
- Is it clear enough for a new user to follow?
Leave the README hero section alone. The top of README (tagline, "What You Get", "Why It Works") is stable marketing copy. Only flag changes there if a major new capability was added that genuinely belongs in the highlights.
Step 4 — Identify gaps
What does the product do that has no documentation at all? What would a new user struggle with? What questions would someone ask that no doc answers? Are there docs that should exist but don't?
Step 5 — Produce the update plan
Create a prioritized list of changes. Each item says what to do and why. Categories include:
- Update existing docs (with specifics on what's wrong)
- Delete docs that are no longer useful
- Create new docs for uncovered areas
- Merge docs that overlap
- Update README doc links to match any structural changes
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.
- 4d ago First seen · 49 lines · 14 tokens per session scan A e43164585523
update-docs is a command published in the GitHub repository stephengpope/thepopebot (1,852 stars, last pushed 3mo ago), licensed MIT. It adds 14 tokens to every session and 545 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
git
Git operations with intelligent commit messages and workflow optimization.
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.