long-task git:20261031.5376ed6A

Immutable. This exact content never changes and is served at /api/v1/blob/2e93fac50b06f0c2.

---
name: long-task
description: Run a long or multi-session task to completion with a written brief, acceptance checks, a progress file that survives context resets, an evidence review and a resume prompt. Use when the user asks to finish, carry through or resume a long task, or invokes /specialist-council:long-task.
argument-hint: "[task, or the slug of a task to resume]"
---

# Long task: finish it, survive resets

Request: `$ARGUMENTS`. Work in the user's project. Keep every file below in `.claude/long-task/<slug>/` of that
project (create it; add it to `.gitignore` only if the user wants it untracked), so a new session can pick it up.

## 1. Brief (once, before any work)

Write `brief.md` with these fields, filled from the request and the project. Ask only for what you cannot infer:

- **Task:** one paragraph.
- **Deliverables:** exact output paths.
- **Acceptance:** checkable conditions, each one something a command, a file or a reviewer can confirm
  (tests pass, file exists with sections X and Y, every claim in the claim table verified or marked unresolved).
- **Constraints:** what must not change, what needs the user's go-ahead (pushes, sends, deletes, spending).
- **Budget:** turn or time limit, if the user gave one.

### Reconstruction preset

Use it when the request rebuilds existing software, a file format or a protocol from observed behaviour (say
"reconstruction", or the request names software to rebuild or clone). It adds to the brief:

- **Authorisation** (first, before any analysis): what may be rebuilt and on what grounds: the user's own code,
  an open licence, interoperability under the applicable law, or written permission. Record the grounds. If they
  are missing or the target's licence forbids it, stop and ask; do not work around a licence or a technical
  protection.
- **Behaviour checklist** in `checks.md`: one row per observable behaviour of the original (input, expected output,
  how it was observed), each marked must-have or nice-to-have. Build clean-room from this list, not by copying code.
- **Verification:** when the `rea` MCP server is present, check each row with its `verify_reconstruction` and
  `evaluate_reconstruction_coverage` tools; otherwise with tests that replay the recorded inputs.
- **Done rule:** every must-have row passes in two runs in a row. Stop and report when two passes in a row make no
  progress (a stall); do not loop on the same failing rows.

## 2. Progress file (update after every step)

`progress.md` holds: task (one line), outputs so far with paths, checks done with their results, decisions and why,
open issues, and the **next action**. Write it before a long command and after each result, so a context reset or
usage limit loses at most one step. Never record secrets in it.

## 3. Goal

Give the user this line to run, filled from the brief, so Claude Code keeps working until the acceptance holds:

```
/goal All acceptance checks in .claude/long-task/<slug>/brief.md pass and progress.md lists their evidence. Stop after N turns.
```

`/goal` is a user command; you cannot run it yourself. The goal check is model-judged, so keep hard limits (money,
runtime) in the brief's constraints and stop on them yourself. `/goal clear` removes it.

## 4. Work

- Do one step at a time against the next action in `progress.md`. Batch independent reads into one turn.
- Commit or otherwise save durable work as you go; `/rewind` does not undo shell changes or subagent edits.
- **Before retrying anything that timed out or failed partway** (a push, an upload, a cluster sync, an API write, a
  commit by another agent), check whether the first attempt already took effect and record what you found.
- Use the Specialist Council for parts that benefit from independent specialists.

## 5. Evidence review (before calling it done)

Dispatch `specialist-council:council-peer-reviewer` (papers, reports, analyses) or
`specialist-council:council-validation-auditor` (models, data, numbers) with the deliverables and their sources, and
ask for the **claim table** in its evidence-review format. Fix every `incorrect` row, recheck the sentences around
each fix, and leave `unresolved` rows marked with the missing evidence. Save the table as `checks.md` next to the
brief.

## 6. Finish or hand over

- **Done:** every acceptance check passes with evidence in `progress.md`. Report the deliverable paths, the check
  results and any unresolved claims.
- **Not done:** write `resume.md`, a ready-to-paste prompt for a fresh session:
  `Resume the long task in .claude/long-task/<slug>/: read brief.md and progress.md, then continue from the next action.`
  Tell the user where it is.

## Resume

When `$ARGUMENTS` names an existing slug, or a `resume.md` exists: read `brief.md`, `progress.md` and `checks.md`,
verify the last recorded step really happened (files, commits, remote state), then continue from the next action.