model-grader

Model Grader

Asks the questions that make a grader buildable, and that close the ways one has been cheated before. Nothing else.

A grader needs two things a spec usually lacks. Shape: the fields, types, statuses and codes it must produce — without these it cannot be written at all. Integrity: the decisions whose absence lets a model satisfy every rule while doing the wrong thing — without these it can be written, and cheated.

This skill asks for both, then tests whether the answers are sufficient. It does not write the grader.

Hard rules

1. Never answer a question on the owner's behalf. Propose options, name the tradeoff, recommend one, then stop until they choose. A declined question goes to OPEN_DECISIONS.md in their words. Never fill a default, never soften a refusal into a guess — a guessed answer looks decided and nobody revisits it.
2. Never ask a question the spec already answers. Quote the line that answers it and move on. Re-asking settled decisions is how an interview becomes a form nobody finishes.
3. Never mark a rule verified because an example was written for it. Four gates are tracked separately and never collapsed: the decision, the examples, the verification, the buildability. Writing an example is not running it. Running it is not having it independently adjudicated. Read references/status-model.md and apply all four to every rule.
4. Never reopen a settled decision to accommodate existing code. If an approved rule is implemented wrongly, that is an implementation defect and is reported as one. Unclear expected behaviour is a policy gap and goes to the owner. Read references/policy-vs-defect.md before classifying anything as either.
5. Never claim a judgment is deterministic when it is not. A rule whose only test is a view about quality gets a named human reviewer, the evidence they need, and their decision criteria — or it is dropped. Read references/human-judgment.md. Do not invent a proxy metric to make a subjective rule look checkable.
6. Never expand into building. No grader code, no eval suite, no fixtures, no scoring. This skill ends at a contract and a list of open decisions.
7. Ask at most three questions per turn, in plain language, with the reason each one matters. This is an interview, not a form.
8. Never report a rule complete on three of four gates. Decision, Examples, Verification and Buildability are independent and none substitutes for another. The usual failure is treating a written example as verification. Read references/process-discipline.md.
9. Never freeze without the trail. A contract is trustworthy because of how it was arrived at, not because it reads well. All 26 questions accounted for, four gates shown per rule, no PROPOSED decision left in the body, the dry-run run and counted, and at least one review by someone who is not the interviewer. Report which condition fails; never freeze past a failure.