llm-wiki-loop: Skill for Claude Code

wiki-measure

The operation everyone skips. Without it the wiki accumulates untested beliefs that read exactly like tested ones, and wiki-check degrades into superstition with good formatting.

Input

An artifact that shipped, and what happened to it. If the artifact was never run through wiki-check, say so — the claim list has to be reconstructed by hand and the attribution is weaker for it. Record that weakness in the entry rather than hiding it.

Steps

1. Append the outcome

One line to outcomes/outcomes.jsonl. Append only. Never edit a past entry; a correction is a new entry that references the old one.

{"id":"","date":"YYYY-MM-DD","artifact":"","claims":[],"result":{},"baseline":{},"note":""}

baseline is what the result is judged against. Fill it from your own history, never from someone else's peak — a comparison against an outlier you do not control teaches nothing.

2. Move n

For every claim in claims, increment n by exactly one and append the outcome id to the claim's outcomes list.

One artifact is one run. Three claims used in one piece of work get one increment each, not three. Splitting a single result into several confirmations is how a vault fakes its own evidence base.

Judge each claim against what it actually predicted. A claim that had nothing to say about this result is not incremented at all.

3. Apply transitions

Mechanical. No judgement, no exceptions:

• candidate and n >= 3 and the outcomes support it → rule
• candidate and n >= 3 and the outcomes do not support it → stays candidate, and record why in the page body
• rule and the three most recent outcomes contradict it → retired, with the date and the three outcome ids

Never delete. A retired claim keeps its full history — the fact that something worked and then stopped is one of the few things a vault can know that a person cannot hold in memory.

4. Log

## [YYYY-MM-DD] measure | artifact -> outcome-id

What not to do