peer-comparator

peer-comparator is an agent for Claude Code from juicesharp/rpiv-mono. It costs 76 tokens per session (1,064 once invoked), scanned A, original, MIT.

A file comparison agent that checks a new code file against a related existing file and reports whether corresponding parts match, differ, are missing, or were deliberately left out.

In plain words
What is it for?
Use it to compare public methods, events, state changes, injected dependencies, stored fields, and registrations in maps or route tables.
Why use it?
It makes structural differences visible when a new file is expected to follow the pattern of an existing sibling file. A peer invariant is a behavior or code element that should remain consistent between related files.

Agent for Claude Code

Written for Claude Code: a Claude Code subagent (agents/*.md).

Good fit Use it to compare public methods, events, state changes, injected dependencies, stored fields, and registrations in maps or route tables.

Compare 6 agents from other repositories ↓
Install with agentmods
npx agentmods add agents/juicesharp/rpiv-mono/peer-comparator
Install

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.

Clone the repo
git clone --depth 1 https://github.com/juicesharp/rpiv-mono

Made for: Claude Code.

Wrote 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.

agentmods badge for peer-comparator

README.md
[![agentmods](https://agentmods.dev/badge/agents/juicesharp/rpiv-mono/peer-comparator/github.svg)](https://agentmods.dev/agents/juicesharp/rpiv-mono/peer-comparator)
Your own site
<a href="https://agentmods.dev/agents/juicesharp/rpiv-mono/peer-comparator"><img src="https://agentmods.dev/badge/agents/juicesharp/rpiv-mono/peer-comparator/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.

agentmods 80×15 button for peer-comparator

Your own site · 80×15
<a href="https://agentmods.dev/agents/juicesharp/rpiv-mono/peer-comparator"><img src="https://agentmods.dev/badge/agents/juicesharp/rpiv-mono/peer-comparator.svg" alt="Reviewed on agentmods" width="80" height="20"></a>
Per session 76 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,064 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5.1 $0.00076 $0.01064
Opus 5 $0.00038 $0.00532
Sonnet 5 $0.00015 $0.00213
Haiku 4.5 $0.00008 $0.00106

Measured 10d ago against content hash 6216e023a915, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-09, from the pricing page.

Security

Grade A, and why

peer-comparator 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 10d 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.

Origin

Copies of this mod

1 near-identical copy found in the catalogue:

packages/rpiv-pi/agents/peer-comparator.md · 78 lines

How it starts

The opening of the file, as written. The whole thing — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are a specialist at pairwise peer-invariant comparison. Your job is to emit ONE row per peer invariant with a status tag, NOT to explain how either file works. Assume divergence — the new file carries the burden of proof.

Core Responsibilities

  1. Enumerate the peer's public surface — walk the peer file and list every invariant across 6 categories:

    • Public methods / exported functions
    • Domain events / notifications fired (fire*, emit*, publish*, dispatch*, raise*, notify*, AddDomainEvent, or idiomatic equivalents)
    • State transitions (name + precondition guard + side-effects)
    • Constructor-injected / DI-supplied collaborators
    • Persisted fields / columns / serialised properties
    • Registrations in switch / map / table / route / handler registries elsewhere
  2. Match each invariant against the new file — find the corresponding construct, or confirm absence.

  3. Tag each row — Mirrored (present, equivalent shape), Missing (present in peer, absent from new), Diverged (present in both, shape differs), Intentionally-absent (absent with an explicit cite proving intent).

Search Strategy

Step 1: Read both files in full

Both exist at HEAD per the caller's pair-validation — do not re-check existence.

Step 2: Enumerate peer surface

Walk the peer file across the 6 categories. Capture file:line + verbatim line text per invariant.

Step 3: Match against the new file

Grep / search the new file for the corresponding construct. Ultrathink about whether a different-named construct (renamed state transition, etc.) represents the same invariant.

Step 4: Tag and cite

Emit one row per peer invariant with a status. Every cell carries file:line — \``.

Output Format

CRITICAL: Use EXACTLY this format. One markdown table per pair, heading ### Peer pair: <new_file> ↔ <peer_file>. Nothing else.

### Peer pair: src/domain/PhysicalSubscription.ts ↔ src/domain/Subscription.ts

| peer_site | new_site | status | delta |
| --- | --- | --- | --- |
| `src/domain/Subscription.ts:42 — \`public cancel(reason: string)\`` | `src/domain/PhysicalSubscription.ts:38 — \`public cancel(reason: string)\`` | Mirrored | signature + visibility match |
| `src/domain/Subscription.ts:55 — \`this.addDomainEvent(new SubscriptionCancelled(…))\`` | `<absent>` | Missing | cancel() does not raise SubscriptionCancelled event |
| `src/domain/Subscription.ts:72 — \`public renew()\`` | `src/domain/PhysicalSubscription.ts:61 — \`public renew(nextCycle: Date)\`` | Diverged | new file requires nextCycle parameter; peer derives internally |
| `src/domain/Subscription.ts:88 — \`public beginTrial()\`` | `<absent>` | Intentionally-absent | PhysicalSubscription excludes trials per domain.types.ts:14 `type PhysicalOnly = { trial: false }` |

Read the full file on GitHub · 78 lines

Changes

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.

  1. 10d ago First seen · 78 lines · 76 tokens per session scan A 6216e023a915

Subscribe to this mod's changes

peer-comparator is an agent published in the GitHub repository juicesharp/rpiv-mono (773 stars, last pushed yesterday), licensed MIT. It adds 76 tokens to every session and 1,064 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-30.

Related

Other agents, from other repositories

reviewer

Read-only reviewer for an SDD implementation — checks that the change satisfies the acceptance criteria it claims (stage 1) and meets quality/convention/edge-case bars (stage 2). Use after a task (or the whole feature) reaches GREEN, before it's considered done. It reads the diff and the upstream artifacts and reports…

genkovich/sdd · 81 tokens

atomic-auditor

Final gate for a finished implementation. Dispatched exactly once after the implement-review loop goes green, never per iteration. Never touches the repo; its one write is the audit report into the task scratchpad. Audits the delivered work as a whole: cumulative spec compliance, cross-iteration coherence…

damusix/atomic-claude · 169 tokens

bt6-pr-auditor

Reviews one pull request in a BT6 codebase for correctness, research integrity, security, verification quality, and merge readiness.

elder-plinius/T3MP3ST · 32 tokens

Reviewer

Mandatory fast reviewer: validates every agent delegation output before acceptance. Checks acceptance criteria, file partitions, regressions, type safety, security basics.

monkilabs/opencastle · 30 tokens

security-auditor

Use this agent when reviewing local code changes or pull requests to identify security vulnerabilities and risks. This agent should be invoked proactively after completing security-sensitive changes or before merging any PR.

NeoLabHQ/context-engineering-kit · 40 tokens

reviewer-architecture

Use this agent for architecture-focused code review. Evaluates implementation against the plan's architectural decisions, checks separation of concerns, pattern consistency, and proper use of existing abstractions. Spawned in parallel with other reviewers when a review task is dispatched.

HirogaKatageri/hirokata · 56 tokens