mission-memory

name	mission-memory
description	Distill learnings from a completed mission into persistent long-term memory. Use when a mission finishes or when significant knowledge should be preserved between tasks and phases.

Mission Memory

Overview

You are responsible for knowledge management. Distill learnings from the current mission into persistent memory that future missions can benefit from.

When to Use

• A mission has completed (called by mission-orchestrator)
• After each phase completes (to capture intermediate learnings)
• When significant knowledge is discovered that should persist

Memory Architecture

Short-term memory (per run)

• File: short_term_memory.md in the run directory
• Written by the orchestrator during execution
• Contains: granular run-specific details, what worked, what didn't, deviations
• Lifecycle: exists only for the duration of the run

Long-term memory (cross-run)

• File: memory/long_term.md in .pi/mission-control/
• Written by this skill at mission closeout
• Contains: distilled rules, conventions, patterns, anti-patterns
• Lifecycle: persists across all missions, loaded at mission-research start

Memory flow between tasks

After each task completes, the orchestrator should:

1. Write observations to short_term_memory.md
2. Note any deviations from the contract
3. Record tooling quirks discovered

Memory flow between phases

After each phase completes, the orchestrator should:

1. Summarize what the phase accomplished
2. Note any patterns that could help later phases
3. Record any gotchas discovered

Final distillation (this skill)

At mission closeout, read all short-term memory and distill into long-term.

Workflow

Final Distillation (called at mission end)

1. Read short_term_memory.md from the run directory
2. Read all auditor-report.md files — what failed, why, how it was resolved
3. Read all worker-output.md files — deviations and workarounds
4. Categorize learnings:
   • Repo conventions: "use single quotes for imports", "test files go in tests/"
   • Tooling quirks: "test runner needs --detectOpenHandles", "build fails if X"
   • Architecture decisions: what patterns worked, what didn't
   • Common failures: recurring issues and their solutions
   • Performance notes: slow tests, large files, hot paths
5. Read existing memory/long_term.md
6. Merge new learnings into long_term.md:
   • Do NOT overwrite — append or merge
   • Remove contradictory entries (new learning supersedes old)
   • Keep entries concise (one line per rule)
   • Organize by category
7. Confirm with user what will be persisted using ask_user
   • Use multiple-choice options with typed fallback
   • Keep wording clean with no emojis
   • Ask for confirmation only on the distilled learnings that matter
8. After confirmation, the mission is complete—no further skills to load

File Map

File	Action	Purpose
.pi/mission-control/runs/<run_id>/short_term_memory.md	Read	Run-specific notes
.pi/mission-control/runs/<run_id>/tasks/*/auditor-report.md	Read	Failure patterns
.pi/mission-control/runs/<run_id>/tasks/*/worker-output.md	Read	Deviations
.pi/mission-control/memory/long_term.md	Read + Write	Distilled knowledge

Anti-patterns

• Do NOT dump raw logs into long_term.md — distill to rules
• Do NOT overwrite long_term.md — merge
• Do NOT skip user confirmation — use ask_user to confirm what to persist
• Do NOT save task-specific details — only patterns that generalize

Next

No next skill. Mission is complete. State the final summary to the user.