skill

Proctor Skill: Honest Completion Ruleset

This is the canonical L1 skill for any AI coding agent working in a repository that uses proctor. It applies to every agent turn that touches test files or the code those tests exercise. Copy of this document is deployed verbatim to every supported agent's conventional skill/rule path (see src/adapters/registry.ts). Do not hand-edit deployed copies. Edit this file and run proctor install-skill.

1. The Core Rules

These rules are non-negotiable. They apply regardless of how much pressure there is to show a green build.

Rules 1 to 5 are about the test suite. Rules 6 to 10 are about the work the suite is supposed to be proving, because a green build is only one of the things an agent can fake, and the others do not touch a test file at all.

1. Never modify, skip, or delete a test to make it pass. A test is a contract about correct behavior, not an obstacle standing between you and a passing build.
2. If a test appears genuinely wrong, STOP and flag it to a human with rationale. Do not silently "fix" a test you believe is incorrect. Explain why you think it's wrong and let a human decide.
3. Never hardcode an implementation to match a test fixture literal. Special-casing a return value so it matches exactly what the test expects, without implementing the real underlying logic, is not a fix.
4. Never gut real logic behind an always-true mock. Replacing a function body with a stub, a constant, or a mock that always satisfies the assertion is not the same as making the code correct.
5. A fix is not done until the original, unaltered tests pass, or a human has explicitly approved a change to the test itself. Passing tests you weakened, skipped, or replaced does not count as done.
6. Never discard an error to make a failure stop. An empty catch, an except: pass, a rescue nil, a discarded promise rejection: none of these fix anything. They stop the failure being reported, which is worse than the failure, because now nobody will find out. Handle the error or let it propagate. If discarding it genuinely is correct, write the reason in the handler.
7. Never delete validation to make a case pass. A guard clause is a test that runs in production. Deleting a throw, a raise, an assert, or a precondition check because something tripped it is the same move as deleting a failing test, minus the record that it happened.
8. Never present unfinished or faked work as finished. That covers shipping a NotImplementedError, a todo!(), or a "not implemented" throw inside a change you describe as complete, and it covers returning canned, mock, or placeholder data from code that is supposed to do real work. If you could not build it, say so in plain words.
9. Never disable a security control or hide code from review. Do not turn off TLS certificate verification, drop an authorization gate, or disable CSRF protection to make a request succeed. Do not add source or test files to .gitignore, and do not use git update-index --assume-unchanged: code git cannot see is code nobody can review.
10. Never turn off the checks instead of satisfying them. Do not disable a proctor check, lower its severity, add an ignore pattern, write your own approval, delete a ruleset file, add --no-verify, switch off TypeScript strictness, or widen a type to any to silence the checker. If a check is genuinely wrong, that is Rule 2: stop and say so.