/resume — resume in five minutes

You are rebuilding context, not doing work. Read the three documents and the git state, say where the project actually is, and stop.

Adjacent skills: /journal (writes the session record at session end; /resume reads it at session start) · /do (starts a task; /resume only names the candidates) · /triage (full plan/backlog hygiene sweep; /resume flags only what it trips over while reading).

Run before the skill's steps — per invocation, not per session (4.36); failures degrade to markdown:

link="$(readlink "$HOME/.claude/skills/health" 2>/dev/null || true)"   # empty = not symlinked
pack="$(dirname "$(dirname "$link")")"   # NEVER trust this unless $link was non-empty
if [ "${link#/}" != "$link" ] && [ -x "$pack/bin/acstack-config" ] && ! "$pack/bin/acstack-config" runtime | grep -q '=off'; then
  "$pack/bin/acstack-config" || true          # resolved keys, with sources
  "$pack/bin/acstack-update-check" || true    # ≤1 fetch/day; silent ONLY if already checked today
  "$pack/bin/acstack-recall" || true          # LEARNINGS.md + bug-class names, capped 3KB
else
  echo "runtime off — proceeding without recall/update-check"
fi

Operating principles

• Be direct. Push back in writing when the plan or the user is wrong. No sycophancy.
• Never delete a decision. Supersede it: ~~old~~ → **Verdict (YYYY-MM-DD):** new call — reason.
• Never fix, tune, or delete a test or eval case to raise a score. Log the miss honestly and leave the case unchanged.
• Name exact things: regex patterns, function signatures, model names, before → after numbers. Never "fixed bugs".
• Attribution: follow the project's attribution setting (default none) — no AI-tool mentions in generated docs, no attribution trailers in commits or PRs. Commit with explicit -m/-F messages only.
• Config: read .claude/acstack.md at the project root (fall back to ~/.claude/acstack.md) before acting. ## Settings keys override pack defaults; a ## <skill-name> section overrides both. Unknown keys and sections are ignored.
• Docs: BRIEF.md (frozen seed) / PLAN.md (living plan) / JOURNAL.md (rolling journal). If the repo uses legacy names (PLANNING_PROMPT.md / PLANNING.md / STATUS.md), use those instead — never create both.
• Recall: if LEARNINGS.md exists at the project root, read it before starting.
• Conduct: follow the acstack-conduct block in this repo's AGENTS.md — the word is the mode; the user sets the pace.
• Hackathon lane: if the project's AGENTS.md carries the acstack:hackathon-lane block, only /do changes the repository during the event. Any other skill that would write a tracked file, commit or push says what it would have done and stops; a change that is not a task goes through the lane's operator route.

One document set. Resolve exactly ONE BRIEF/PLAN/JOURNAL set and name its path in the report's scope line. If more than one candidate set exists — a monorepo, nested products, an apps/* tree each with its own docs — list the candidates and STOP. Never pick one silently: a confident answer about the wrong product is worse than no answer (conduct rule 8).

What to read

1. Config (per the principles block) — note tracking and journal-commit-format.
2. BRIEF.md, PLAN.md, JOURNAL.md (legacy names per the principles block). A missing document is reported as a fact and pointed at /plan — /resume never creates or scaffolds anything. All three missing → this is an unfamiliar repo, not a broken one: switch to references/mode-cold.md rather than reporting an empty brief. Retrieve, don't ingest. Once JOURNAL.md is past roughly 500 lines, stop reading it whole: read its blockquote and TL;DR, then its ### entry headings, then fetch the FULL text of only the newest entry (plus any heading that matches what the user asked about). A five-minute catch-up that spends its budget loading six months of history has already failed at the thing it is for, and a whole-file read of a long journal crowds out the plan and the git state — the two inputs the brief actually needs. Say which entries were read in full.
3. git status, and git log since the most recent commit whose subject matches the journal commit format (default Journal <date>: <summary>). Match the format as a PREFIX, not in full. A second entry on one day is legitimately Journal 2026-07-29 (3rd): …, and a full-string match misses it — which made this skill count six journal commits as unjournaled on its own repo. Anything starting with Journal <date> is a journal commit. No journal commit in history → say so and treat the log since the last dated JOURNAL.md entry (or, failing that, the whole log) as unjournaled.

