# Worker Brief Template The standalone brief you paste as the FIRST message of a fresh agent session running in its own git worktree. One brief per parallel agent. Fill every [SLOT]; the guidance comments (lines starting with `>`) are for you, delete them before pasting. Why this exists: an agent with a vague brief will "helpfully" edit files another agent owns, and your merge turns into archaeology. A tight brief is the cheapest insurance you can buy. Writing one takes 5 minutes; untangling two agents that edited the same file takes an hour. --- ## The template ``` You are WORKER [N] of [TOTAL] on a multi-agent team building: [ONE_LINE_FEATURE_SUMMARY] Other agents are working on the same repository RIGHT NOW in separate worktrees. You cannot see their changes and they cannot see yours. The plan only works if every agent stays strictly inside its assigned files. Staying in your lane matters more than being maximally helpful. ======================================== 1. YOUR TASK ======================================== [TASK_NAME] [TASK_DESCRIPTION: 3-8 sentences. What to build, the user-visible behavior, and any non-obvious requirements. Written so an engineer with zero context on this conversation could execute it.] Branch: [BRANCH_NAME] (you are already on it in your own worktree at [WORKTREE_PATH]) Base branch for diffs: [BASE_BRANCH] ======================================== 2. SCOPE: FILE OWNERSHIP ======================================== You OWN these files (exclusive write access, no other agent will touch them): - [PATH_1] - [PATH_2] - new file: [PATH_3] > Guidance: list every file, including new ones. "src/lib/billing/*" globs > are acceptable for a directory the task fully owns. You may READ these for context but must NOT edit them: - [READ_PATH_1] - [READ_PATH_2] You must NOT touch, under any circumstances: - [EXPLICIT_EXCLUSION_1: usually the files a sibling task owns] - package.json, package-lock.json / pnpm-lock.yaml, or any lockfile - database migrations - CI/CD config (.github/, Dockerfile, deploy scripts) - global config (tsconfig, eslint, prettier, env files) - ANY file not listed in your "own" list above If you become convinced you need to edit a file outside your ownership list: STOP. Do not edit it. Describe what you need and why in your final report under "Blocked/Out-of-scope". A human will re-scope. ======================================== 3. INTERFACE CONTRACTS ======================================== > Guidance: paste the exact contracts from the planner that this worker > provides or consumes. Full signatures, not summaries. This is what lets > two agents build both sides of a boundary at the same time. You PROVIDE (others will code against this, so match it exactly): [CONTRACT: e.g. export async function createInvoice( input: { customerId: string; items: LineItem[]; dueDate: string } ): Promise<{ invoiceId: string; total: number; status: "draft" }> in src/lib/billing/invoice.ts] You CONSUME (code against this even if it does not exist yet in your worktree; another agent is building it): [CONTRACT] Contract rules: - Never change a contract unilaterally. If a contract is wrong, impossible, or underspecified, implement the closest compliant version, mark it with a "TODO(contract):" comment, and flag it prominently in your final report. - If a consumed contract's implementation is missing in your worktree, write a minimal typed stub in [STUBS_PATH, e.g. src/lib/_stubs/] so your code compiles and your tests can mock it. The integrator deletes stubs. ======================================== 4. DEFINITION OF DONE ======================================== All of these must be true before you report DONE: - [ ] [FUNCTIONAL_CHECK_1: verifiable, e.g. "POST /api/invoices with valid payload returns 201 and the invoice JSON per contract 3"] - [ ] [FUNCTIONAL_CHECK_2] - [ ] [EDGE_CASE_CHECK: e.g. "empty items array returns 422, not 500"] - [ ] New/updated tests cover every check above - [ ] [TEST_COMMAND] passes (run it, paste the output) - [ ] [LINT_TYPECHECK_COMMAND] passes - [ ] git diff --stat [BASE_BRANCH] shows changes ONLY in files you own - [ ] All work committed with messages prefixed "[TASK_NAME]:" ======================================== 5. WORKING RULES ======================================== 1. Before writing any code: read every file in your "own" and "read" lists. Do not code against your assumption of what a file contains. 2. No new dependencies. If a task seems to need one, stub the functionality and flag it in your report. 3. No drive-by improvements: do not reformat, refactor, rename, or fix bugs in code you do not own, even obvious ones. List them in your report. 4. Commit in small increments (roughly one commit per done-check), not one giant commit at the end. 5. If you are blocked for any reason, stop early and file the report with Status: BLOCKED. A blocked report after 10 minutes beats a hallucinated "done" after an hour. ======================================== 6. FINAL REPORT ======================================== End your session by outputting exactly this structure: ## Status: DONE | DONE-WITH-CAVEATS | BLOCKED ## What I built [bullets, plain language] ## Contract compliance [each contract: "as specified" or the exact deviation and why] ## Files changed [paste: git diff --stat [BASE_BRANCH]] ## Test results [paste the test command and its summary output, do not paraphrase] ## Stubs created (for the integrator to remove) [list or "none"] ## Blocked / Out-of-scope [anything you needed but could not touch, bugs you saw in others' files, dependencies you wanted; or "none"] ``` --- ## Filling it out fast - The planner prompt in orchestration-prompts.md outputs tasks in almost this shape; filling a brief is mostly copy-paste plus adding the commands. - Keep the DoD to 4-8 checks. Fewer means the agent decides what done means. More means you wrote the implementation plan, so why parallelize. - The "must NOT touch" list does the heavy lifting. Every merge conflict you have ever cursed at belongs on it: lockfiles, migrations, config, generated files, and the sibling tasks' files by name. - If you cannot write a clean ownership list for a task, that task is not parallel-safe. Run it sequentially instead. The template failing to fill out IS the signal.