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/rchgrav/claudebox/pr-draftgit clone --depth 1 https://github.com/RchGrav/claudeboxWhat 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.00009 | $0.01318 |
| Opus 5 | $0.00005 | $0.00659 |
| Sonnet 5 | $0.00002 | $0.00264 |
| Haiku 4.5 | $0.00001 | $0.00132 |
Grade B, and why
pr-draft 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 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.
Subtle steeringmediumPrompt injection
Instructions that bias recommendations or shape behaviour without the user noticing.
- 👩🔬 **How to validate**: Manual steps for reviewers to exercise the code and observe outcomes (teach reviewers how to prove the changes work by using the functionality - never tell them to run tests or checks, as CI How it starts
The opening of the file, as written. The whole thing — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Create a draft pull request from the current branch to the main branch.
Target branch (optional): $ARGUMENTS
Process:
- Check current branch (must not be main/master)
- Check working tree for uncommitted changes:
- Review each change to determine if it belongs with the current PR
- Be cautious with temporary changes: commented-out code, debug prints, config tweaks for testing
- Ask user before committing anything that looks temporary or experimental
- For legitimate changes: commit them with the PR
- For unrelated changes: determine best approach (stash, separate commit, or leave uncommitted)
- Ensure branch is up to date with latest changes from target branch
- Ensure branch is pushed to remote
- Analyze commits since branching from main to understand the changes
- Read modified files to understand the full scope
- Check if PR relates to existing project plans or issues and ensure they're updated:
- Look for related GitHub issues, project roadmaps, or planning documents
- Check if task tracking files (like
.claude/tasks/*.md) need updates - Verify project documentation reflects the changes being made
- Generate PR description:
- Check for existing PR template in
.github/pull_request_template.mdor.github/PULL_REQUEST_TEMPLATE.md - If project has PR template: Follow it, but enhance with the spirit of the high-quality template
- If no project template: Use the high-quality template structure (ONLY these sections):
- 💪 What: What's new/different, direct changes to project behavior, testing/documentation status, implementation details (use present tense: "Adds", "Updates", "Removes", "Fixes")
- 🤔 Why: Problem solved, business value, timing rationale
- 👀 Usage: How to use new functionality (if user-facing)
- 👩🔬 How to validate: Manual steps for reviewers to exercise the code and observe outcomes (teach reviewers how to prove the changes work by using the functionality - never tell them to run tests or checks, as CI handles that)
- 🔗 Related links: External context as markdown links (only if valuable, omit if none)
- Append missing valuable sections from the high-quality template if not covered by project template
- Focus on reviewer experience - provide context that helps reviewers understand and validate changes
- "What" vs "Why" clarity: "What" describes direct changes/impacts, "Why" explains benefits and rationale
- Format requirements: Start "What" with flat bullet list of primary behavior changes/takeaways using present tense verbs (Adds, Updates, Removes, Fixes), format "Why" as flat bullet list
- Avoid file listings: Don't include "New Files" sections - reviewers will see files in the PR, focus on what the PR accomplishes
- Link formatting: Use markdown links for external URLs, raw URLs for GitHub PRs/issues (GitHub formats them nicely), format Related links as bullet list
- "Why" tone: Make salient points about why changes help this specific project, avoid overly broad statements or overselling
- Reference related issues/plans - link to GitHub issues, project plans, or task files this PR addresses
- Check for existing PR template in
Verb tense consistency:
- Always use present tense in "What" section: "Adds", "Updates", "Removes", "Fixes", "Improves"
- Never use past tense: Avoid "Added", "Updated", "Removed", "Fixed"
- Examples: "Adds user authentication", "Updates error handling", "Removes deprecated functions", "Fixes memory leak"
- Rationale: Present tense describes what the PR does when merged, not what was done during development
Related links guidelines:
- ONLY include links that provide valuable context NOT already in the PR
- External references: Documentation, Stack Overflow, RFCs, design docs, external issues
- Background PRs: Previous/related PRs that provide important context
- DO NOT include:
- Files in the current PR (reviewers can already see them)
- Generic/empty pages (issues page with no relevant issues)
- Links that duplicate information already in PR description
- Internal project files unless they provide critical background context
- If no useful links exist, omit the entire Related links section - no section is better than empty section
- Quality over quantity - 1-2 highly relevant links better than 5 marginally useful ones
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 · 88 lines · 9 tokens per session scan B 03a732ac2bd0
pr-draft is a command published in the GitHub repository RchGrav/claudebox (1,142 stars, last pushed 1y ago), licensed MIT. It adds 9 tokens to every session and 1,318 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it B with 1 finding (subtle steering). 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.