/deadeye

name: deadeye
description: "deadeye's home command: `/deadeye` (status), `/deadeye config` (view or change any setting), `/deadeye theme [name]`, `/deadeye stats [view]` (every report deadeye computes about itself), `/deadeye help` (the reference card). With the Claude Code mod on these open panes; otherwise they work from chat."
argument-hint: "[config|theme [name]|stats [impact|savings|context|accuracy|disagreement|adherence] [session-id]|help]"
allowed-tools: Bash(deadeye status), Bash(~/.deadeye/bin/deadeye status), Bash(deadeye config *), Bash(~/.deadeye/bin/deadeye config *), Bash(deadeye gain), Bash(~/.deadeye/bin/deadeye gain), Bash(deadeye audit), Bash(~/.deadeye/bin/deadeye audit), Bash(deadeye context *), Bash(~/.deadeye/bin/deadeye context *), Bash(deadeye misses), Bash(~/.deadeye/bin/deadeye misses), Bash(deadeye disagreement), Bash(~/.deadeye/bin/deadeye disagreement), Bash(deadeye adherence), Bash(~/.deadeye/bin/deadeye adherence)

/deadeye

One command, five jobs. The first argument picks the job; with the Claude Code mod on (`mode.mod on`) the mod answers the same command with panes instead of this text, so nothing here runs. If `deadeye` reports "command not found" it's just not on PATH (deadeye never adds itself to PATH; it resolves its own binary internally for hooks): retry with `~/.deadeye/bin/deadeye`. Only if that also fails is it not bootstrapped yet (it self-installs on the first hook invocation).

`/deadeye` (no argument)

Run `deadeye status` and present it under these headings: **Modes** (per-axis), **Coder mode** (persona, live level), **Kill switches** (flag any OFF), **Catalog** (tier table, source, build date -- flag if stale), **Daemon** (up/down). Surface a `CLAUDE_CODE_EFFORT_LEVEL` note prominently if present.

`/deadeye config [what to change]`

You are the settings picker. Run `deadeye config list` for every key, its current value and allowed values; show it as a short list. For what a key DOES, link https://deepaksinghcs14.github.io/deadeye-cc/settings.html -- don't retype those explanations.

• If the user already said what they want ("plan gate off", "coder to

sniper", "theme nord"), map it to the key and value and apply it.

• Otherwise ask which setting, then which value.

Apply with exactly:

deadeye config set <key> <value>

It validates against the schema and writes `~/.deadeye/config.json`, preserving every other setting. Show the confirmation line it prints.

Keys and allowed values (authoritative -- never invent others):

| Key | Values | |---|---| | `mode.routing` | off · advise · enforce | | `mode.effort` | off · advise · enforce | | `mode.preprocess` | off · on | | `mode.plan_gate` | off · soft · hard | | `mode.workflow_hint` | off · on | | `mode.codemap` | off · on | | `mode.update_check` | off · on | | `mode.routing_judge` | off · on | | `mode.catalog_check` | off · on | | `mode.tier_sample` | off · on | | `mode.mod` | off · on | | `mod.theme` | auto · marksman · nightvision · highnoon · blueprint · ghost · tokyonight · catppuccin · rosepine · gruvbox · dracula · nord · kanagawa · everforest · synthwave · solarized · dawn | | `mod.repaint` | off · on | | `mod.background` | off · on | | `mod.hud` | auto · full · deadeye · off | | `mod.tips` | off · on | | `mod.sounds` | off · on | | `mod.notify` | off · on | | `coder.default_level` | off · spotter · marksman · sniper | | `coder.security` | off · advise · ask | | `coder.security_osv` | true · false | | `security.exfil` | off · advise · ask |

Also settable (free-form): `coder.subagent_matcher` (regex), `downshift_threshold` (0-1), `injection_budget_tokens` / `coder.injection_budget_tokens` (int), `plan_gate.min_files` (int), `tier_sample.rate` (int).

`/deadeye theme [name]`

With a name: `deadeye config set mod.theme <name>` (one of the `mod.theme` values above, or `auto`). Without one: list the themes with a one-line feel for each, point at https://deepaksinghcs14.github.io/deadeye-cc/themes.html to see them drawn, and ask which. The theme shows only with the mod on.

`/deadeye stats [view] [session-id]`

One entry point for every report deadeye computes about itself. Pick a view by the argument; with none, show the measured-impact scoreboard.

Economics, from the decision log (`~/.deadeye/decisions.jsonl`):

• no view, or `impact` → the measured scoreboard (`deadeye gain`)
• `savings` → the full token-savings report (`deadeye audit`)
• `context [session-id]` → per-session context-byte breakdown (`deadeye context [session-id]`)

Judgment, from review/coder receipts (`~/.deadeye/receipts.jsonl`) and the outcomes store -- deadeye checked against what actually happened:

• `accuracy` → candidate review misses and recorded disputes (`deadeye misses`)
• `disagreement` → where the judge would have routed cheaper (`deadeye disagreement`)
• `adherence` → the coder ladder's checkable rungs on shipped diffs (`deadeye adherence`)

The three judgment views measure GOING FORWARD only: they read receipts written when a review or coder session runs, and nothing before this feature existed left one. An empty report means "not measured yet", never "nothing wrong" -- say which.

`deadeye gain`'s last line is a `file://` link to a regenerated visual report (`deadeye report` under the hood) -- relay it as-is, the same as every other figure.

Run the matching binary and present its output **as-is** -- every figure comes from the decision log, the receipts log, or the repo's own git history, not an invented aggregate. If the log is empty, the binary prints its own explanation -- relay it as-is and suggest running a task with the plugin active first.

Honesty boundaries (load-bearing -- do not soften)

**impact (`deadeye gain`)**

• NEVER print a per-repo savings percentage for code that was never

written -- the unbuilt version has no baseline to subtract from.

• Estimates and measurements are labeled differently in the output; keep

that distinction.

• For per-repo reality