Common foundation

The quality loop: check, assess, learn

A living checklist per deliverable, a double test with evidence, and a self-learning loop: every error found becomes a rule that Claude rereads before producing.

SkillArtifactClaude Code10 min per deliverable, 30 min per month

Screenshot of a real tool · fictitious data, names blurred

The problem

AI produces quickly and well, but not without errors: a reference that cannot be found, a misspelt name, a date off by one day, a broken link, a slide that does not match the template. If the error is not learned, it comes back in the next deliverable. Human proofreading, for its part, wears thin: you end up skimming what has always been right.

Step-by-step method

1. One checklist per type of deliverable (slide, schedule, manuscript, email, published page): five to ten verifiable points, phrased as yes-or-no questions.
2. First test, automatic: Claude goes through each point and answers “OK” or “GAP”, with the evidence (the identifier found, the directory line, the link tested). Whatever can be scripted is scripted (links, identifiers, duplicates, date formats).
3. Second test, human and targeted: you do not reread everything; you reread the gaps and a small random sample of the “OK” items. Test the interface, not just the code: on a page, every bulk-action button (approve all, archive all) is actually tried out, on test data.
4. Assess: a simple rating per deliverable (compliant, compliant with reservations, to be redone) and a dated record of what was checked.
5. Learn: every error found, by you, a colleague or an external reviewer, becomes a new line in the list, with the example that revealed it. The list is versioned (v1, v2…). Each learned rule fits on one line: date, reason, action, the sentence actually said. A rule that contradicts another does not erase it: both lines stay and the conflict is flagged. A new clue (a keyword, a threshold) is tested on all the cases already seen before it is kept, so that nothing that used to work gets broken.
6. Reread before producing: the list is part of the skill. Claude reads it before generating the deliverable, not only afterwards: a learned error does not happen again.
7. Weekly quality review: the week’s gaps, recurring errors, rules added, and rules never triggered in three months, candidates for removal.
8. System health map: one status light per building block (last run, gaps, errors) to spot a silent failure before it becomes costly. It grows richer over time:
   • a live test of the connectors, launched from the page;
   • alarms that you acknowledge without deleting them, with their history;
   • a “task succeeded but no log for today” check: runs marked as successful had in fact produced nothing;
   • a false positive is fixed in the check itself, never by ignoring the light;
   • a single notification, and only if there is one red or several amber lights.
9. A test bench: about twenty real requests, with the expected result, replayed after every change to a skill. A change that makes a previously successful request fail is not kept.
10. A judge who is not a player: whoever produces does not check for themselves that the loop has closed. A read-only sentinel names the gaps, and another skill repairs them: see The learning loop.

Deliverable

A living checklist per deliverable, a log of checks, a quality review every week.

Safeguards

The AI does not validate itself: a human check remains mandatory for anything that goes out (publication, email, submission). The loop proposes corrections and rules; it applies nothing without approval. An added rule is reviewed; a list that only ever grows longer is no longer read.

Starter prompt

Here is the deliverable and checklist v3. Go through each point and answer OK or GAP with the evidence. For each gap, propose the correction without applying it. Finish with the rules to add to the list, phrased as questions, with the example that justifies them.

← Back to the triptych