mission-memory

To store project learnings, you save insights as standalone markdown files with YAML frontmatter in the .mission-control/memory/ directory. This builds a persistent, per-project knowledge base that captures individual insights to prevent repeating past mistakes.

Loading universal gotchas works by automatically injecting any memory file marked with category: gotcha into every new mission. This mechanism guards against known traps across all projects without requiring manual lookup during your post-mission review.

The required YAML frontmatter schema for a mission memory file includes fields for tags, source, extractedAt, confidence, and category. Enforcing this schema ensures structured storage and supports tag-driven relevance for loading learnings into new missions.

To retrieve specific knowledge for a project handover, the system uses tag-driven relevance. Non-gotcha learnings load based on matching mission goal tags, supporting top-N selection by relevance and recency to ensure you get the most applicable insights.

Yes, you can manually add or edit memory files to reflect unique project learnings. Users create new files with descriptive kebab-case names in the .mission-control/memory/ directory, ensuring the YAML frontmatter and concise body accurately capture the insight.

The best way to structure knowledge transfer for recurring tasks is using a per-project memory system. By storing insights as YAML-frontmatter markdown files and tagging them appropriately, you enable automatic, context-aware loading of relevant learnings for future missions.