--- name: pause description: "Save your current session state for later resumption." allowed-tools: Read, Write, Bash, Glob argument-hint: "[reason]" --- **STOP — DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's plugin system. Using the Read tool on this SKILL.md file wastes ~7,600 tokens. Begin executing Step 1 immediately.** ## Step 0 — Immediate Output **Before ANY tool calls**, display this banner: ``` ╔══════════════════════════════════════════════════════════════╗ ║ PLAN-BUILD-RUN ► PAUSING SESSION ║ ╚══════════════════════════════════════════════════════════════╝ ``` Then proceed to Step 1. # /pbr:pause-work — Save Session State You are running the **pause** skill. Your job is to capture the current session state so the user can resume exactly where they left off in a future conversation. This creates a `.continue-here.md` handoff file with everything the next session needs. This skill runs **inline** (no Task delegation). --- ## Core Principle **Capture everything the next session needs to hit the ground running.** The resume skill will read this file cold, with zero prior context. Write it as if you're handing off to a colleague who has never seen this project. --- ## Flow ### Step 1: Read Current State **Flag: `--checkpoint`** If `$ARGUMENTS` contains `--checkpoint`: - Perform a lightweight state dump without full session analysis - Write a minimal .continue-here.md with just: Position, git status, and suggested next action - Skip the detailed "Completed This Session" analysis (saves time) - Useful for quick manual checkpoints at any point Read the following files to understand where things stand: 1. **`.planning/STATE.md`** — Current position - Extract: current phase, current plan, progress, blockers - If STATE.md doesn't exist, display: ``` ╔══════════════════════════════════════════════════════════════╗ ║ ERROR ║ ╚══════════════════════════════════════════════════════════════╝ No Plan-Build-Run project state found. Nothing to pause. **To fix:** Run `/pbr:new-project` to initialize a project first. ``` 2. **`.planning/config.json`** — Project settings - Extract: project name, feature toggles 3. **`.planning/ROADMAP.md`** — Phase overview - Extract: current phase name, total phases ### Step 2: Determine Current Phase Directory From STATE.md, get the current phase number and find its directory: 1. List directories in `.planning/phases/` 2. Match the current phase number to a directory 3. If no match: use the most recently modified phase directory ### Step 3: Gather Session State Collect the following information: #### Current Position - Phase number and name - Plan number (if mid-phase) or "between plans" - Status: in-progress, between-plans, between-phases, planning, reviewing #### Work Completed This Session Scan the current phase directory for SUMMARY.md files: - Read each SUMMARY.md frontmatter - Note which ones were created/modified recently (check timestamps or git log) - For recently completed plans: extract the plan name and brief status Also check git log for recent commits: ```bash git log --oneline -20 --since="8 hours ago" ``` This gives a reasonable window for "this session's work." #### Remaining Work Scan for plan files without corresponding SUMMARY.md files: - These are plans that haven't been executed yet - List them with brief descriptions from their frontmatter #### Key Decisions Made Check for: - Recent CONTEXT.md files (from `/pbr:discuss-phase`) - Key decisions in recent SUMMARY.md files - Any deviations noted in summaries #### Blockers or Concerns From STATE.md blockers section and any: - Failed verifications - Checkpoint stops - Active debug sessions - Unresolved issues noted in summaries #### What to Do Next Determine the logical next action (same routing logic as `/pbr:progress`): - If mid-plan execution: "Continue building phase N" - If between plans in a phase: "Execute next plan (plan M)" - If phase complete, not reviewed: "Review phase N" - If phase reviewed, has gaps: "Fix gaps in phase N" - If phase complete: "Plan phase N+1" #### Mental Context Reflect on the current approach: - What strategy is being followed for this phase? - Why was this approach chosen over alternatives? - What's been tricky or surprising? - Any user preferences expressed in the current conversation? ### Step 4: Write .continue-here.md **CRITICAL: Write pause state NOW before displaying confirmation. Do NOT skip this step.** Write the handoff file to the current phase directory: **Path:** `.planning/phases/{NN}-{phase-name}/.continue-here.md` **Content:** Read `${CLAUDE_SKILL_DIR}/templates/continue-here.md.tmpl` for the handoff file format. Fill in all `{variable}` placeholders with actual session data gathered in Steps 1-3. Fill in all XML sections. The `` section should capture your understanding of the current approach and reasoning -- not just facts. Think of it as a message to your future self explaining what was going on. ### Step 4b: Write HANDOFF.json (Machine-Readable Companion) **CRITICAL: Write HANDOFF.json NOW, alongside .continue-here.md. Do NOT skip this step.** After writing `.continue-here.md`, also create `.planning/HANDOFF.json` with structured state for machine consumption: 1. Read current STATE.md for phase/plan/status 2. Read current plan file to get task progress (current task, total tasks) 3. Check for uncommitted files via `git status --short` 4. Read the HANDOFF.json template: `${CLAUDE_PLUGIN_ROOT}/templates/HANDOFF.json.tmpl` 5. Fill in all fields from the template with actual session data: - `status`: "paused" - `created_at`: current ISO timestamp - `phase`: number, slug, and name from STATE.md - `plan`: number, wave, current task, total tasks - `next_action`: the suggested next action from Step 3 - `blockers`: any blockers from STATE.md or verification failures - `human_actions_pending`: any actions the user needs to take - `completed_tasks`: task descriptions already done in current plan - `uncommitted_files`: from `git status --short` - `context_notes`: mental context about current approach and reasoning **CRITICAL: Write HANDOFF.json NOW. This file is required for session resumption.** 6. Write the filled JSON to `.planning/HANDOFF.json` **Purpose:** `.continue-here.md` is human-readable; `HANDOFF.json` is machine-readable. The resume skill reads HANDOFF.json first for structured data, falling back to `.continue-here.md` for backward compatibility. ### Step 5: Update STATE.md **CRITICAL -- DO NOT SKIP: Update STATE.md via CLI.** ```bash pbr-tools state record-session --stopped-at "{brief description of current work}" ``` This updates STATE.md frontmatter (`session_last`, `session_stopped_at`, `session_resume`, `last_command`, `last_activity`) and the Session Continuity body section atomically. Also update the session_resume pointer: ```bash pbr-tools state update last_command "/pbr:pause-work" ``` If the CLI fails, display a branded ERROR box: "Failed to update STATE.md session state." and stop. ### Step 6: Commit as WIP Reference: `skills/shared/commit-planning-docs.md` for the standard commit pattern. If `planning.commit_docs: true` in config.json: ```bash git add .planning/phases/{NN}-{phase-name}/.continue-here.md git add .planning/HANDOFF.json git add .planning/STATE.md git commit -m "wip(planning): save session state — phase {N} plan {M}" ``` **Commit rules:** - Always use `wip(planning):` prefix for pause commits - Include phase and plan numbers - Stage only the continue-here and STATE.md files - Do NOT stage any code changes (those should already be committed by the executor) ### Step 7: Confirm to User Display branded confirmation: ``` ╔══════════════════════════════════════════════════════════════╗ ║ PLAN-BUILD-RUN ► SESSION SAVED ✓ ║ ╚══════════════════════════════════════════════════════════════╝ Position: Phase {N} — {phase name}, Plan {M} Completed: {count} plans this session Remaining: {count} plans in this phase ╔══════════════════════════════════════════════════════════════╗ ║ ▶ NEXT UP ║ ╚══════════════════════════════════════════════════════════════╝ **Resume in your next session** `/pbr:resume-work` `/clear` first → fresh context window ``` --- ## What Gets Captured | Information | Source | Why It Matters | |-------------|--------|---------------| | Phase + plan position | STATE.md | Know where to start | | Completed work | SUMMARY.md files, git log | Know what's already done | | Remaining work | Plan files without summaries | Know what's left | | Decisions | CONTEXT.md, SUMMARY.md | Preserve user preferences | | Blockers | STATE.md, verification files | Don't repeat failed approaches | | Next steps | Routing logic | Immediate action on resume | --- Reference: `skills/shared/error-reporting.md` for branded error output patterns. ## Edge Cases ### No work was done this session - Still write the continue-here file - "Completed This Session" section says: "No plans completed (discussion/planning only)" - Capture any decisions or context from the conversation ### Multiple phases were worked on - Write .continue-here.md in the MOST RECENT phase directory - Reference the other phases in the "Completed This Session" section - Next steps should focus on the current position ### Mid-task pause (executor was interrupted) - Note which task was in progress - Warn: "Task {name} was in progress when paused. It may need to be re-executed." - Check git log to see if any partial commits exist ### .continue-here.md already exists - **Always REPLACE** the existing file entirely — never append - Appending causes stale data from previous sessions to persist, which confuses resume - The old .continue-here.md content is superseded by the current state - No need to ask the user — the current session state is always more accurate ### STATE.md doesn't exist - Warn: "No STATE.md found. Creating a minimal pause file." - Write .continue-here.md based on git log and file system scan only - Don't try to update STATE.md ### No git history (fresh project) - Skip the git log step - Estimate session work from file modification times - Still write the continue-here file --- ## Anti-Patterns 1. **DO NOT** include full file contents in .continue-here.md — keep it concise 2. **DO NOT** stage code files in the WIP commit — only planning docs 3. **DO NOT** skip the commit when `planning.commit_docs` is enabled — the WIP commit preserves the pause state in version control and ensures `.continue-here.md` is not lost if working tree changes occur 4. **DO NOT** write multiple .continue-here.md files — one per pause 5. **DO NOT** include sensitive information (API keys, passwords) in the handoff 6. **DO NOT** modify any code files — this skill only writes planning docs 7. **DO NOT** skip the "Next Steps" section — it's the most important part for resumption