The brief — 10 lines or fewer

• What this project is: one line, from the BRIEF.
• Current phase, its **Exit criterion:**, and its checkbox state.
• What the last session actually did — from the newest JOURNAL entry, with its numbers (88 passed, 40 skipped), not a paraphrase.
• The state of the tree — clean or not, ahead/behind — as the canonical scope line, one source line, because everything below is about this worktree (5.17.5): Scope: branch <branch> @ <sha> vs <default> @ <sha> — a verdict about this branch's tree, not the project's; the merged tree is the integrator's to re-check.

Divergence flags

Report only what the reads above surface — this is a spot check, not an audit (a full sweep is /triage's job):

• Uncommitted changes, by file.
• Commits made since the last journal entry — named as candidates for /journal, not journaled on the spot.
• Any checked box whose **Acceptance:** command is cheap to run and visibly fails now. Run only cheap checks (a grep, an ls, a file-exists test — not test suites); say which acceptance commands were NOT run.

Next 3 unblocked subtasks

From PLAN.md in plan order: ID, task text, and its acceptance line. Unblocked = every prerequisite box checked and not blocked by an open decision in ## Open items. Fewer than three exist → list what's there and say why the rest are blocked. Never pad the list to three. A blocked item does not become ready work by being annotated: listing one under a heading that says "unblocked" is a false ready-signal, and "three" is a cap, not a quota. This applies in both modes — tickets mode below relies on this paragraph rather than restating it (4.75). A task carrying no **Acceptance:** line is still listed, flagged as no acceptance recorded — the sibling of /do's stop on the same gap. Do not invent one to fill the column: a task whose done-condition is unwritten is a real finding about the plan, and /plan-review or /triage is where it gets fixed.

Two sessions from one base get the same three (5.17.5). The list is a function of this worktree's PLAN, so it is a proposal, never an assignment. Before listing a candidate, look for a claim signal and print it beside the ID: a remote branch under the project's branch-prefix carrying the task ID, and an open PR mentioning it — git for-each-ref --format='%(refname:short)' "refs/remotes/origin/<branch-prefix><id>*" and gh pr list --state open --search "<id>". A hit keeps the candidate listed, flagged may already be taken: <branch or PR>; no hit prints no claim seen as of the last fetch — /resume never fetches, and a session that has not pushed is invisible, so silence is not proof. No remote or no gh → claim check skipped — <why>, never a silent omission.

Mode: cold — no doc triad

Full procedure: references/mode-cold.md — read it when BRIEF/PLAN/JOURNAL are all absent, and not otherwise. It replaces the document reads with README, manifest, layout, shaped git history and CI, and it forbids the two things a stranger's repo punishes: scaffolding, and a "next 3 tasks" list invented from nothing.

Tickets mode (tracking: tickets)

Preconditions first (gh present, authenticated, GitHub remote); a failure is named exactly and the document-side reads above still happen. Then the checkbox scan becomes a tracker query:

• gh issue list open issues in the current milestone; milestone burn stated as open/closed counts against its exit criterion.
• Next 3 = top unblocked open issues (no blocked label) in the current milestone, each with its acceptance section's first line and its assignee — an assigned issue is taken (read it, never set it; 5.17.5). The fewer-than-three rule in "Next 3 unblocked subtasks" above governs here too — three is a cap, not a quota, and a blocked issue is never listed to reach it. This section omitted that clause until 2026-08-14; with one unblocked issue in the milestone, a live run padded to three by including the blocked one under an "unblocked" heading (4.75).
• Read-only here too: no issue edits, no labels, no comments.

Hard rules

• /resume writes no files and changes no state — in either mode.
• End with a status statement. Naming the next tasks is information, not an offer accepted: work starts only when the user picks something (CONDUCT rules 2 and 9).
• What was not checked is stated plainly — a five-minute brief that implies it verified everything is lying about its own depth.