feed-the-machine 1.0.0

package/ftm-pause/references/protocols/SKILL-RESTORE-PROTOCOLS.md

@@ -0,0 +1,186 @@
+# Skill State Capture and Restoration Protocols
+
+This document defines exactly what state must be captured (by ftm-pause) and restored (by ftm-resume) for each ftm skill. It is the shared contract between the two skills.
+
+---
+
+## ftm-brainstorm
+
+### State to Capture
+
+**Phase tracking:**
+- Current phase (0, 1, 2, or 3)
+- If Phase 1: which round (1, 2, or 3), which path (A: Fresh Idea or B: Brain Dump)
+- If Phase 2: how many research+challenge turns have been completed
+- If Phase 3: which section of the plan has been presented (Vision, Tasks, Agents, or complete)
+
+**Phase 0 context:**
+- The full repo scan results (project type, tech stack, architecture, patterns, infrastructure, scale)
+- Whether the scan was skipped (no git repo) and any stack info gathered from the user instead
+
+**Phase 1 — Intake:**
+- The user's original idea/request (verbatim if short, summarized if long)
+- If Path B: the full brain dump extraction (decisions made, open questions, assumptions, contradictions, gaps)
+- All user answers from each completed round
+- Research Sprint 1 results (landscape context) — all findings from Web Researcher, GitHub Explorer, Competitive Analyst
+- Research Sprint 2 results (constraint-scoped research) — all findings from all three agents
+- If Path B: the novelty map (which claims are solved/partially solved/novel)
+
+**Phase 2 — Research + Challenge Loop:**
+- Every completed turn's 5 suggestions (or fewer if weak results) with evidence and links
+- Every challenge posed and the user's response
+- Every question asked and the user's answer
+- Accumulated decisions and direction chosen
+- Research agent results from each turn (summarized — full URLs and key findings, not raw agent output)
+- The current "direction" the brainstorm is heading (architecture chosen, scope narrowed, etc.)
+
+**Phase 3 — Plan Generation:**
+- Which sections have been presented and approved (Vision, Tasks, Agents/Waves)
+- The plan content generated so far
+- The plan file path if it's been saved
+- User feedback on each section
+
+### Restoration Instructions
+
+On resume, reload Phase 0 context into the project context register. Reload the full context register from Phase 2 state so the next research sprint does not re-search prior ground. Resume at exactly the turn number and phase detail captured — if the user was mid-Phase 2, the next action is a research sprint responding to their last answer.
+
+---
+
+## ftm-executor
+
+### State to Capture
+
+**Plan context:**
+- Plan file path (absolute)
+- Plan title and summary
+- Total task count
+- Agent team composition (agent names, roles, task assignments)
+
+**Execution progress:**
+- Current wave number
+- For each task: status (pending / in-progress / complete / failed / blocked)
+- For completed tasks: commit hashes, audit results (pass/fail/auto-fixed), brief summary of what was done
+- For in-progress tasks: which agent is working on it, what's been done so far
+- For failed/blocked tasks: what went wrong, error details
+
+**Worktree state:**
+- List of all worktree branches and their paths
+- Which worktrees are active vs merged vs abandoned
+- Any merge results or conflicts encountered
+- The main/working branch name
+
+**Verification state:**
+- Post-task audit results for each completed task
+- Any manual intervention items outstanding
+- Full test suite status (last run result)
+
+### Restoration Instructions
+
+On resume, verify that all worktrees in the saved state still exist on disk (`git worktree list`). If any are missing, note them for the user before continuing. Resume from the current wave, skipping tasks already marked complete. If a task was in-progress, treat it as needing restart from the beginning of that task.
+
+---
+
+## ftm-debug
+
+### State to Capture
+
+**Problem context:**
+- The original problem statement (symptom, expected behavior, what's been tried, when it started, reproduction steps)
+- Codebase reconnaissance results (entry points, call graph, state flow, dependencies, recent changes, test coverage, config, error handling)
+- The investigation plan (likely category, which agents deployed, worktree strategy)
+
+**Phase 1 — Investigation results:**
+- Instrumenter report: what was instrumented, log point locations, DEBUG-INSTRUMENTATION.md content
+- Researcher report: findings with sources, relevance, solutions, confidence, RESEARCH-FINDINGS.md content
+- Reproducer report: trigger command, consistency, boundaries, minimal test path, REPRODUCTION.md content
+- Hypothesizer report: all hypotheses ranked with claims, mechanisms, code paths, evidence, HYPOTHESES.md content
+
+**Phase 2 — Synthesis & Solve:**
+- Cross-reference analysis (how findings align or conflict)
+- Recommended fix approach
+- Solver attempts: which hypotheses tried, what was implemented, commit hashes
+- FIX-SUMMARY.md content if fix was applied
+
+**Phase 3 — Review & Verify:**
+- Reviewer verdict (APPROVED / APPROVED WITH CHANGES / NEEDS REWORK)
+- REVIEW-VERDICT.md content
+- How many solver-reviewer iterations completed
+- Outstanding issues from review
+
+**Worktree state:**
+- debug-instrumentation branch and path
+- debug-reproduction branch and path
+- debug-fix branch and path (including any fix attempt sub-branches)
+- Which worktrees still exist vs cleaned up
+
+### Restoration Instructions
+
+On resume, verify debug worktrees still exist. Re-read any artifact files referenced in the state (HYPOTHESES.md, REPRODUCTION.md, etc.) to reload their content into context. Resume at the exact phase captured — if mid-Phase 2, proceed to the next solver iteration using the saved hypotheses and prior solver attempts.
+
+---
+
+## ftm-council
+
+### State to Capture
+
+**Council setup:**
+- The council prompt (the framed problem statement)
+- Whether the user confirmed/edited the prompt
+- Prerequisites check result (codex and gemini available?)
+
+**Deliberation state:**
+- Current round number (1-5)
+- For each completed round, each model's full response:
+  - Research summary (what files examined, what was found)
+  - Position (their stance)
+  - Reasoning (with code references)
+  - Concerns
+  - Confidence level
+- For rebuttal rounds: each model's updated position, new evidence, responses to other models, remaining disagreements
+- Alignment analysis after each round (agreement areas, divergence points, different research paths, majority forming?)
+
+**Outcome:**
+- Whether consensus has been reached (and if so, which 2 models agreed)
+- The verdict if delivered (decision, agreed by, dissent, evidence basis)
+- If no consensus after 5 rounds: the synthesis and options presented
+
+### Restoration Instructions
+
+On resume, re-present the council prompt and the round history as a summary before continuing. If consensus was already reached, surface the verdict and ask the user what they want next. If still in deliberation, resume with the next model dispatch using full prior-round context.
+
+---
+
+## ftm-audit
+
+### State to Capture
+
+**Trigger context:**
+- What triggered the audit (manual invocation, post-task from executor, specific files/scope)
+- Scope (full project, specific files, specific task's changes)
+
+**Phase 0 — Project patterns:**
+- Detected framework, router, state management, API layer, build tool
+- Active dimensions (D1-D5) and their configuration
+- Any unusual patterns noted
+
+**Layer 1 — knip results:**
+- Full knip output (categorized: unused files, unused exports, unused deps, unlisted deps, unresolved imports)
+- Each finding with file:line
+
+**Layer 2 — Adversarial audit results:**
+- Each finding with type, location, evidence, and which dimension failed
+- Wiring contract checks if applicable (which checks passed, which failed)
+
+**Layer 3 — Auto-fix results:**
+- Fixes applied (finding, fix description, verification result)
+- Manual intervention items (finding, reason auto-fix skipped, suggested action)
+- Re-verification results
+- Current iteration count (of max 3)
+
+**Final status:**
+- PASS or FAIL
+- Remaining issues count and details
+
+### Restoration Instructions
+
+On resume, skip any layers already completed. If mid-Layer 3 auto-fix loop, restore the iteration count and continue from where it left off. If the final status was PASS, surface the result and confirm with the user before doing anything further.

package/ftm-pause/references/protocols/VALIDATION.md

@@ -0,0 +1,80 @@
+# State Validation Logic
+
+This document defines all validation checks performed before and after writing state to disk.
+
+---
+
+## Pre-Write Validation
+
+Before writing `~/.claude/ftm-state/STATE.md`, verify the following:
+
+### Skill Detection Confirmed
+
+- A ftm skill was positively identified from the conversation context
+- If no skill detected: halt and tell the user "No active ftm session detected" — do not write a blank or partial state file
+
+### Required Frontmatter Fields Present
+
+The YAML frontmatter block must contain:
+- `skill` — one of: ftm-brainstorm, ftm-executor, ftm-debug, ftm-council, ftm-audit
+- `phase` — the current phase number or stage name for that skill
+- `phase_detail` — a human-readable one-liner about exactly where the session stopped
+- `timestamp` — ISO 8601 format (YYYY-MM-DDThh:mm:ss)
+- `project_dir` — absolute path to the working directory
+
+Git fields (`git_branch`, `git_commit`) are required only if a git repo is present. If no repo, omit them rather than leaving them blank.
+
+### State File Contains Actual Content
+
+- "Next Step" section must be specific and actionable — not a placeholder like "[describe next step]"
+- Decisions Made section must reflect real decisions from the conversation, not template text
+- If the session was very early (e.g., Phase 0 only), the "Captured" summary should say so explicitly
+
+### Artifacts Verified
+
+For each artifact path listed in the state file:
+- The file must exist on disk at the recorded path
+- If an artifact path is stale (file was deleted or moved), note it with `[NOT FOUND]` rather than silently omitting it
+
+---
+
+## Post-Write Validation
+
+After writing the state file, verify:
+
+### File Was Written Successfully
+
+- The state file exists at `~/.claude/ftm-state/STATE.md`
+- File size is non-zero
+- The frontmatter block is parseable (starts with `---`, contains required keys)
+
+### State Is Resumable
+
+The written state must pass the "cold start test": a fresh conversation with no prior context should be able to reconstruct the session from the state file alone, without needing to ask the user "where were we?" Concretely:
+- The skill and phase are unambiguous
+- The Next Step section tells ftm-resume exactly what action to take first
+- Enough prior context is captured that the first response after resume won't require re-explaining the project
+
+---
+
+## Edge Case Handling
+
+### Multiple Skills Active
+
+If two ftm skills were invoked in the same conversation (e.g., brainstorm followed by executor), save the most recently active one to `STATE.md`. Save the other to `STATE-[skill].md` in the same directory. Both files go through the same validation.
+
+### Overwriting Existing State
+
+Overwrite `STATE.md` without prompting. The previous state was either already resumed and consumed, or abandoned. Validation still applies to the new file.
+
+### No Git Repo
+
+Skip `git_branch` and `git_commit` fields entirely. Record only `project_dir`. Do not write empty string values for these fields — omit them from the frontmatter block.
+
+### Very Early Session (Phase 0 or Step 1 Only)
+
+Capture whatever exists. Even a Phase 0 repo scan is worth saving. The "Next Step" section should note that the user needs to answer the first intake question. This passes validation — sparse state is valid state.
+
+### Large State Files
+
+Do not truncate. Some sessions accumulate substantial state — 8+ brainstorm turns with full research results, or an executor session with 20+ tasks. The state file can be large. Completeness is required for reliable restoration.

package/ftm-pause.yml

@@ -0,0 +1,2 @@
+name: ftm-pause
+description: Save the current ftm skill session state so work can be resumed in a new conversation. Use when user says "pause", "save state", "I need to stop", "continue later", "ftm pause", "save progress", or is about to end a session mid-workflow. Works with any ftm skill (brainstorm, executor, debug, council, audit).

package/ftm-researcher.yml

@@ -0,0 +1,2 @@
+name: ftm-researcher
+description: Deep parallel research engine with 7 domain-specialized finder agents, adversarial review via ftm-council, adaptive wave-based search, and codebase awareness. Use when the user wants thorough research on any topic — "research X", "find out about Y", "what's the state of the art on Z", "compare approaches to W", "deep dive into X", "look into Y". Also invoked by ftm-brainstorm for its research sprints. Triggers on "research", "investigate", "deep dive", "state of the art", "compare", "find examples of", "what's out there for", "how do others handle", "find me evidence", "look into". For idea exploration and brainstorming, use ftm-brainstorm instead (which calls ftm-researcher internally for research).

package/ftm-resume/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: ftm-resume
+description: Resume a previously paused ftm skill session from saved state. Use when user says "resume", "continue where we left off", "ftm resume", "pick up", or starts a new conversation wanting to continue previous ftm work.
+---
+
+## Events
+
+### Emits
+- `session_resumed` — when a saved session state has been validated and the appropriate ftm skill is re-invoked with restored context
+- `task_completed` — when the resume workflow finishes (skill re-invoked and state file archived)
+
+### Listens To
+(none — ftm-resume is explicitly invoked by the user and does not respond to events)
+
+# FTM Resume — Session State Restoration
+
+Read a saved ftm session state file and seamlessly continue the workflow in a fresh conversation. The user should feel like they never left — same context, same decisions, same progress, picking up at exactly the right step.
+
+## Why This Exists
+
+FTM skills are long-running, multi-phase workflows. A brainstorm session might span 10+ turns of research and questioning. An executor session might be mid-way through wave 2 of a 5-wave plan. A debug war room might have 4 investigation agents completed and a solver mid-attempt. When these sessions end — whether by choice, crash, or context exhaustion — the work shouldn't be lost. This skill reads the state file that ftm-pause saved and reconstructs the session so the appropriate ftm skill can continue exactly where it stopped.
+
+---
+
+## Step 1: Read and Validate
+
+Read `~/.claude/ftm-state/STATE.md`.
+
+Run all validation checks before proceeding. See `references/protocols/VALIDATION.md` for the full validation protocol covering:
+- State file integrity and required frontmatter fields
+- Version compatibility between saved state and installed skills
+- Project directory existence
+- Git state drift (branch changes, new commits)
+- Worktree branch availability (executor and debug)
+- Plan file existence (executor)
+- Artifact file availability (debug)
+- Session staleness (< 24h / 1–7 days / > 7 days)
+- Skill availability
+
+Present a consolidated validation summary before asking the user to confirm. A single block-level failure prevents resumption. Warnings require user acknowledgment.
+
+---
+
+## Step 2: Parse the Frontmatter
+
+Extract required YAML frontmatter: `skill`, `phase`, `timestamp`, `project_dir`. Optional fields: `phase_detail`, `git_branch`, `git_commit`.
+
+---
+
+## Step 3: Present the Resume Summary
+
+After validation passes (or the user acknowledges warnings), present the resume summary for the relevant skill.
+
+All summaries follow this structure — adapt the "Where we left off" fields to the skill:
+
+```
+Resuming ftm-{skill} session from {timestamp}
+Project: {project_dir}
+
+Where we left off:
+  [skill-specific fields — see below]
+
+Next step:
+  {next_step from state file}
+
+Ready to continue? (or type new context to add before resuming)
+```
+
+**ftm-brainstorm fields:**
+- Phase: {phase} — {phase_detail}, Path: {A or B}
+- Research sprints completed: {N}, Challenge turns: {N}
+- Decisions locked: {N} (list them), Open questions: {N} (list them)
+
+**ftm-executor fields:**
+- Wave: {current_wave} of {total_waves}, Tasks: {completed}/{total} complete
+- Done / In-progress (with agent) / Pending / Failed+Blocked (list each)
+- Worktrees: {N active}, Last audit: {result}
+
+**ftm-debug fields:**
+- Phase: {phase} — {phase_detail}, Problem: {one-line summary}
+- Investigation: Instrumenter / Researcher / Reproducer / Hypothesizer (complete/pending + finding)
+- Solver attempts: {N}, Reviewer verdict: {if any}, Worktrees: {list}
+
+**ftm-council fields:**
+- Council prompt: {brief summary}, Round: {N} of 5
+- Each model's one-line position, Consensus: {Yes/No + detail}
+
+**ftm-audit fields:**
+- Trigger: {what triggered it}
+- Phase 0 / Layer 1 / Layer 2 / Layer 3: {complete with findings / pending}
+- Status: {PASS/FAIL/in-progress}
+
+---
+
+## Step 4: Handle User Response
+
+**"Yes" / "Continue" / "Go"** — proceed to Step 5.
+
+**New context / additional information** — the user may say "yes, but also..." or provide updated information. Capture this as a "Post-pause update" section in the Context Snapshot. Pass it forward when invoking the skill.
+
+**"Start fresh" / "Never mind"** — archive the state file (see Step 6) and tell the user: "State archived. You can start a fresh session with /ftm-{skill}."
+
+---
+
+## Step 5: Invoke the Appropriate FTM Skill
+
+Invoke the ftm skill with the full saved context injected so it picks up exactly where it left off, not from the beginning. Construct a context preamble that tells the skill its position.
+
+Read `../ftm-pause/references/protocols/SKILL-RESTORE-PROTOCOLS.md` for the exact per-skill state fields to inject and restoration instructions for each skill (brainstorm, executor, debug, council, audit).
+
+### Context preamble pattern:
+
+```
+RESUMING FROM SAVED STATE — DO NOT START FROM PHASE 0.
+
+[Inject all relevant state sections from the state file, organized by the
+field groups defined in SKILL-RESTORE-PROTOCOLS.md for this skill.]
+
+NEXT STEP: {paste next_step from state file — this is where execution picks up}
+
+{if post-pause update: POST-PAUSE UPDATE FROM USER: {new context}}
+```
+
+Then invoke the skill via the Skill tool:
+- brainstorm: `/ftm-brainstorm`
+- executor: `/ftm-executor {plan_path}`
+- debug: `/ftm-debug`
+- council: `/ftm-council`
+- audit: `/ftm-audit`
+
+---
+
+## Step 6: Archive the State File
+
+After the skill has been successfully invoked, archive the consumed state file immediately:
+
+```bash
+mkdir -p ~/.claude/ftm-state/archive
+mv ~/.claude/ftm-state/STATE.md ~/.claude/ftm-state/archive/STATE-$(date +%Y%m%d-%H%M%S).md
+```
+
+Archive immediately after invocation — not after the full session completes. The state has been consumed. If the user needs to pause again, ftm-pause will create a new STATE.md from the now-continued session.
+
+---
+
+## Edge Cases
+
+**Multiple state files** — If both `STATE.md` and `STATE-ftm-brainstorm.md` exist, ask the user which one to resume. List them with skill type and timestamp.
+
+**User wants to resume but also change direction** — Add the direction change as a post-pause update. Let the skill's natural conversation flow handle it. Do not edit the state file directly.
+
+**Archived states** — If the user asks "do I have any old sessions?", check the archive:
+```bash
+ls -la ~/.claude/ftm-state/archive/
+```
+List archived states with skill type, timestamp, and phase. Offer to restore any of them (copy from archive to STATE.md, then run the normal resume flow).
+
+**Nothing to resume** — If `~/.claude/ftm-state/` doesn't exist or contains no STATE.md:
+```
+No saved ftm session found.
+
+To save a session for later:
+1. Start any ftm skill (/ftm-brainstorm, /ftm-executor, /ftm-debug, /ftm-council, /ftm-audit)
+2. When you need to stop, use /ftm-pause
+3. In a new conversation, use /ftm-resume to continue
+```

package/ftm-resume/references/protocols/VALIDATION.md

@@ -0,0 +1,172 @@
+# Resume Validation Protocols
+
+Before attempting to restore a session, run these environment checks. Each check either passes, warns, or blocks resumption.
+
+---
+
+## Check 1: State File Integrity
+
+Read `~/.claude/ftm-state/STATE.md`.
+
+**File missing:**
+```
+No saved ftm session found at ~/.claude/ftm-state/STATE.md
+
+To save a session mid-workflow, use /ftm-pause during any active ftm skill.
+```
+Stop here.
+
+**File exists but unparseable (missing frontmatter, malformed YAML):**
+```
+Found state file but it appears corrupted — missing required frontmatter fields.
+Expected fields: skill, phase, timestamp, project_dir
+
+Would you like me to try to extract what I can from the file, or should we start fresh?
+```
+
+**Required frontmatter fields:**
+
+| Field | Required | Purpose |
+|-------|----------|---------|
+| `skill` | Yes | Which ftm skill to resume |
+| `phase` | Yes | Which phase the skill was in |
+| `phase_detail` | No | Human-readable position within phase |
+| `timestamp` | Yes | When the session was saved |
+| `project_dir` | Yes | Project directory the session was working in |
+| `git_branch` | No | Git branch at time of save |
+| `git_commit` | No | HEAD commit at time of save |
+
+**Incomplete state (missing critical sections — no "Next Step," no "Context Snapshot"):**
+
+Warn: "The state file is incomplete — it may have been saved during an error. I can try to resume with what's available, but some context may be missing. Alternatively, we can start fresh."
+
+---
+
+## Check 2: Version Compatibility
+
+If the state file has a `ftm_version` field, compare it to the installed skill version.
+
+- **Same version**: Pass.
+- **Minor version difference**: Warn. "This state was saved with an older version of ftm. The workflow may behave slightly differently, but resumption should work."
+- **Major version difference**: Block with explanation. "This state was saved with ftm v{N}, but the installed version is v{M}. Major version changes may have altered skill structure. Resuming could produce unexpected behavior. Recommend starting fresh."
+- **No version field**: Proceed without warning (pre-versioning state files are assumed compatible).
+
+---
+
+## Check 3: Project Directory
+
+```bash
+test -d "{project_dir}" && echo "EXISTS" || echo "MISSING"
+```
+
+- **EXISTS**: Pass. Continue.
+- **MISSING**: Block. "The project directory `{project_dir}` no longer exists. Cannot resume — the codebase isn't available. Did the project move?"
+
+---
+
+## Check 4: Git State (if git fields present)
+
+```bash
+cd "{project_dir}" && git branch --show-current && git rev-parse --short HEAD
+```
+
+Compare current branch and commit against saved values.
+
+- **Same branch, same commit**: Pass — nothing changed.
+- **Same branch, different commit**: Warn. "The codebase has been modified since the session was saved. {N} new commits on `{branch}` since `{saved_commit}`." Show the commit log between saved and current. Ask if the user wants to continue anyway or review changes first.
+- **Different branch**: Warn. "You're now on branch `{current}` but the session was saved on `{saved_branch}`. Would you like to switch back to `{saved_branch}`, or continue on `{current}`?"
+
+---
+
+## Check 5: Worktree Branches (executor and debug only)
+
+If the state file references worktree branches:
+
+```bash
+cd "{project_dir}" && git worktree list
+git branch --list "plan-exec/*" "debug/*"
+```
+
+- **All referenced branches exist**: Pass.
+- **Some missing**: Warn. List which branches are missing. "These worktree branches from the saved session no longer exist: {list}. Tasks associated with these branches may need to be re-executed."
+- **All missing**: Warn more strongly. "All worktree branches from the saved session have been cleaned up. Completed task work may have been merged already. In-progress tasks will need to restart."
+
+---
+
+## Check 6: Plan File (executor only)
+
+If the state references a plan file:
+
+```bash
+test -f "{plan_path}" && echo "EXISTS" || echo "MISSING"
+```
+
+- **EXISTS**: Pass.
+- **MISSING**: Block. "The plan file `{plan_path}` no longer exists. Cannot resume executor without a plan. Do you have the plan elsewhere?"
+
+---
+
+## Check 7: Artifact Files (debug only)
+
+Check for any referenced artifact files (RESEARCH-FINDINGS.md, HYPOTHESES.md, REPRODUCTION.md, etc.):
+
+```bash
+for f in {artifact_paths}; do test -f "$f" && echo "$f: EXISTS" || echo "$f: MISSING"; done
+```
+
+- **All exist**: Pass.
+- **Some missing**: Warn. The state file should contain the key content from these files, so they're reconstructible. Note which are missing.
+
+---
+
+## Check 8: Staleness
+
+Calculate the age of the saved state by comparing the `timestamp` field to the current time.
+
+- **< 24 hours**: Fresh. No warning needed.
+- **1–7 days**: Mild staleness. Note and proceed: "This session is {N} days old. The codebase may have changed — check the git log above."
+- **> 7 days**: Present staleness options explicitly:
+
+```
+This session was saved 12 days ago. The codebase has likely changed significantly.
+
+Options:
+1. Resume anyway — use the saved context but some references may be outdated
+2. Resume with a fresh repo scan — re-run Phase 0 to update project context, then
+   continue from where you left off
+3. Start fresh — discard this state and begin a new session
+
+Which would you prefer?
+```
+
+If the user picks option 2: run Phase 0 of the relevant skill (repo scan for brainstorm, plan re-read for executor, codebase reconnaissance for debug) with fresh data. Merge the new scan with the saved state — keeping all decisions, answers, and progress but updating the project context.
+
+---
+
+## Check 9: Skill Availability
+
+If the state says `skill: ftm-debug` but that skill isn't in the skills directory:
+
+"The saved session requires ftm-{skill} but that skill isn't available. Install it and try again."
+
+Block resumption.
+
+---
+
+## Validation Summary
+
+Run all applicable checks in order. Present a consolidated summary before asking the user to confirm:
+
+```
+Validation complete:
+  ✓ State file: valid
+  ✓ Project directory: exists
+  ✓ Git state: same branch, 2 new commits (show log)
+  ⚠ Worktrees: plan-exec/task-3 missing
+  ✓ Plan file: exists
+  ✓ Session age: 6 hours
+
+1 warning. Ready to resume? (or review warnings first)
+```
+
+A single block-level failure prevents resumption. Warnings require user acknowledgment before proceeding.

package/ftm-resume.yml

@@ -0,0 +1,2 @@
+name: ftm-resume
+description: Resume a previously paused ftm skill session from saved state. Use when user says "resume", "continue where we left off", "ftm resume", "pick up", or starts a new conversation wanting to continue previous ftm work.