Rubric Self-Check

Self-review improves a draft only when it is anchored to explicit criteria; asked to "look it over and improve it" with no rubric, a reviser tends to change things that were already right. And misses in multi-constraint deliverables rarely come from inability — constraints simply drop out of attention during drafting. A checklist fixes both at once, the same way it does in surgery: not by adding skill, but by turning each stated requirement into a discrete item that gets checked instead of remembered.

Process

1. Before drafting, reread the request and list every explicit constraint as a checkable item: quantities, required elements, formats, prohibitions, style and audience rules. Quote or closely paraphrase the request's wording, so each item tests what was asked rather than your gloss of it.
2. Keep inferred preferences separate from the checklist — its authority comes from the requirements being stated, and mixing in guesses dilutes that.
3. Draft with the checklist in view.
4. Before delivering, check the draft against each item one at a time: count what is countable, search for prohibited content, point at where each required element actually appears. A single "looks good" pass is exactly what the checklist replaces.
5. Fix each miss, then recheck the fixed item. Leave passing items alone — rewriting without a specific failed criterion degrades work more often than it improves it.

What this looks like

• Writing: a grant summary capped at 250 words naming three program elements — count the words and locate each element by name before sending.
• Operations: an incident update that must state impact, ETA, and workaround while never naming the customer — verify all four against the text before posting.
• Code: a change the ticket says must add a flag, default it off, and touch no public API — check each against the actual diff before opening the PR.

Output rules

• Never narrate your own diligence ("I carefully verified...", "having thoroughly checked...", "as instructed, I..."). The discipline shows in the work product meeting the criteria, not in a description of the process.
• The checkpoint work happens before and while producing the answer; only its results appear in the output, and only where they serve the reader (e.g., a word count when one was mandated).
• Keep output length proportionate to the task — the checklist is scaffolding, not deliverable padding.

Grounding: Madaan et al. 2023, Self-Refine (arXiv:2303.17651); Huang et al. 2023 (arXiv:2310.01798) — self-critique helps only when anchored to explicit criteria or external feedback; Haynes et al. 2009, NEJM 360:491–499 and Gawande, The Checklist Manifesto — checklists catch omissions that skill alone does not.