Merge #559: define restartable task boundaries

docs: define restartable task boundaries

docs/getting-started.md

@@ -175,6 +175,12 @@ The same artifacts are the handoff between sessions. For a small task, run the w
 
 **In the new session**, read the actual files and look at `git status` before doing anything. Don't assume approvals you can't see in the artifacts. Treat a recorded "tests pass" as a claim about a specific baseline: re-run the checks it covers if the code has moved since, if it doesn't say what was run against what, or if you're about to touch the area it covered. If the baseline still holds, take it and get on with the next task — the point is a check proportional to what changed, not a full suite at every handoff.
 
+#### Task-boundary restarts and Ralph loops
+
+`/build auto` can run the whole approved plan in one session. It does not require or perform a fresh process per task. Its per-task status updates, verification results, and commits make each completed task a restartable boundary, so a capable external harness may exit and resume there without depending on chat history.
+
+A shell-level "Ralph loop" is harness behavior, not a separate skill workflow. If you use one, restart only after the current task has reached a recorded boundary; on re-entry, read the durable artifacts and repository state before selecting the next pending task. A process exit is not evidence that a task passed, and a restart must not bypass an approval gate. See the `context-engineering` skill's **Restartable Session Boundaries** section for the handoff checklist.
+
 This doesn't need the `/spec` and `/plan` wrappers — plain requests work in any agent, including a `npx skills add` install that only has the skills:
 
 > Read SPEC.md, then break it into small verifiable tasks with acceptance criteria and dependency order. Save them to tasks/plan.md and tasks/todo.md. No product code yet — show me the plan first.

skills/context-engineering/SKILL.md

@@ -120,6 +120,22 @@ Long conversations accumulate stale context. Manage this:
 
 For the proactive discipline that makes these last resorts unnecessary — what to cut first, what to protect, and when to start — see **Context Budget Management** below.
 
+### Restartable Session Boundaries
+
+A fresh session is safe at a completed task boundary, not at an arbitrary token count. Before leaving the current session, persist:
+
+1. the accepted scope and decisions in the spec or plan;
+2. the current task status and the next pending task;
+3. the files changed and the working-tree state;
+4. the exact verification commands and outcomes;
+5. unresolved questions, risks, and required approvals.
+
+Commit the completed task only when the user or repository workflow authorizes it. Otherwise, leave the working tree intact and record that the changes are uncommitted.
+
+In the fresh session, read the rules, spec, plan, task status, and actual `git status` before acting. Re-run verification when its recorded baseline is missing, the code has moved, or the next task depends on it. Do not infer approval from a previous conversation unless the durable artifact records it.
+
+An external harness may automate exit and restart between these boundaries. That loop must treat the artifacts and repository state as the source of truth, preserve human approval gates, and distinguish a completed task from a crashed process. The skill defines the handoff contract; process supervision and model selection belong to the harness.
+
 ## Context Packing Strategies
 
 ### The Brain Dump