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 skills/sortie-ai/sortie/code-reviewnpx skills add sortie-ai/sortie --skill code-reviewgit clone --depth 1 https://github.com/sortie-ai/sortieWrote 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/sortie-ai/sortie/code-review)<a href="https://agentmods.dev/skills/sortie-ai/sortie/code-review"><img src="https://agentmods.dev/badge/skills/sortie-ai/sortie/code-review.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.00130 | $0.02423 |
| Opus 5 | $0.00065 | $0.01211 |
| Sonnet 5 | $0.00026 | $0.00485 |
| Haiku 4.5 | $0.00013 | $0.00242 |
Grade A, and why
code-review 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 — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reviewing sortie pull requests
.github/copilot-instructions.md covers the mechanical checks: layering, concurrency, path containment, SQLite rules, error wrapping, resource lifecycle, adapter boundaries, style. Do not repeat them. This skill covers what those checks cannot see: defects that are locally correct and globally wrong.
Two rules govern every finding.
Verify before flagging. Open the file and read the line. A finding that cites a line that says something else costs the maintainer more than silence. State the evidence inline: file, symbol, and what it actually does.
One grounded finding beats five speculative ones. Uncertain findings are noise. If a check below needs a fact you cannot establish from the diff plus the files it touches, say what you could not verify instead of guessing.
Start from the pull request description
.github/pull_request_template.md makes the author declare Intent, Sensitive Areas, Breaking Changes, and Migrations. Treat each as a claim to audit, not as context to absorb.
- Intent says opt-in or default-off. Find the branch that makes it inert when unconfigured, and confirm nothing outside it changed behavior. An opt-in feature that alters a default path is the failure this claim hides.
- Sensitive Areas names a file. Review it first and hardest. An empty Sensitive Areas on a diff that touches orchestrator state, an adapter boundary, or workspace removal is itself a finding.
- Breaking Changes says none. Check exported signatures, domain struct fields consumed by adapters, config field names and defaults, and log or metric names an operator may depend on.
- Migrations says none. Check
internal/persistence/sql/and any new column read.
Documentation is part of the change
The specification under docs/architecture/ is the contract implementation follows, so drift is a defect, not a nicety. For any behavior change, find the section that describes that behavior and confirm the PR updates it.
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 · 91 lines · 130 tokens per session scan A 50fa2da015e5
code-review is a skill published in the GitHub repository sortie-ai/sortie (135 stars, last pushed 4d ago), licensed Apache-2.0. It adds 130 tokens to every session and 2,423 once invoked, about $0.0006 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 skills, from other repositories
issue-review
Triage a copperhead GitHub issue, attempt reproduction, and check it against the spec. Use when the user asks to review an issue, e.g. /issue-review 42 or /issue-review .
pr-review
Review a copperhead pull request against the repo's invariants and spec workflow. Use when the user asks to review a PR, e.g. /pr-review 28 or /pr-review .
tura
Work in the Tura agent-runtime repository. Use for Tura architecture, Rust backend, GUI/TUI, prompts, commands, providers, sessions, documentation, tests, packaging, and release work in this directory.
openspec-update-change
Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Never edits code.
openspec-sync-specs
Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
openspec-apply-change
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.