| name | wrap-up |
| description | Close-out checklist for a non-trivial task — run BEFORE declaring done / writing `result:`. Verifies the project's continuity docs, READMEs, and cross-session trackers actually match the work just landed, and persists durable facts to memory. Use when finishing a coding session, wrapping up, closing out a task/project, or when asked "did you update the docs". Skip for trivial one-line edits. |
wrap-up — sync docs to reality before closing
Landing the code is not the whole deliverable. A task is only closed when the docs that
describe the project still tell the truth. This checklist catches the recurring miss:
work shipped, result: written, but roadmap/handoff/tracker still describe the old state.
Run this when finishing non-trivial work, right before the result: line. Skip entirely
for a typo / one-line fix, or when nothing documented actually went stale.
1. Inventory what changed this session
List concretely: code/config touched, behavior changed, new commands/tools/files, new tests,
test-count delta, deploy/version state. This is the diff between reality-now and docs-as-written.
2. Find the project's designated docs
Read the project's CLAUDE.md for which files are continuity docs — do not guess. Typical set:
- README(s) — top-level and any subsystem you changed (e.g.
eval/README.md, a package README).
- Roadmap / plan — did a tracked item close, or a section (e.g. a "measurer"/feature list) go incomplete?
- HANDOFF / status / "Состояние кода" — tip commit, test count, feature list, "next step".
- Cross-session tracker (
tasks/todo.md) — mark done items; add a dedicated entry for new work.
- CHANGELOG, reference-map, ADRs — if the change is architectural or user-visible.
3. For each, ask: did my work make it stale?
Only touch what actually drifted. A stale status line, a missing feature entry, an out-of-date
test count or tip commit, a "next step" that's now done — those are drift. Prose that still holds — leave it.
4. Guard against clobbering a parallel session (critical)
Before editing a shared/tracked doc, check it isn't being edited concurrently: git status +
file mtime (fresh = minutes ago → another session is likely mid-edit). Two agents editing the
same doc in parallel is an anti-pattern. If it's fresh-dirty, do not clobber — make only a
non-colliding anchored insert, or hold that one doc and flag it in your summary. Day-stale dirty
(uncommitted from a prior session) is safe to extend additively.
5. Apply updates in the right place, the right way
- Repo code/docs (README, subsystem docs): follow the repo's git rules — branch/PR, or a
sanctioned direct commit if the project allows it. Ship the README in the same commit as the code.
- Forge / orchestration continuity docs: edit in place; commit locally if the project keeps
forge commits local (don't fight a blocked push).
- Under the bgIsolation guard, Edit/Write on a tracked checkout is blocked → use the Bash
read-modify-write fallback (and keep literal
! out of the source — the harness escapes it).
6. Persist durable facts to memory
If the work established durable external/prod facts (paths, IDs, live config, an architecture map,
a verified recipe), write a reference/project memory so the next session doesn't re-derive them.
7. Then close
Only now write the result: line. In the summary, name any doc you deliberately held (e.g. a
concurrently-edited tracker) and why — an honest half-close beats a silent one.
