Resume

Overview

ttm-resume is the session-recovery skill for takeToMarket. Marketing campaigns run across many sessions over many days, and context loss between sessions is where things get silently dropped. Resume loads the active campaign's STATE.md, summarizes the last completed phase, lists pending work and known blockers, and recommends the exact next /ttm-* command. It also detects interrupted verify/fix loops so you continue from where the loop stopped rather than restarting.

Use it when returning to a campaign after a session break. Invoke it with the campaign slug, e.g. ttm-resume spring-launch. Think of it as restoring a debugger state: you don't have to remember where you were because the state files do.

This is a read-only command. It does not modify any files; it reads campaign state and displays a recovery summary, and you run the suggested next command yourself.

How it works

Step 0: First-run inline education

Read .taketomarket/CONFIG.md. Parse first_run_seen (object) and inline_education (boolean, default true).

If inline_education is false, skip this step. Else if first_run_seen.ttm-resume is not true, print the explainer below verbatim, then mark this skill as seen:

node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" first-run mark ttm-resume

Use this exact check (bash) to decide whether to print: node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" first-run check ttm-resume --raw -- the JSON seen field is true once the explainer has run before.

Explainer for /ttm-resume

/ttm-resume is the session-recovery skill. It loads the active campaign's STATE.md, summarizes the last completed phase, lists pending work and known blockers, and recommends the exact next /ttm-* command. It also detects interrupted verify/fix loops so you continue from where the loop stopped.

Why it matters: marketing campaigns run across many sessions over many days, and context loss between sessions is where things get silently dropped. Resume is the equivalent of restoring a debugger state: you don't have to remember where you were because the state files do.

(Canonical source: references/inline-education-blurbs.md. Embedded verbatim because workflows do not @-resolve files at runtime.)

Purpose

Session recovery workflow for /ttm-resume. Loads campaign state, shows a context summary (last completed phase, what was done, pending work, blockers), and suggests the exact next /ttm-* command. Detects interrupted verify/fix loops so the user continues from where they left off rather than restarting.

State is loaded directly from CAMPAIGNS/<slug>/STATE.md (no separate handoff file).

Required reading: ${CLAUDE_PLUGIN_ROOT}/references/context-loading.md.

Constraints

Read-Only Command

This workflow does NOT modify any files. It is purely informational -- it reads campaign state and displays a recovery summary. The user runs the suggested next command themselves.

Process

Step 1: Load Context

takeToMarket > LOADING CONTEXT

Extract SLUG from $ARGUMENTS (strip --text flag if present):

SLUG=$(echo "$ARGUMENTS" | sed 's/--text//g' | xargs)

If SLUG is empty, error: "Usage: /ttm-resume [campaign-slug]. Provide a campaign slug." Exit.

Step 2: Load Campaign State

takeToMarket > LOADING CAMPAIGN STATE

Run:

node "${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs" campaign state "${SLUG}" --raw

If exists: false: tell user campaign not found. Suggest /ttm-new-campaign to create a new campaign. Exit.

Parse the full JSON output. Extract:

• phase (current campaign phase)
• name (campaign display name)
• last_updated (ISO timestamp of last state change)
• All phase.* timestamps (phase.created, phase.researched, phase.briefed, phase.produced, phase.verified, phase.reviewed, phase.fixed, phase.shipped, phase.measured, phase.learned)
• fix.run_count (number of fix loop iterations)
• review.overall_result (approved, revise, or null)
• verify.overall_result (pass, fail, or null)
• verify.run_count (number of verification runs)

Also read the FULL STATE.md file (not just CLI output) to get body content:

Read .taketomarket/CAMPAIGNS/${SLUG}/STATE.md

The body contains "Phase:" and "Next step:" lines plus any additional notes, blockers, or context left by previous workflow runs.

Step 3: Build Recovery Context

takeToMarket > RECOVERY CONTEXT

Determine last completed phase by finding the latest non-null phase.* timestamp. Use this ordering (earlier phases first):

1. created
2. researched
3. briefed
4. produced
5. verified
6. reviewed
7. fixed
8. shipped
9. measured
10. learned

For each completed phase, note the timestamp.

Calculate time since last activity from last_updated:

• If less than 1 hour: "X minutes ago"
• If less than 24 hours: "X hours ago"
• If less than 7 days: "X days ago"
• Otherwise: "X weeks ago" or exact date

Step 4: Detect Interrupted Loops

Check if campaign is mid-fix-loop:

• fix.run_count exists AND is > 0
• AND review.overall_result equals 'revise'

