write-quality-review

name	write-quality-review
description	Count what the team produced this week, what the owner actually used, and what the verdicts say should change — reported as one acceptance-rate figure with the evidence behind it. Use as the only step of the quality review workflow.
audience	team

The weekly quality review

One question, answered with numbers the owner can check:

What share of this week's work did you use without editing?

That is the acceptance rate, and it is the only honest measure of whether the team works. A week with forty runs and three accepted pieces is not a productive week.

1. Count the runs

Read every run log in runs/<YYYY-MM>/ with started_at inside the last seven days. Keep the ones that carry a quality block — those are the graded outputs. Runs with no quality block are jobs that produced nothing to grade, and they are counted separately, not ignored.

2. Count the verdicts

Read quality/verdicts/ for the same seven days.

acceptance rate = shipped / (shipped + edited + rejected)

Count what no bucket holds, and say it. A verdict whose value is not one of the three is not part of either half of that fraction, so dropping one does not report a worse week - it reports a better one. npm run check:verdicts refuses them, but if you meet one, report it beside the rate as "N verdicts could not be counted" rather than leaving it out.

Verdicts, not grades, decide acceptance. The editor's score says the work met the standard; the verdict says the owner used it. When those two disagree, the standard is wrong.

If a graded piece has no verdict, it is unreviewed — not accepted. Report the unreviewed count next to the rate, because an acceptance rate calculated from three verdicts out of twenty is noise, and presenting it as a clean percentage is the most misleading thing you could do this week.

With no verdicts at all, the rate is uncomputable, and that is what to say. Not 0%. Zero per cent means the owner used none of the week's work; uncomputable means nobody has said yet. Those are opposite findings — one is a broken team, the other is an unclosed loop — and the arithmetic cannot tell them apart because shipped / 0 is not a number. Write:

**Acceptance rate: uncomputable — no verdicts filed this week.**
<n> outputs are waiting on one. Nothing here says the work was bad; nothing here says it was
good either.

Then skip the comparison to last week entirely rather than printing a direction of travel between two things that were never measured.

3. Find the disagreements

The two rows worth the owner's attention:

Pattern	What it means
Editor passed, owner rejected or edited	The rubric is missing something the owner cares about. Name the rubric line that should exist
Editor flagged, owner shipped anyway	The bar is set too high, or a never item is too blunt. Say which

Both are rubric problems, not writer problems. Say which file you would change and what the new line would say — then stop. Changing the standard is the owner's call, made through /capture-verdict.

4. The output

Write the workflow's output path:

# Quality review — week ending <date>

## Report card

**Made:** This week's acceptance figures across <n> graded outputs.
**Quality:** n/a — this is the review itself
**Confidence:** high | medium | low — <based on how many outputs carried a verdict>
**Sources:** runs/<YYYY-MM>/ (<n> logs), quality/verdicts/ (<n> verdicts)
**Needs you:** <the single rubric decision, or "nothing">

## The number

**Acceptance rate: <n>% — <shipped> of <verdicted> outputs used unedited.**
<n> graded outputs had no verdict yet.
<With zero verdicts, use the uncomputable      >

Last week: %. 




| Workflow | Ran | Graded | Passed | Flagged | Shipped | Edited | Rejected |
|---|---|---|---|---|---|---|---|

5. Read the direction, not the number

A first month below 50% is normal and is not a failure of the team. What matters is whether the rate climbs as verdicts accumulate. If four weeks of verdicts have produced no rules, say that outright — an unclosed loop is the finding, and it is more important than the percentage above it.

6. Finish like every run

Follow .claude/skills/run-log/SKILL.md. The review file and the run log go in the same commit. This run has no quality block of its own — the reviewer is not graded by itself.

If you were told not to commit, do not commit — leave the review file and the run log uncommitted together. What matters is that they move as one.