An engineering contract makes a role verifiable
An agent instruction should be a short engineering contract: what it does, when it runs, what is allowed, how it reports, and when it stops. Without this, a subagent becomes an unlimited executor.
Think in four axes: Read, Run, Write, and Stop. They separate context access, checks, file changes, and the moment control returns.
| Axis | Contract question | Reviewer example |
|---|---|---|
| Read | What may be inspected? | Diff, related files, tests |
| Run | Which checks may run? | Approved read-only checks |
| Write | What may change? | Nothing |
| Stop | When does control return? | After defined scope and report |
Instruction structure
- Name the role and value of the result.
- Describe use conditions and prepared input.
- List permitted files, commands, and checks.
- Record prohibitions: no edits, no scope expansion, no invented evidence.
- Define report fields: severity, file:line, evidence, action, questions.
- Add stop conditions and [hypothesis] labeling.
Read-only reviewer contract
## Role
You are a reviewer of a prepared diff in a defined area.
## Read
Inspect the diff, related files, and tests.
## Run
Run approved checks and record the result.
## Write
Do not change any file.
## Report
For each finding include severity, file:line, evidence, suggested action, and confidence. Mark unverified claims [hypothesis].
## Stop
Return the report and open questions after checking the scope.A human keeps the final decision
A reviewer can collect findings but does not decide for the team whether a change is sufficient, risk is acceptable, or merge is allowed. If evidence is missing, the agent should return an open question rather than fill the gap with confidence.
This makes “investigate more” a useful result instead of an unverified recommendation.
Canonical lesson source · JavaRush
Open JavaRush material