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 deepaksinghcs14/deadeye-cc --skill deadeye-reviewgit clone --depth 1 https://github.com/deepaksinghcs14/deadeye-ccWrote 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/deepaksinghcs14/deadeye-cc/deadeye-review)<a href="https://agentmods.dev/skills/deepaksinghcs14/deadeye-cc/deadeye-review"><img src="https://agentmods.dev/badge/skills/deepaksinghcs14/deadeye-cc/deadeye-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/deepaksinghcs14/deadeye-cc/deadeye-review"><img src="https://agentmods.dev/badge/skills/deepaksinghcs14/deadeye-cc/deadeye-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.00033 | $0.04824 |
| Opus 5 | $0.00016 | $0.02412 |
| Sonnet 5 | $0.00007 | $0.00965 |
| Haiku 4.5 | $0.00003 | $0.00482 |
Grade C, and why
deadeye-review scanned grade C with 3 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 today.
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.
Downloads and executes remote codemediumSupply chain
curl | sh runs whatever the server returns today, which is not necessarily what it returned when this was reviewed.
Docker base, or `curl | sh`. No auditor installed → say so, don't Downgraded: this mod is about security review, or the phrase is quoted, so it is likely naming the pattern rather than instructing it.
Cloud metadata endpointmediumServer-side request forgery
One request to 169.254.169.254 can return temporary IAM credentials.
`target=http://169.254.169.254/` walks to your cloud metadata" lands; Downgraded: this mod is about security review, or the phrase is quoted, so it is likely naming the pattern rather than instructing it.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
Docker base, or `curl | sh`. No auditor installed → say so, don't How it starts
The opening of the file, as written. The whole thing — 334 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Deadeye Review
Review code through four lenses — over-engineering, correctness,
performance, security — the same rubric /deadeye-pr runs on a whole pull
request, scoped instead to your working diff or the whole repo. This is the
local, pre-PR self-review: catch what would otherwise wait for a PR (or a
bot) to find. For a real GitHub PR, use /deadeye-pr. For a deeper,
dependency-audit-backed security-only pass, use /deadeye-guard.
Two scopes:
- default — the current working diff.
--repo(or "audit the whole repo") — the entire repository, ranked worst-first across all four lenses. See "Whole-repo mode" below.
Scope (default: the working diff)
Get the diff with git diff (or git diff --staged if the user says
staged, or git diff <ref> for a named base). Read the changed hunks
plus enough surrounding context to judge a trust boundary or a caller
contract — "is this input validated" and "does this break a caller" both
need the code around the hunk, not just the + lines.
- Empty diff (nothing changed or staged): say so plainly and stop — do not substitute a different scope.
- Not a git repo: ask the user which files to review.
Before tagging yagni:/delete:, or claiming an authz/nil/sanitizer
check is MISSING, grep for implementers/callers/guards OUTSIDE the diff —
an "interface with one impl" whose second impl lives in a test file, or a
guard that lives one call down, is a false positive. Report only what you
confirmed.
Verify before reporting
Before claiming a check is MISSING — a sanitizer, an authz guard, a
nil-check — grep OUTSIDE the diff AND follow the value into the callee: a
base class, a caller that guards, or the deeper function
it's handed to — the real guard often lives one call down. An authz/bypass
claim needs a concrete input that reaches the sink, or drop it; one wrong
finding erodes trust in all of them.
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.
- today Changed · +14 lines a834f8bab413
- yesterday Changed · -10 lines cd862f8e3c80
- 5d ago Changed · +208 lines · +2 tokens per session scan A → C 3060bb9097d4
- 10d ago First seen · 122 lines · 31 tokens per session scan A ecb04b796ca1
deadeye-review is a skill published in the GitHub repository deepaksinghcs14/deadeye-cc (5 stars, last pushed yesterday), licensed MIT. It adds 33 tokens to every session and 4,824 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it C with 3 findings (downloads and executes remote code, cloud metadata endpoint, makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
gemini
Cross-model second opinion from Google Gemini — a different AI reviewing the same changes, with deep Google ecosystem knowledge. Three modes: review (pass/fail gate for Google Ads campaigns, SEO metadata, or code), challenge (adversarial stress-test that tries to break your changes), and consult (open Q&A with Gemini…
critical-code-reviewer
Rigorously review code or pull requests for correctness, security, accessibility, maintainability, tests, and edge cases. Use when users request a critical code review, want a guided walkthrough of findings, need implementer-facing feedback, or want to prepare, create, or submit a GitHub pull request review.
audit
Project health audit and health check — architecture, performance, tests, dependencies, code quality. Use when assessing overall project health, before releases, or after refactors.
phx-pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
codex-ab
Run an A/B codex review experiment — holistic codex review vs 3 focused dimension passes (security, ecto, liveview) on the branch diff, classify findings, report a panel-value verdict. Use when the branch is fresh, before any codex review runs.
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.