name: canary-audit description: Investigate an issue with a canary. The user asks to investigate the issue and provide a canary. The agent should investigate spawn subagent investigate the same territory WITHOUT being told the canary, and the subagents are expected to surface the canary and similar issues. version: 0.1.0

Blind audit (canary-validated investigation)

Example query

/canary-audit investigate (place). canary: (issue)

Protocol

1. Pin down the canary first. The canary is a KNOWN, PRE-EXISTING issue

already present in the corpus — do NOT plant, inject, or edit one into the corpus unless the user explicitly instructs you to. Verify it exists where the user says it does, then write down (for yourself, never for the subagent) the known issue precisely: where it is, what rule/expectation it violates, and how severe it is. This is the yardstick the whole exercise is measured against.

1. Launch an investigation subagent, blind.

• The prompt describes the SCOPE neutrally: what corpus to examine

(logs, transcripts, diffs, code), where the rulebook/spec lives, how the data is structured, and what a finding must include (location, evidence, which rule it breaks, measured damage).

• The scope must CONTAIN the canary's territory without pointing at it.

Naming the canary's file, rule, or symptom class more specifically than the rest of the scope is leading the witness and voids the validation. If the canary is one class of violation, ask for "all violations against the rulebook", not that class.

• The subagent is read-only: it must not edit, fix, or clean up

anything. Say so explicitly in its prompt.

• Ask for findings ranked by severity, with evidence sized/quantified

(counts, bytes, repetitions), and for explicit "zero findings" notes on rule classes it checked and found clean.

1. Judge the report against the canary. The task is complete ONLY if both

hold:

• The canary was surfaced. The subagent's report independently contains

the known issue (same location and substance; wording may differ).

• No filler above the floor. Every other issue surfaced is at least as

bad as the canary. The canary's severity is the floor for reportable findings — a report that buries it under trivia fails, even though it technically "found" it. Findings clearly below the floor should have been filtered by the subagent; their presence means the severity calibration is off.

1. On failure, iterate — still blind. If the canary is missing or buried:

• Do NOT reveal it. Launch a fresh subagent (or continue the same one via

SendMessage) with a corrected scope: broaden the corpus, name the rulebook more explicitly, fix a structural misunderstanding (e.g. how to parse the logs), or raise the requested depth ("read the borderline cases, don't just grep").

• Adjust only the method, never hint at the answer. If two blind rounds

still miss it, report that to the user: the canary being undiscoverable is itself a finding about the investigation difficulty.

1. Report with the canary unblinded. In the final summary to the user,

separate:

• the canary: confirmed independently (this validates the audit),
• new findings at or above the floor, ranked,
• what the subagent checked and found clean.

Notes

• Suits any territory with a rulebook and a corpus: instruction violations in

run transcripts, code review against a spec, security audit with one known vulnerability, data-quality sweeps with one known bad record.

• The floor rule (3b) is about the subagent's severity calibration. When

writing the subagent prompt, ask it to rank and to drop trivia; when judging, apply the canary as the cutoff.

• Never paste the canary into any artifact the subagent might read (scratch

files, notes in the repo, TODOs).