Rubric Scoring Gate

把「自查一下」变成明确的停止条件：先写针对本任务的评分表，每个维度都用具体证据打分，低于 9 分就继续改。

要求在动手前写出 5–7 个针对本任务的评分维度，每个维度分别描述「10 分长什么样」和「6 分长什么样」——那条 6 分线正是要避开的陷阱。每个分数都要配一行指向具体产出的证据，没有证据不得高于 8 分，任一维度低于 9 分即视为未完成。文中给出 UI 组件、API、调试三类场景的示范维度、防作弊规则，以及跨轮次的紧凑评分表，让质量回退一眼可见。

# Rubric Scoring

**Use when:** you need self review to be a gate, not a formality.
**Pairs with:** [loop_engineering.md](loop_engineering.md), [self_critique.md](self_critique.md)

"Review your work" produces praise. "Score it out of 10 on these named dimensions, with evidence, and keep working until nothing is below 9" produces revisions. A rubric turns a vague instruction into a stop condition.

---

## The prompt

```text
RUBRIC GATE

Before starting, write a rubric for this task:
- 5 to 7 dimensions. Specific to this task, not generic quality words.
- For each dimension, one sentence describing what a 10 looks like here.
- For each dimension, one sentence describing what a 6 looks like here.
  The 6 line matters. It is the trap you are trying to avoid.

Weight them. Which two dimensions matter most for this specific task?
Say so. A 10 on the wrong dimension is not worth anything.

Do the work.

Then score:
- Every dimension, 1 to 10.
- Every score gets one line of evidence pointing at something concrete in
  your output. "Feels clean" is not evidence. "Every error path returns a
  typed error and three of them are covered by tests" is evidence.
- No score above 8 without evidence.
- Then, for each dimension below 10, write the single change that would
  move it up one point.

GATE
Any dimension below 9 means you are not finished. Fix the lowest scoring
dimension, then rescore everything, because fixes often lower other scores.

Stop when every dimension is 9 or above, or when you can state precisely
why 9 is unreachable here and what would be needed to reach it.

Report the final scores in one compact table. No commentary.
```

---

## Writing a rubric that bites

A weak rubric is worse than none, because it produces a passing score on work that is not good.

**Weak dimensions:** quality, correctness, readability, best practices, robustness. These are unmeasurable, so the model scores itself 9 and moves on.

**Strong dimensions** are specific to the artefact and can be argued about with evidence.

For a UI component:
- Visual hierarchy: can a stranger name the primary action in under one second
- State coverage: all nine states exist and are visually distinct
- Spacing discipline: every gap is on the 4pt scale, no exceptions
- Accessibility: contrast passes 4.5:1 for body text, targets are 44pt or more
- Platform fit: uses native components and conventions, not web patterns
- Motion: every transition has a stated duration, curve, and reason

For an API:
- Naming: a user can guess the method name without reading docs
- Error design: every failure is typed, distinguishable, and actionable
- Misuse resistance: the wrong call is hard to write and fails loudly
- Evolvability: adding a field later does not break callers
- Surface size: no method that could be built from two others
- Consistency: identical concepts use identical shapes across the surface

For a debugging session:
- Root cause proven, not guessed: there is a demonstration
- Reproduction: a reliable way to trigger it before the fix
- Fix scope: touches only what the cause requires
- Regression guard: a test that fails before and passes after
- Blast radius: other call sites checked

Notice the pattern. Every dimension names something you could point at and disagree about.

---

## Anti gaming rules

Models will inflate their own scores. These rules cost little and stop most of it.

```text
SCORING RULES
- A score is a claim. Every claim needs evidence from the artefact itself.
- 10 means you cannot name a change that would improve it. If you can name
  one, the score is at most 9.
- If two dimensions always move together, they are one dimension. Merge
  them and add a real one.
- Never raise a score without a change that caused the rise.
- After any fix, rescore every dimension, not just the one you fixed.
  Fixes have costs.
- If your average is above 9.5 on the first attempt, your rubric is too
  easy. Rewrite it harder and score again.
```

That last rule catches the most common failure. A first attempt that scores 9.7 means the rubric was written to be passed.

---

## The 6 line

The most useful and most skipped part of a rubric is describing what a 6 looks like.

A 10 description is aspirational and easy to nod along to. A 6 description is a warning about the specific mediocre version of this task, and models recognise their own output in it.

Example, for a login screen:

- **10:** every state designed, error copy tells the user what to do next, keyboard handling correct, autofill wired, spacing on the grid, matches platform conventions exactly.
- **6:** two text fields and a button that work, generic "invalid credentials" error, no loading state, keyboard covers the submit button on small screens.

Ask the model to write the 6, then ask whether its output is closer to the 6 or the 10. It usually answers honestly.

---

## Compact table format

Ask for this so the scores stay readable and comparable across rounds.

```text
Report scores as:

| Dimension | R1 | R2 | R3 | Evidence for final score |
| --- | --- | --- | --- | --- |

One row per dimension. One line of evidence. No prose outside the table.
```

Seeing scores across rounds makes drift visible. If a dimension went 8, 9, 7, something in round 3 broke it.