Resume

---
name: resume
description: Resume a project in five minutes - read BRIEF/PLAN/JOURNAL plus git state, deliver a short where-we-are brief, divergence flags (uncommitted work, unjournaled commits, acceptance drift), and the next three unblocked tasks. Use at session start or when the user asks where were we, what's next, to catch up on a project, or to get oriented in an unfamiliar repo.
argument-hint: "[notes]"
allowed-tools: Read, Grep, Glob, Bash(git log:*), Bash(git status:*), Bash(git rev-parse:*), Bash(ls:*), Bash(grep:*), Bash(wc:*), Bash(gh issue list:*), Bash(gh pr list:*), Bash(git for-each-ref:*)
---

# /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).

<!-- acstack:runtime -->
Run before the skill's steps — per invocation, not per session (4.36); failures degrade to markdown:
```bash
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
```
<!-- /acstack:runtime -->

<!-- acstack:principles -->
## 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.
<!-- /acstack:principles -->

**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.