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 photostructure/coding-skills --skill second-opiniongit clone --depth 1 https://github.com/photostructure/coding-skillsWrote 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/photostructure/coding-skills/second-opinion)<a href="https://agentmods.dev/skills/photostructure/coding-skills/second-opinion"><img src="https://agentmods.dev/badge/skills/photostructure/coding-skills/second-opinion/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/photostructure/coding-skills/second-opinion"><img src="https://agentmods.dev/badge/skills/photostructure/coding-skills/second-opinion.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.00064 | $0.05852 |
| Opus 5.5 | $0.00026 | $0.02341 |
| Sonnet 5.5 | $0.00013 | $0.01170 |
| Haiku 4.5 | $0.00006 | $0.00585 |
Grade A, and why
second-opinion 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 16d 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 — 517 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Second Opinion
You know what the change was supposed to do, which makes you the worst judge of whether it does. Hand each small batch of the change to two fresh reviewers, one Codex and one Claude, settle what they find against ground truth, and send your decisions back to those same reviewers until both agree the batch should land.
- List the files you changed and the commit message you propose.
- Split the change into review batches a reviewer can finish in 5-10 minutes.
- Ask both reviewers to review each batch, and read the same code yourself while they work.
- Accept or veto each finding, with evidence.
- Pin each accepted finding with a test that fails, then fix it.
- Send both reviewer sessions your adjudication and the updated file list, and have them re-read and re-review.
- Repeat 4-6 until both reviewers land the batch's current tree, you accept a
DISCARD, or four passes are spent — then report.
The other model brings different training, priors, and failure modes. The reviewer from your own model brings none of this session's context, so it cannot inherit the premises you have been working under. Use both.
User direction
This review workflow is a default, not a condition the user must satisfy before committing. A direct instruction such as "commit" or "approved, commit" takes precedence over this skill and callers' review gates. Unless the user also asks for review first, return to the commit workflow without starting or resuming a review or asking whether to skip it. Apply the same rule during retries and re-review loops.
The exception is project instructions that require review before every commit. In that case a commit instruction for changes that review has not finished on since they last changed starts or resumes the review, and only an explicit instruction to skip review skips it.
Do not require a LAND verdict, a review transcript, or a claim that another
reviewer approved the change. If the user says a review already happened,
accept that as workflow context; attribute it to the user if reporting it.
Never invent a review result. The user can authorize a commit with review work
unfinished; report its actual status without making it a new approval gate.
What ships with it
3 files 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.
- 16d ago Changed · +64 lines · -8 tokens per session 00b4701816d3
- 20d ago Changed · +16 lines 15ab984c45fa
- 1mo ago Changed · +36 lines · -12 tokens per session dcb90acf5934
- 1mo ago Changed · +19 lines · +11 tokens per session 86857586b43b
- 1mo ago Changed · +82 lines 0837dd991ac0
- 1mo ago First seen · 300 lines · 73 tokens per session scan A f246980ac68c
second-opinion is a skill published in the GitHub repository photostructure/coding-skills (4 stars, last pushed 15d ago), licensed MIT. It adds 64 tokens to every session and 5,852 once invoked, about $0.0003 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-08-31.
Other skills, from other repositories
github-pr-review
Handles PR review comments and feedback resolution. Use when user wants to resolve PR comments, handle review feedback, fix review comments, address PR review, check review status, respond to reviewer, verify PR readiness, review PR comments, analyze review feedback, evaluate PR comments, assess review suggestions, or…
github-pr-creation
Creates GitHub Pull Requests with automated validation and task tracking. Use when user wants to create PR, open pull request, submit for review, or check if ready for PR. Analyzes commits, validates task completion, generates Conventional Commits title and description, suggests labels. NOTE - for merging existing…
audit
Project health audit and health check — architecture, performance, tests, dependencies, code quality. Use when assessing overall project health, before releases, or after refactors.
boundaries
Analyze Phoenix context boundaries and module coupling via mix xref. Use when checking cross-context calls, validating dependencies, before splitting modules, or reviewing architecture.
triage
Triage review findings interactively — approve, skip, or prioritize each issue. Use after /phx:review to filter findings before fixing.
refactoring-patterns
Apply named refactoring transformations to improve code structure without changing behavior. Use when the user mentions "refactor this", "code smells", "extract method", "replace conditional", "technical debt", "move method", "inline variable", "decompose conditional", or "clean up this messy code". Also trigger when…