Claude Operator: Prompt to Autonomy · 18 min · 130 XP
A result you can check
Require a fixed answer shape, then verify one claim before you rely on it.
A worker's output is only useful if the caller can evaluate it without re-doing the work. That means asking for a fixed shape up front — a result contract. Four parts carry almost everything you need.
Always answer in this form: CONCLUSION: one sentence EVIDENCE: file:line references you actually read UNCERTAINTY: what you could not confirm, and why NEXT STEP: the single most useful thing to do next If you cannot support a conclusion with evidence, say so in CONCLUSION rather than offering your best guess.
The UNCERTAINTY line is the one people leave out, and it's the one that makes the rest trustworthy. Without a place to put doubt, a worker with an incomplete answer will produce a complete-sounding one — not from dishonesty, but because the format demanded a conclusion. Give it somewhere to say "I couldn't check the mobile client" and you find out which parts to lean on.
The EVIDENCE line does something else useful: it makes verification cheap. When findings come back with file and line references, checking one is a ten-second job. Do it. Pick one load-bearing claim from every delegated result and confirm it yourself before it shapes a decision — the same habit as checking a project map, for the same reason. Evidence you never spot-check is decoration.
Practice. Give your researcher a result contract with conclusion, evidence, uncertainty and next step. Delegate one real architecture question about your project and require file citations. Then take one claim from the result and verify it yourself — confirm it or correct it with evidence, and notice which parts of the report you'd have accepted without checking.
Loading your workspace…