| 1 | # Task Contracts and Pause Policy |
| 2 | |
| 3 | <a href="./GUIDE.md">Guide</a> |
| 4 | · |
| 5 | <a href="./TASK_CONTRACT.zh-CN.md">Simplified Chinese</a> |
| 6 | |
| 7 | Reasonix works best when nontrivial work is described as a **task contract**: |
| 8 | what the work is for, what action is requested, how the result should be |
| 9 | delivered, what boundaries must be preserved, and when the agent should pause. |
| 10 | Some prompt templates call the last section "Checkpoint"; Reasonix documents it |
| 11 | as "Pause policy" to avoid confusion with Checkpoints/Rewind snapshots. |
| 12 | |
| 13 | This is intentionally not a larger role prompt. Strong coding agents usually do |
| 14 | not need step-by-step thinking instructions. They need clear boundaries and |
| 15 | acceptance criteria. |
| 16 | |
| 17 | ## Template |
| 18 | |
| 19 | ```text |
| 20 | Context: |
| 21 | I am working on [larger task]. |
| 22 | The target audience/user is [who]. |
| 23 | This result should help them [achieve what outcome]. |
| 24 | |
| 25 | Request: |
| 26 | Please complete [one clear action]. |
| 27 | |
| 28 | Output format: |
| 29 | Return the result as [specific structure]. |
| 30 | It must include [required sections]. |
| 31 | Keep it within [length or scope]. |
| 32 | |
| 33 | Constraints: |
| 34 | Do not [bad assumption]. |
| 35 | Do not [out-of-scope content]. |
| 36 | Do not [low-quality output shape]. |
| 37 | If information is missing, mark uncertainty explicitly. |
| 38 | |
| 39 | Pause policy: |
| 40 | Unless the next step involves an irreversible or externally visible operation, |
| 41 | a scope change, or information only I can provide, keep working and report back |
| 42 | after the task is complete. |
| 43 | ``` |
| 44 | |
| 45 | ## How Reasonix Uses It |
| 46 | |
| 47 | - **Normal chat** can use the template directly for one-off work. |
| 48 | - **Goal mode** treats the goal as a task contract and keeps working until the |
| 49 | request, output format, constraints, and verification expectations are |
| 50 | satisfied. |
| 51 | - **Plan mode** is the right choice when you want the model to draft and confirm |
| 52 | a plan before implementation. It is a workflow instruction, not a read-only |
| 53 | permission boundary. |
| 54 | - **Tool approval** remains separate: file writes, shell commands, publishing, |
| 55 | credentials, and external effects still follow the configured approval policy. |
| 56 | - **Checkpoints/Rewind** are file and conversation snapshots. The task contract's |
| 57 | pause policy is about when the agent should ask the user before continuing. |
| 58 | |
| 59 | The Goal-mode task contract rides the provider-visible user turn. It does not |
| 60 | rewrite the cache-stable system prompt, memory prefix, or tool schemas. |
| 61 | |
| 62 | ## Example |
| 63 | |
| 64 | ```text |
| 65 | /goal Context: |
| 66 | I am improving the desktop composer. |
| 67 | The target user is someone doing repeated code review sessions. |
| 68 | This should help them avoid accidental interruptions. |
| 69 | |
| 70 | Request: |
| 71 | Make the slash-command menu keep keyboard focus while suggestions are open. |
| 72 | |
| 73 | Output format: |
| 74 | After implementation, summarize changed files and verification results. |
| 75 | |
| 76 | Constraints: |
| 77 | Do not change the Wails JSON contract. |
| 78 | Do not refactor unrelated composer state. |
| 79 | If browser verification cannot run, say why. |
| 80 | |
| 81 | Pause policy: |
| 82 | Unless the next step requires a product decision, a public push, or credentials, |
| 83 | continue through implementation and verification before reporting back. |
| 84 | ``` |
| 85 |