The unit of delegation
A prompt such as improve this repository delegates interpretation as well as implementation. A bounded contract separates the outcome from the agent's discretion: name the problem, the owned paths, the prohibited paths, the expected behavior, and the evidence that would change a reviewer's mind. The contract also names the environment in which work may happen. A local draft, an isolated branch, and a production service are different places with different consequences. This is an editorial operating pattern, not a claim that a particular product enforces every boundary automatically.
Write acceptance before generation
Describe two or three observable examples, including a negative case. For a parser change, give representative inputs, expected outputs, and what must happen on malformed input. For a UI change, identify a user journey and the narrow screen or accessibility states that matter. Then specify the allowed verification: focused tests, a build, manual inspection, or a diff review. A test command listed in a brief is an instruction to run it, not evidence that it has passed. Keep reported evidence tied to actual tool output.
Set authority and termination
The contract should enumerate available tools and side effects. Reading source and preparing a patch may fit a routine assignment; sending a message, altering a database, or publishing needs separate authority. Add a stop rule for missing credentials, ambiguous requirements, a repeated failure, or an exceeded cost or time budget. MCP describes tools as capabilities a server exposes, and OWASP's agent guidance treats tool access and least privilege as security concerns. Neither source turns a broad natural-language wish into a safe permission policy; the project owner still has to define one.
Make review cheap
Ask for a compact handoff: changed paths, why they changed, checks actually run, checks omitted, and remaining uncertainty. A reviewer should be able to compare the diff with the original acceptance examples without reconstructing a long conversation. If the assignment reveals a larger architectural problem, record it as a follow-up rather than silently expanding the edit. The best contract is short enough to be read before work begins and precise enough to reject a plausible but wrong completion. Revise it when new evidence changes the task, and preserve that revision in the review trail.
What to carry into the work
- State one measurable outcome and two acceptance examples.
- Name writable and protected paths.
- List permitted tools and external side effects.
- Define a stop rule and a review handoff.
Sources & dates
- Tools — Model Context Protocol specification ↗Model Context Protocol · Undated source · Checked 16 Sept 2026
- LLM Prompt Injection Prevention Cheat Sheet ↗OWASP · Undated source · Checked 16 Sept 2026
Unknown source dates stay undated. Preparation is not publication; no historical byline or interview is implied.