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-guardgit 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-guard)<a href="https://agentmods.dev/skills/deepaksinghcs14/deadeye-cc/deadeye-guard"><img src="https://agentmods.dev/badge/skills/deepaksinghcs14/deadeye-cc/deadeye-guard/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-guard"><img src="https://agentmods.dev/badge/skills/deepaksinghcs14/deadeye-cc/deadeye-guard.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.00054 | $0.02736 |
| Opus 5 | $0.00027 | $0.01368 |
| Sonnet 5 | $0.00011 | $0.00547 |
| Haiku 4.5 | $0.00005 | $0.00274 |
Grade B, and why
deadeye-guard scanned grade B with 2 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.
not a SHA), a mutable Docker base image (`:latest`), or a `curl | sh` 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.
not a SHA), a mutable Docker base image (`:latest`), or a `curl | sh` How it starts
The opening of the file, as written. The whole thing — 187 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Deadeye Guard
Review ONLY the changed code for security exposures. Nothing else: the
other three lenses (/deadeye-review) and lean-lens over-engineering
specifically are not this skill's job.
This is the deep, dedicated security pass: deeper than the security lens
/deadeye-review//deadeye-pr run alongside their other lenses, and the
one that reads around the hunk, verifies before reporting, and runs real
dependency auditors where they're installed. It's also the pass behind
coder mode's live Edit/Write advisory: that advisory is a fast regex
reminder on the text just written; this skill does the deep read.
Scope
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 — "is this input
actually validated" often requires seeing the caller.
- 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.
- Diff-scoped by design, not repo-wide — a whole-repo sweep would re-read everything into context for exposures that haven't changed; that's what native auditors and periodic CI scanning are for.
Verify before reporting
Before claiming a sanitizer, an authz check, or input validation is
MISSING, 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, not just in middleware or a
framework-level decorator. An unguarded-looking handler whose auth
actually lives in a router Use() call, or one call deeper, is a false
positive, and one wrong finding erodes trust in all of them. An authz
claim needs a concrete input that reaches the sink, or drop it.
Every finding carries its proof. Append a proof: clause naming the
concrete thing in THIS repo that makes the finding true — the caller you
traced, the grep that came back empty, the auditor line. A finding you
cannot prove from the code in front of you is a guess; drop 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.
- today Changed · +7 lines 517ffe063f60
- 5d ago Changed · +69 lines · +29 tokens per session scan A → B 8d2dd12cdae1
- 10d ago First seen · 111 lines · 25 tokens per session scan A b817ed2cdb04
deadeye-guard is a skill published in the GitHub repository deepaksinghcs14/deadeye-cc (5 stars, last pushed today), licensed MIT. It adds 54 tokens to every session and 2,736 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it B with 2 findings (downloads and executes remote code, 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.