The Task Contract

A Task Contract is the approved operating boundary for one unit of work. It is not merely a summary of the request and it is not a long prompt intended to control every line of code.

Its purpose is to make the consequential parts of the task explicit before implementation begins:

• what outcome is authorized;
• which project evidence and assumptions support the work;
• what may be modified;
• what must remain unchanged;
• which behaviours demonstrate completion;
• which checks are required;
• when the agent must stop and ask for a decision.

The Task Contract authorizes work. Generating it does not authorize implementation until the developer reviews and approves it.

Why a request is not enough

A natural-language request can be clear about the desired result while leaving critical implementation questions open. An AI model may then fill the gaps with assumptions, broaden the scope or choose an architecture that was never requested.

The Task Contract converts the request and the relevant project state into a reviewable decision surface. It exposes assumptions before they become code and gives the developer a concrete object to correct.

What a useful contract contains

The exact representation may vary, but a complete contract should make these elements visible.

Task source

Identify where the work originates: a developer request, backlog item, GitHub Issue, analysis, bug report or another declared source. Preserve the source identifier when one exists.

Objective

Describe the observable result, not the preferred implementation alone. A good objective states what should become true after the task.

Pertinent analysis

Record only the project facts needed to authorize the work: current behaviour, relevant architecture, existing functions, constraints, dependencies and uncertainties.

Allowed edit surface

Identify the files, modules or behavioural areas expected to change. The surface should be large enough to implement coherently but not so broad that unrelated restructuring can enter unnoticed.

Preserved areas and exclusions

State what must not change. Typical exclusions include unrelated features, dependencies, shared interfaces, existing validation rules, repository-wide formatting, infrastructure, commit history and documentation outside the task.

Acceptance criteria

Define observable conditions that show the requested behaviour exists. Acceptance criteria should be specific enough to review without prescribing unnecessary implementation details.

Verification

Declare the smallest relevant automatic commands and manual checks. The contract should distinguish checks the agent can execute from checks the developer must perform.

Stop conditions

Explain when the agent must stop instead of improvising. Examples include contradictory evidence, a required dependency that does not exist, a scope expansion, an unsafe destructive operation or an architectural decision not covered by the task.

How to review a Task Contract

Before approval, ask:

• Does the objective match the actual request?
• Are assumptions supported by the repository or explicitly marked as uncertain?
• Is the edit surface coherent and proportionate?
• Are working behaviours and developer changes protected?
• Are acceptance criteria observable?
• Are checks realistic for the current project?
• Are prohibited operations visible?
• Would a substantial new decision require an amendment or a separate task?

Reject or correct the contract when it hides uncertainty, includes unrelated refactoring, names files without inspecting the repository or treats a proposed capability as already implemented.

Approval and implementation

Approval should be explicit. After approval, the agent may implement only the authorized work while respecting the current repository state.

Approval does not remove developer freedom. The developer can still edit any code, change direction or perform work directly. Those changes become current project state and the agent must integrate with them.

When the contract changes

A clarification that does not alter the authorized outcome can be recorded without replacing the contract. A local technical adaptation may also be acceptable when it remains inside the objective, edit surface and acceptance criteria.

A material change requires an amendment when it affects scope, behaviour, files, checks or exclusions. A different primary objective should normally become a separate task.

The updated contract should show:

• what changed;
• what remains valid;
• work already completed;
• checks that must be repeated;
• the new approval state.

Contract size

The contract should be as small as possible while remaining sufficient for autonomous review and implementation. Small does not mean vague.

A one-line change may need only a compact contract. A cross-layer feature may require coordinated files, behavioural constraints and multiple checks. The correct size follows risk and decision surface, not a fixed template length.

Relationship to preservation-first

The Task Contract defines the authorized change. Preservation-first defines how that change is integrated with the existing software.

Together they prevent two opposite failures:

• changing too much because the task boundary is vague;
• changing too little or inconsistently because the local architecture was ignored.

The contract may therefore name existing methods, utilities, guards, public interfaces or local patterns that the implementation must reuse or preserve.