git:20260924.e9e9cf4 to git:20260925.6dde440

- A long chat holds verdicts and findings that exist NOWHERE ELSE. Compaction throws them away. This skill WRITES the conversation onto the board first: it files what is new, updates what exists, and moves every issue the owner's words moved. Afterwards "go", "continue" or "resume" starts from the issues, not the scrollback.

-

- **Invoking it is the owner's word to file AND to apply every status change they spoke**, for this run only. It drains the CONVERSATION, never the capture file. That stays `workkit:triage`'s (spec § Capture).

- **The trigger is loose on purpose.** Any line that mentions compacting, in any form, fires it: compact, compaction, `/compact`, context full or low or running out, clear the chat, new chat, fresh session, start over. A question form ("can I compact?", "should I compact?") is answered by running this skill first, then yes. The `docs:checkpoint` hook (`hooks/docs/checkpoint/run.sh`) matches those phrases deterministically on every prompt and injects the instruction to run this skill, so the description above is the judgment fallback for a phrasing the pattern misses.

- ## 1. Enumerate FIRST, before touching anything

- Read the whole chat back, not just the last exchange. Write out ONE line per owner comment, concern, ruling, verdict, decision, and question, plus every finding the agent made that has no home yet. Quote the owner's words on each line. A single exchange usually fans out to several lines; never one blob.

- The list is built from the chat, never from memory of what was filed. "Already on #652" is not a line; if it is on #652, the line names #652 and the run confirms it with `gh issue view`.

- The list is a WORKING document, never chat output: keep it in reasoning or a scratch file, act on it, and print only the trail in §5. The owner sees what changed, not the checklist.

- - **An issue exists** → update it: a dated comment quoting the owner's words, a spec line, a label.

- - **No issue exists** → file one, following the `workkit:triage` routing table (the SSOT for destination, the filing litmus test, and the issue anatomy: spec § Issue anatomy).

- - **An unanswered owner question** → `status:blocked` with the question in the owner's own words. A question the agent answered in chat is not blocked; the answer goes on the issue.

- Status changes ARE checkpoint work. Every owner word that moves an issue's stage is applied, with the words quoted on the issue, dated:

- One `status:` label per issue: remove the old one in the same command (`gh issue edit <N> --remove-label status:qa --add-label status:complete`). Never `agent:ok`, and never a flip the owner did not speak. A verdict is applied, never inferred.

-

- One case where the spoken pass does NOT move the label: a `status:qa` item whose comments carry no line starting `Proof:`. Quote the owner's words on the issue as always, then LEAVE it at `status:qa` and say so in the Filed trail. The proof is a hard gate (spec § The proof), so `safety/proof-guard` bounces the flip anyway, and the fix is a re-park: the agent that built the item runs its layers, comments the `Proof:` line, and the flip follows.

- One bullet per item now in flight or queued, each pointing at its issue; DELETE the bullets the issues now hold. The file is a queue, not a journal. The 40-line bar and the 350-character bullet cap hold (spec § Capture, `docs:session-guard`).

- The trail is a report of actions, not an audit log. ONE bullet per issue this run touched, its bold lead the number, the issue link and five words (§ Restating an issue), listing everything done to it in plain words (comments, filings, flips). Never one line per action, never a raw URL. It is the reply's `**🗂️ Filed**` section, the one shape `workkit:triage` prints too, and every bullet reads in the cold-reader line (`docs/project-state.md` § Restating an issue). Items verified as already on the board get ONE closing count line, never a line each.

- The trail is the whole reply: nothing printed before it but the timestamp. `**✅ Safe to compact or continue in a new session.**` prints ONLY when every enumerated item is on the board; otherwise the last line names what is still unfiled.

- - Every rule under `workkit:triage` § Rules binds here: one home per entry, one `status:` label, never invent priority, never `agent:ok` on the owner's behalf, `(check placement)` for the ambiguous ones.

- - No capture-file drain here. An entry belonging to another repo or to the home repo routes the same way triage routes it.