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 skills add Ohswedd/praxis --skill review-scopegit clone --depth 1 https://github.com/Ohswedd/praxisWrote 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/skills/ohswedd/praxis/review-scope)<a href="https://agentmods.dev/skills/ohswedd/praxis/review-scope"><img src="https://agentmods.dev/badge/skills/ohswedd/praxis/review-scope.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.1 | $0.00085 | $0.00643 |
| Opus 5 | $0.00043 | $0.00321 |
| Sonnet 5 | $0.00017 | $0.00129 |
| Haiku 4.5 | $0.00009 | $0.00064 |
Grade A, and why
review-scope 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 8d 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 — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Scope the change before you judge it
The working tree is not the change. On a branch that has committed anything,
git diff is empty, and a review scoped that way reads nothing, finds nothing,
and returns PASS. That failure is silent: the verdict is indistinguishable from a
genuine clean review, and it gets more likely the better the delivery
discipline is, because one commit per subtask means most of a task's life is
spent in exactly that state.
So a review has a base, and everything from that base to now is in scope: what the branch has committed, what is staged, what is merely edited, and the untracked files that appear in no diff at all.
Where your scope comes from
It is given to you. Whoever dispatched you resolves it first with
scripts/scope.py and states it in your prompt: the base commit, the commits on
the branch, and the files under review. Work from that.
You are a read-only auditor: your tools are Read, Grep and Glob, with no
shell. You cannot run git and you cannot resolve a base yourself. That is
deliberate, and it means the scope is a fact you are handed rather than one you
discover.
When you were not given one
Say so, in the verdict, in words. Then:
- Audit what you can reach with
Read,GrepandGlob, and state exactly what that was: the files you actually examined. - Do not describe the result as clean. A review whose scope was narrower than the
change is not a passing review, and the reader cannot tell the difference
unless you tell them. Return
FAILif the scope gap makes your verdict meaningless, andPASS WITH NOTESnaming the gap if it does not. - Never infer the change from what happens to be modified on disk. That is the working-tree assumption this whole rule exists to break.
State the base in your verdict
Every verdict names the base it was given and what it read. A verdict whose scope is unstated cannot be trusted by the next reader, and "I reviewed the working tree" on a branch with commits means the review did not happen.
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.
- 8d ago First seen · 54 lines · 85 tokens per session scan A c056df1f0e15
review-scope is a skill published in the GitHub repository Ohswedd/praxis (1 stars, last pushed 1mo ago), licensed MIT. It adds 85 tokens to every session and 643 once invoked, about $0.0004 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-31.
Other skills, from other repositories
g-review
Run the review gate on the current branch diff. Runs the test suite, captures the diff, and dispatches code-lead, which verifies done conditions and reviews the diff itself. Issues MERGE READY or HOLD.
g-audit
Full-codebase or targeted code quality audit. Detects SOLID violations, code smells, architectural drift, dead code, and test coverage gaps. Targeted scope produces an inline report. Whole-codebase scope produces a prioritised roadmap milestone.
g-refactor
Guided refactor workflow — identify target, pre-analyse, spec, approve, execute, review. Accepts a scope path, an audit milestone file, or runs interactively. Safe-by-default: checks test coverage before execution and runs the full review gate after.
g-blast-radius
Analyse the blast radius of a planned change. Inputs a file path, feature name, or list of paths from a plan. Outputs the set of dependent files (forward and reverse references), a per-file volatility score (commit frequency proxy), and a total blast-radius rating (low / moderate / wide). Read-only.
refine-loop
Runs a safe, resumable refinement loop over a working repository. It discovers behavior-preserving improvements through four evidence-based lenses, ranks them by ROI, applies one small change at a time, verifies independently, and stops deterministically at diminishing returns or a safety limit. Use when explicitly…
no-mistakes
Validate committed feature-branch changes through the no-mistakes pipeline: intent, rebase, review, test, docs, lint, push, PR, and CI. Use when the user asks to run no-mistakes, ship safely, validate before pushing, or gate a change before it reaches upstream.