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.
git clone --depth 1 https://github.com/sorah/configWrote 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/sorah/config/pull-request)<a href="https://agentmods.dev/commands/sorah/config/pull-request"><img src="https://agentmods.dev/badge/commands/sorah/config/pull-request/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/sorah/config/pull-request"><img src="https://agentmods.dev/badge/commands/sorah/config/pull-request.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00014 | $0.00928 |
| Opus 5.5 | $0.00006 | $0.00371 |
| Sonnet 5.5 | $0.00003 | $0.00186 |
| Haiku 4.5 | $0.00001 | $0.00093 |
Grade A, and why
pull-request 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 — 73 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Load the commit-style skill and apply its conventions to PR titles and descriptions.
Instructions
$ARGUMENTS
Step 1: Analyze the branch
- Determine the current branch name and the base branch (main/master).
- Halt immediately if the current branch is the primary branch (main or master). Ask the user what to do.
- Run
git log <base>..HEADandgit diff <base>...HEADto understand all commits on this branch.
Step 2: Consider a stacked PR
Stacked PRs are handled by the gh-stack skill, which is not part of this plugin. Halt immediately whenever a stack is called for but that skill is unavailable — tell the user the gh-stack skill is missing and ask how to proceed. Never improvise a stack with raw gh or git commands.
If the branch is already part of a stack (gh stack view --json exits 0 and lists the current branch), or the user asked for a stacked PR: load the gh-stack skill and follow it instead of the gh pr create flow in Step 4. gh pr create does not maintain stack bases.
Otherwise, judge whether the branch is better submitted as a stack. Suggest stacking when the commits divide into parts that can be reviewed on their own and splitting them measurably lightens the reviewer's load:
- A preparatory change (refactor, rename, extraction, dependency bump) that stands on its own, followed by the change that depends on it
- Parts with different reviewer audiences (e.g. infrastructure/schema vs. application code)
- A diff large enough that reviewing it as a single unit is a burden, with a natural seam to cut along
Do not suggest stacking when the change is one cohesive unit, when the split parts would not build or pass tests independently, or when the pieces are meaningless apart from each other. A small PR does not need splitting.
When stacking is worthwhile, present the proposed layers (branch names and which commits go where) and wait for approval — restructuring rewrites branch history. On approval, load the gh-stack skill and follow it to build and submit the stack; compose each PR's title and description with Step 3 below. Skip this step when the argument contains "message-only" — mention the suggestion, but do not restructure.
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 · 73 lines · 14 tokens per session scan A 99a71761f2a5
pull-request is a command published in the GitHub repository sorah/config (31 stars, last pushed yesterday), licensed MIT. It adds 14 tokens to every session and 928 once invoked, about $0.0001 per session on Opus 5.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-10-17.
Other commands, from other repositories
speckit.spex.submit
Push and create PR for team review, with optional watch mode for CI monitoring.
git
The pre-finish status: branch, hygiene findings, message checks, workflow lint, template state.
merge-conflict-analysis
You are analyzing merge conflicts for PR #${{ pr-number }}.
release-tag
Create and push a version tag after a release PR has been merged.
factory
Linha de montagem multi-agente (Software Factory) — spec-writer → builder em worktree isolado → 4 revisores paralelos (Security, Code, UI, UX) → approver com gate de risco e dashboard visual.
repo-audit
Audit a codebase (local or remote GitHub/GitLab) against architecture principles and requirements, surfacing drift, risk, and missing decisions.