linear-resume

Files (1)

• SKILL.md

SKILL.md (first lines)

# Resume Linear-tracked work

Read the **latest handoff** for whatever the user is resuming and turn it into a resume-from-here
brief: where the build/ticket is, the open loose ends, and the reasoned next step. This skill is the
**read** counterpart to `/linear-handoff` (which writes the handoff). It is strictly **read-only** — it never
branches, creates a worktree, advances a ticket's status, or posts a comment/update.

## Prerequisites

- Linear MCP connected (the `mcp__claude_ai_Linear__*` tools). If absent, stop and tell the user
  this skill needs Linear.

## The container model (project vs. issue)

Linear stores a handoff in one of two places, and that is the only distinction this skill makes:

| Resuming… | Handoff lives as | Read with |
|---|---|---|
| a **project** (a coordinated multi-ticket build) | the newest **status update** | `get_status_updates` `type:"project"` |
| an **issue** — an **epic/parent** *or* a **standalone ticket** | the newest **handoff comment** | `list_comments` |

Epic-vs-standalone makes no difference to the mechanism — both are issues, both store handoffs as
comments. The only question is *project or issue?*

A **handoff comment** is identified by convention: its body begins with a `## Handoff` heading
(see `/linear-handoff`). When scanning an issue's comments, treat only those as handoffs; ignore
ordinary discussion.

## 1. Resolve what to resume

Resolve in order; stop at the first hit:

1. **Supplied** — the user named a project, or gave a ticket/epic id or Linear URL → use it. If it
   is an id/URL, `get_issue` it to learn its title, its `project`, and its `parent`.
2. **Current branch** — `git rev-parse --abbrev-ref HEAD` matches Linear's branch shape
   (`<user>/<team>-<num>-<slug>` or `ticket/<team>-<num>-<slug>`) → extract `<TEAM>-<NUM>`,
   `get_issue` it.

If neither yields anything, ask the user which project/epic/ticket to resume. Never guess.

**Decide project vs. issue:**

- The user named a **project** (or you only have a project) → §2a.
- The user handed an **issue** → §2b. (This is the same-ticket / epic-level case.)

## 2a. Read the latest project status update

`get_status_updates` with `type:"project"`, the project name, `orderBy:"createdAt"`, `limit:1` (pull
a few if you want the recent trail). The newest update is the resume point.

If the project has **no** status updates, say so and fall back to listing the project's in-progress
/ recently-updated issues so the user can choose — there is no recorded handoff yet.

## 2b. Read the latest handoff comment on the issue

`list_comments` for the issue, newest first. Find the first whose body begins with a `## Handoff`
heading — that is the latest handoff.

- **Found** → that comment is the resume point.
- **None, but the issue has a `project`** → there is no per-ticket handoff; the coordinated build's
  state lives at the project level. Tell the user and offer to resume the **project** instead
  (re-run §2a against `issue.project`).
- **None and no project** → there is no recorded handoff. Fall back to the issue's own description +
  most recent comments and say plainly that you are reconstructing from the ticket itself, not from
  a handoff.

## 3. Surface the resume brief

Render what you read as a short, factual brief — do not dump the raw update/comment verbatim, distil
it:

- **Where it stands** — what last merged / what state the ticket is in (with ids/SHAs as written).
- **In flight** — any open PR + its CI/review state, as recorded.
- **Open loose ends** — deferred/skipped items, unresolved decisions, anything left red on purpose.
- **The reasoned next step** — the next task and *why* it was chosen, copied from the handoff. If the
  handoff is stale or self-contradictory, say so rather than papering over it.

If you read a project update naming the next **ticket**, name that ticket explicitly. If you read a
single ticket's handoff, frame the next step as continuing *that* ticket.

**Do not assert state the handoff did not claim.** If the handoff says "CI unverified," carry that
caveat forward — do not upgrade it to "green."

## 4. Hand off to the next action (suggest, never execute)

End by pointing at the next command — but **do not run it**; the user
drives:

- **Cross-ticket** (you resumed a project/epic and the next step is a *different* ticket) → give
  the ticket's id and suggest moving it to In Progress, so dispatch launches a
  `/dispatch:build <TEAM>-<NUM>` worker for it.
- **Same-ticket** (you resumed one ticket to continue it) → if a worktree/branch for it already
  exists, give the user its path or branch to reopen (e.g. via `claude-workspace <branch>`); if not,
  suggest creating it the same way. Either way, this skill does not touch git.

## Boundaries

- **READ-ONLY.** Never `git worktree add` / branch / checkout, never `save_issue` (no status or
  assignee change), never `save_comment` / `save_status_update`. Resume informs the next action; it
  is not the next action.
- Do not move tickets or invoke `/linear-handoff` for the user — suggest the command and let them
  decide.
- Do not re-derive sequencing the handoff already reasoned out — carry its "next" forward; only flag
  it if it's stale or wrong.

## Early exits

| Condition | Action |
|---|---|
| No Linear MCP available | Stop — this skill requires Linear |
| Nothing resolvable to resume | Ask the user which project/epic/ticket |
| Project has no status updates | Say so; list in-progress issues to choose from |
| Issue has no handoff comment but has a project | Offer to resume the project instead |
| Issue has no handoff comment and no project | Reconstruct from the ticket; say you're doing so |

From thrawn01/claude-dotfiles, MIT.

More from thrawn01/claude-dotfiles