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 wolfenazz/YzPzCode --skill diff-reviewgit clone --depth 1 https://github.com/wolfenazz/YzPzCodeWrote 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/wolfenazz/yzpzcode/diff-review)<a href="https://agentmods.dev/skills/wolfenazz/yzpzcode/diff-review"><img src="https://agentmods.dev/badge/skills/wolfenazz/yzpzcode/diff-review/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/skills/wolfenazz/yzpzcode/diff-review"><img src="https://agentmods.dev/badge/skills/wolfenazz/yzpzcode/diff-review.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.00039 | $0.00469 |
| Opus 5.5 | $0.00016 | $0.00188 |
| Sonnet 5.5 | $0.00008 | $0.00094 |
| Haiku 4.5 | $0.00004 | $0.00047 |
Grade A, and why
diff-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 1mo 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.
This is a copy
88% identical to diff-review — 4 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
What it actually says
Diff review
Spec §20.3 / §21.3.2: a code-migration / tune-collab handoff is worthless without a human-reviewable diff. This atom is the "present the patch, capture the decision" stage.
Inputs
- The project cwd's accumulated edits since the run started (or since the previous diff-review iteration).
plan/steps.jsonfor context per file.
Output
project-cwd/
└── review/
├── diff.patch # unified diff (git apply-shaped)
├── summary.md # human-friendly per-file walkthrough
├── decision.json # { decision: 'accept' | 'reject' | 'partial', accepted_files: [...], rejected_files: [...], reviewer: 'user' | 'agent' }
└── meta.json # { generatedAt, atomDigest, planRevision }
The atom raises a choice GenUI surface with the three top-level
decisions (accept / reject / partial). On partial the user
flips per-file decisions through follow-up surfaces.
Convergence
The atom completes when decision.json has a non-empty decision.
Acceptance writes handoffKind: 'patch' (or 'deployable-app'
when a successful build-test is on file) into the eventual
artifact manifest; rejection rolls back the patch via git restore
or the equivalent in the code-import-bound repo path.
Anti-patterns the prompt fragment forbids
- Skipping the surface and assuming acceptance.
- Generating a
decision.jsonthat lacksaccepted_files/rejected_filesonpartialdecisions. - Rolling back files outside
plan/steps.json's union offiles[]— the patch boundary is a contract.
Status
Reserved id, prompt-only fragment in v1.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 1mo ago First seen · 55 lines · 39 tokens per session scan A 63017360f72d
diff-review is a skill published in the GitHub repository wolfenazz/YzPzCode (20 stars, last pushed yesterday), licensed Apache-2.0. It adds 39 tokens to every session and 469 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 88% identical to diff-review, differing in 4 lines, and is treated as a copy.
Other skills, from other repositories
critty
Review code changes or a document with Critty's terminal UI and address the reviewer's inline comments round by round. Use when the user or an approval workflow selects Critty; a generic review request does not count.
git-workflow
Git workflow and conventional commits. Use when working with git, branches, commits, pull requests, code review, or version control strategy.
loop-gh-pr
A recipe for a scheduled GitHub pull-request watcher. It checks open pull requests for new activity and prepares read-only review drafts without posting comments or merging anything.
git-iris
Use this skill when generating commit messages, pull request descriptions, release notes, changelogs, or code reviews in a repository where git-iris is available. Activates on requests like "commit this", "write a commit message", "draft a PR", "generate release notes", "write a changelog", or "review my changes" when…
pr-review-fix-pipeline
Reviews a PR and applies fixes for the non-controversial findings: review, fix, test, and commit in one pass. Writes code, so use it only on feature branches where automatic edits are fine. Trigger on: "review and fix PR", "auto-fix the PR", "review PR #X and fix issues", "run the review pipeline".
requesting-code-review
Use when implementation is done and you need a structured pre-PR review workflow. Triggers: 'ready for review', 'review my changes before PR', 'pre-merge check', 'is this ready', 'submit for review'. NOT for: post-merge review (use code-review) or deciding how to integrate (use finishing-a-development-branch).