---
name: goon
description: Resume a project session by reading the latest handoff, MAP plan, and checking project state
disable-model-invocation: true
argument-hint: "[focus area]"
---

# Resume Session

You are resuming work on a project. Follow these steps exactly.

## Adaptability

The steps below are guidance. When something doesn't match the project — no
MAP plan, no GitHub, unusual structure — adapt and tell the user what you're
doing differently. Don't skip things silently; propose the adaptation:

> "No MAP phases found — I'll orient from the handoff's 'what to build next'
> section instead."

## Usage

If `$ARGUMENTS` is "help" or "?", show this and stop:

```
/goon [focus area]

Resume a project session. Reads the latest handoff, checks the MAP plan
and GitHub issues, runs a quick build check, and orients you.

Examples:
  /goon                              Resume with default priorities
  /goon hidden classes               Focus on hidden classes work
  /goon "fix the GC bug first"       Override priorities for this session

Part of the /map → /goon → /handoff workflow:
  /map       Plan the work and bootstrap the project
  /goon      Resume a session (you are here)
  /handoff   Wrap up a session and generate the next handoff

Requires .claude/map/*/goon.yaml — run /map first to bootstrap.
```

## 1. Load project config

Glob for `.claude/map/*/goon.yaml` to find all map configurations.

- **No results**: Tell the user: "No map found in `.claude/map/`. Run
  `/map [feature]` to plan and bootstrap." Then stop.
- **One result**: Load it. Set `{map_dir}` to the directory containing it.
- **Multiple results**: If `$ARGUMENTS` matches a subfolder name (exact or
  substring), use that one. Otherwise, list the available maps and ask:
  > "Found multiple maps:
  > - `.claude/map/hidden-classes/` — {description from goon.yaml}
  > - `.claude/map/gc-refactor/` — {description from goon.yaml}
  > Which one are you working on?"

Once loaded, all MAP files, handoff files, and phase docs live in `{map_dir}/`.

## 2. Find and read the latest handoff

Handoff files live in `{handoff.dir}/{handoff.prefix}*.md` (defaults:
`{map_dir}/SESSION_HANDOFF*.md`). Glob for all matching files and pick the one
with the highest number suffix:

- `SESSION_HANDOFF-05.md` beats `SESSION_HANDOFF-04.md`
- Unnumbered `SESSION_HANDOFF.md` is iteration 1 (lowest priority)
- Sort numerically, not lexicographically (`-10` beats `-9`)

Read the **entire** latest file. This is your primary context for the session.
Everything in it — project description, known bugs, workflow lessons, style
guide — is authoritative until you verify otherwise.

If no handoff file exists, tell the user:

> "Found `goon.yaml` but no handoff file. Run `/map [what you want to build]`
> to generate the initial handoff, or `/handoff` to create one from the
> current project state."

Then stop.

## 3. Check for MAP plan

Look for `{map_dir}/MAP_PLAN.md` and `{map_dir}/MAP_PHASE_*.md` files. If they
exist, this project has a structured plan. Read `MAP_PLAN.md` to understand the
overall architecture and phases.

**Look for `Appendix B — Resume guidance`** at the bottom of `MAP_PLAN.md`. If
present, it's the authoritative resume checklist for this MAP — follow it
verbatim instead of improvising. It typically lists:
- Files to read in order
- How to identify the next pending phase
- How to dispatch the phase agent (usually points at `Appendix A — Standard
  agent dispatch preamble` in the same file)

Also look for `## TODO before dispatch` in `MAP_PLAN.md` — a checklist the
orchestrator should work through before spawning the next phase agent
(re-read style guides, verify cited file paths still resolve, etc.).

Cross-reference the handoff's phase progress notes with the MAP phases to
determine:
- Which phases are **done** (completed in previous sessions)
- Which phase is **current** (in progress or next up)
- Which phases are **pending**

Read the current phase's `MAP_PHASE_N.md` doc — this is your implementation
guide for the session.

## 4. Check project state

Run these in parallel:

- **Git state**: `git log --oneline -20` to see recent commits
- **GitHub issues**: If `repo` and `milestone` are set in goon.yaml, run:
  `gh issue list --repo {repo} --milestone "{milestone}" --state open`
- **Quick build check**: If `checklist.quick` is defined, run those commands
  to verify the project is in a working state

If the quick build check fails, flag it immediately:

> "Build check failed — here's the error: [error]. Want to fix this first
> before we plan the session?"

Wait for the user's response before continuing.

## 5. Orient the session

Present a concise summary to the user:

1. **Project**: name and one-line description
2. **MAP progress** (if MAP exists): phases done / total, current phase name
   and goal
3. **Current milestone**: what's open, what's closed, what ships
4. **Last session**: brief summary of what was done (from handoff)
5. **Priorities**: what to work on now — derived from the current MAP phase
   (if it exists) or the handoff's "what to build next" section
6. **Known issues**: any blockers or bugs noted in the handoff

If the user passed a focus area as `$ARGUMENTS`, prioritize that area in your
summary and suggest a plan of attack for it.

## 6. Read key files

If `key_files` is defined in goon.yaml, read CLAUDE.md (always) and skim the
first 2-3 key files listed. Don't dump them to the user — just internalize them
so you're ready to work.

## 7. Confirm direction and plan

Present the top priority and ask for confirmation:

**"Ready to continue Phase N: {phase name}. {one-line summary}. Sound good,
or do you want to focus on something else?"**

Wait for their response. They might:
- Confirm → proceed to step 8
- Redirect → adjust priorities, then proceed to step 8
- Ask questions → answer from your loaded context

## 8. Ultrathink and plan the attack

Once the user confirms direction, **ultrathink** and produce a concrete plan
for the session. This is the most important step — don't leave the user having
to tell you what to do.

The plan should include:
1. **Goal**: what's done when this session is over (specific exit criteria)
2. **Approach**: the sequence of changes, in dependency order
3. **Key files**: which files you'll be reading and modifying
4. **Risk areas**: anything tricky (borrow checker, API changes, migration)
5. **Agent strategy**: how you'll use subagents to parallelize the work

Present this to the user for sign-off. Once confirmed, start executing.

## Your role: orchestrator

You are the **orchestrator**. Your job is to plan, coordinate, and review —
not to write every line of code yourself. Preserve your context window for
decision-making by delegating implementation to agents:

- **Use agents for coding tasks**: spawn agents with detailed prompts that
  include file paths, function signatures, what to change, and exit criteria.
  The agent writes the code; you review the result.
- **Use agents for exploration**: when you need to understand a part of the
  codebase, spawn an Explore agent rather than reading dozens of files yourself.
- **Stay high-level**: keep track of the plan, verify agents' work compiles
  and passes tests, make architectural decisions, and course-correct.
- **Batch independent work**: if two changes don't touch the same files,
  spawn agents in parallel.

Don't burn context on implementation details you can delegate.