If yes: flag as interrupted fix loop. The user should run /ttm-fix ${SLUG} to continue the loop (NOT restart from scratch). Note the current attempt number.

Check if campaign is mid-verify:

• verify.run_count exists AND is > 0
• AND verify.overall_result is NOT 'pass'

If yes: flag as interrupted verification. Suggest re-running /ttm-verify ${SLUG} to continue verification from where it left off.

Step 5: Determine Next Command

Use the phase-to-command mapping to suggest the exact next command:

| Current Phase | Next Command            | Notes                                                                       |
|---------------|-------------------------|-----------------------------------------------------------------------------|
| created       | /ttm-discover ${SLUG}   | Campaign exists but no research done                                        |
| researched    | /ttm-brief ${SLUG}      | Research complete, needs brief                                              |
| briefed       | /ttm-produce ${SLUG}    | Brief ready, needs production                                               |
| produced      | /ttm-verify ${SLUG}     | Assets produced, needs verification                                         |
| verified      | /ttm-review ${SLUG}     | Verification passed, needs review                                           |
| reviewed      | See logic below         | Depends on review result                                                    |
| fixed         | /ttm-review ${SLUG}     | Fix applied, needs re-review                                                |
| shipped       | /ttm-measure ${SLUG}    | Shipped, awaiting measurement window                                        |
| measured      | /ttm-learn ${SLUG}      | Measured, needs learning extraction                                         |
| learned       | /ttm-archive ${SLUG}    | Learnings extracted, ready to archive                                       |
| archived      | None                    | "Campaign already archived. No further action needed."                      |
| cancelled     | None                    | "Campaign cancelled. No further action. Create a new with /ttm-new-campaign." |

Reviewed phase logic:

• If review.overall_result equals 'revise': suggest /ttm-fix ${SLUG}
• If review.overall_result equals 'approved': suggest /ttm-ship ${SLUG}
• If review.overall_result is null or unclear: suggest /ttm-review ${SLUG}

Override with interrupted loop detection (Step 4):

• If mid-fix-loop detected: override suggestion to /ttm-fix ${SLUG} regardless of phase-to-command mapping
• If mid-verify detected: override suggestion to /ttm-verify ${SLUG}

Step 6: Display Recovery Summary

takeToMarket > RESUME SUMMARY

Display formatted summary:

## Campaign Resume: ${SLUG}

**Campaign:** ${name}
**Current Phase:** ${phase}
**Last Activity:** ${relative_time} (${last_updated})

### Completed Phases
| Phase | Completed At |
|-------|-------------|
| Created | ${phase.created} |
| Researched | ${phase.researched} |
| ... | ... |

### Pending Work
${next_step_description -- derived from the phase and any body content in STATE.md}

### Suggested Next Command
> `/ttm-fix spring-launch`
> Reason: Fix loop in progress (attempt 2 of 3). Review flagged positioning drift.

If an interrupted loop was detected in Step 4, add a prominent note:

### Interrupted Loop Detected

**Type:** Fix loop (attempt ${fix.run_count} of 3)
**Reason:** Review result is 'revise' -- fixes needed before re-review.

Running `/ttm-fix ${SLUG}` will continue from attempt ${fix.run_count}, not restart.
Do NOT run `/ttm-produce` -- existing assets need fixing, not reproduction.

If the campaign has blockers noted in STATE.md body, display them:

### Known Blockers
${blockers from STATE.md body if any}

Additional Context Display

If time_since_last_activity is greater than 7 days, add a context refresh suggestion:

### Context Refresh Recommended

It has been ${days} days since last activity. Consider:
- Re-reading POSITIONING.md for any updates
- Checking CALENDAR.md for scheduling conflicts
- Running /ttm-health to verify campaign consistency

Success criteria

• Campaign state loaded from STATE.md (not a separate handoff file)
• Recovery context shows last completed phase and full timeline
• Interrupted fix loops detected (fix.run_count > 0 AND review.overall_result = revise)
• Interrupted verify loops detected (verify.run_count > 0 AND verify.overall_result != pass)
• Exact next /ttm-* command suggested based on phase-to-command mapping
• Loop detection overrides standard phase mapping when applicable
• No files modified (read-only command)

Output

No files modified. This is a read-only command that displays recovery context and suggests the next command for the user to run.

What if this doesn't fit?

Looks like /ttm-resume can't do that yet.

• Want a new skill? /ttm-request-skill
• Existing skill needs work? /ttm-improve-skill