grilllisted

# grill `code-review` checks whether a change looks correct. `grill` tries to break a design, plan, diff, or claim before you trust it. Use `self-refute` on your own fresh output. Use `grill` on something you are being asked to trust. ## When to use it - A design, plan, or diff that is about to be trusted, merged, or shipped. - A claim that needs to hold under pressure, not only sound right. - For a claim that must be recomputed from a source of truth, use `prove`, the heavier sibling; grill argues, prove recomputes. - Skip it for a small, reversible change already covered by code-review. ## Required inputs - The thing to test: the design, plan, diff, or claim. - Any spec or docs it rests on, so claims can be checked against what was promised. ## Steps 1. List the key claims. Name the three to seven things the design, plan, diff, or claim depends on. 2. Attack each claim. Write the strongest concrete counter-case: an input, sequence, race, missing precondition, or assumption that breaks it. 3. Cross-check against the spec or docs when they exist. Flag disagreements and claims with no enforcement. 4. Rank the results. Mark each claim `SURVIVED` with the reason, or `BROKEN` with the counter-case and a severity of blocker, major, or minor. ## Output format - Claims: the key claim list, one line each. - Findings: per claim, `SURVIVED` or `BROKEN`, with the counter-case and severity for broken ones. - Verdict: one line. Trustworthy as-is, trustworthy with the listed fixes