chimera-state-what-you-did-not-check
A ranking built from part of the system reads as a ranking of the system — write the scope and the exclusions next to the findings, not after them.
Conferred by a reviewer who read the card, not claimed by the file about itself. A card the agent distils during a run that consumed untrusted content is born tainted and is held for review before it is ever retrieved.
When it comes to mind
- writing a review or audit
- listing the top risks
- reporting findings
- ranking issues by severity
- someone asks if it is safe
Avoid and Check are where the value usually is. Do is the section everybody writes.
Trigger
You are delivering something that reads as a survey: a code review, a security pass, "the three biggest problems", a prioritised backlog, a comparison of options. Anything where you looked at some of a space and produced an ordering.
It does not apply to answering a bounded question — "does this function handle an empty list?" — where the scope is already the whole of what was asked. The risk here is specific to output whose form is a list of the worst things, because that form carries an implied "of everything" the reader will supply for free.
Do
- Open with the scope, before the findings. Name what you actually read: paths or globs, the
commit or branch, and whether you ran anything or only read.
Reviewed: src/api/*.py at 4f2a1c9, static read only, no tests executed. - List the exclusions with their reason, and keep the reasons concrete: no access to the migrations, the integration suite needs credentials I do not have, the frontend was out of budget for this pass.
- Scope every superlative to what you read. Not "the worst issue is the missing auth check" but "the worst of the six handlers I read". The two sentences cost the same and mean different things.
- Separate "checked and clean" from "not checked". A reader treats silence as a clean bill; only one of those two states earns it.
- Name the unchecked thing most likely to outrank your current number one, so the reader knows what the next pass should buy. If nothing plausible could, say that too — it is a real finding.
Avoid
Reporting "no SQL injection found" after a pass that never opened the database layer. The
sentence is literally true and functions as a clearance. Write "did not review db/ — no access
to the migration files" and the same pass now says what it knows.
Avoid putting the scope in a closing paragraph under a heading like Limitations. Readers act on the top of the document; a caveat below the ranking arrives after the decision it was supposed to qualify.
Avoid the ordering that spans checked and unchecked work. Ranking three reviewed modules against one you skimmed produces a list whose positions mean different things at different rows, and nothing in the layout tells the reader which is which.
Check
Ask one binary question of the finished document: can a reader who was not present name the files you read and the ones you did not, without asking you? If not, the scope is missing regardless of how careful the findings are.
Second, reread every superlative — worst, main, top, only, no — and confirm each one carries its qualifier in the same sentence. These words are where the partial quietly becomes global.
Risk
Exclusion lists can grow into blanket immunity: a document that disclaims everything asserts nothing, and reviewers who write them stop being accountable for the part they did cover. Keep the list to exclusions a reader would otherwise assume were included.
Stating scope also invites "then go check the rest", which is sometimes the wrong call — a deliberately partial pass on the highest-risk surface can be the correct use of the time. If so, say why that surface was chosen, or the honest disclosure gets read as an unfinished job.
And scope is not a substitute for depth. "I read these six files" does not mean the six were read well, and a precise boundary around shallow work still makes shallow findings.
Use it
The card is data. Clone the repository and import it by path — anything that arrives over the network is treated as tainted and held for approval, which is the behaviour you want and the reason there is no one-line installer here.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-state-what-you-did-not-check/SKILL.mdIntegrity
SHA-256 of the file as published. An importer can check that what it received is what this page showed.
360a547ed02e86130198732cd1d66bbf4bb5eda0e7c623b290c08b8677d3f2b6