| name | context-curation-base |
| description | Framework for managing project file context after retros/planning. Trigger after weekly retro + planning complete, after monthly retro + planning complete, or when context feels bloated. Also triggers with "context curation", "clean up project files", "archive old summaries", "what can we remove". Uses fractal compression with fold-before-archive pattern. |
Context Curation Skill
Created: Monday, January 19, 2026
Updated: Monday, January 20, 2026
Purpose: Systematic process for managing project file context after retros/planning sessions
Status: Experimental
Overview
Context curation follows the "fractal compression" pattern: each level of summary makes the previous level's raw inputs archivable. Before archiving, fold extractable data into addendums or reference docs.
Trigger phrases:
- "context curation"
- "clean up project files"
- "archive old summaries"
- "what can we remove"
Compression Hierarchy
Daily summaries → Weekly retros → Monthly retros → Quarterly retros → Yearly retros
| After completing... | These can be archived... |
|---|
| Daily summary | Raw conversation logs for that day |
| Weekly retro | Daily summaries for that week |
| Monthly retro | Weekly retros for that month |
| Quarterly retro | Monthly retros for that quarter |
| Yearly retro | Quarterly retros for that year |
Principle: Keep at least one copy at each granularity level.
Retention Minimums
Keep at least one document at each granularity level:
| Level | Minimum to Keep |
|---|
| Daily | 1-2 most recent summaries |
| Weekly | Current week's plan + most recent retro |
| Monthly | Current month's plan + most recent retro |
| Quarterly | Current quarter's plan + most recent retro |
| Yearly | Current year's plan + most recent retro |
Principle: Even after compression, maintain the ability to see recent state at each time scale.
Fold Before Archive
Before archiving daily summaries, extract data that should persist in reference docs.
What to Extract
- Quantitative progress (reps, times, measurements, PRs)
- Protocol changes or discoveries
- Status updates for tracked items
- Confirmed additions (new safe foods, new movements, etc.)
Where to Extract
Addendum files for reference docs that accumulate data:
Reference-Doc.md → Reference-Doc-Addendum-YYYY-MM-DD-to-DD.md- Date range matches the weekly retro period
- Example:
Training-Log-Addendum-2026-02-16-to-22.md
Direct updates for simple status changes:
- Single value changes can go directly to main doc
- Level progressions, status flips, etc.
Addendum Naming Pattern
{Reference-Doc}-Addendum-YYYY-MM-DD-to-DD.md
Where date range matches the weekly retro being processed.
When Addendums Get Compressed
During weekly curation, fold addendums into their main docs:
- Review addendum content
- Integrate into appropriate sections of main doc
- Update revision date on main doc (e.g.,
**Updated:** 2026-02-23)
- Save updated doc to project (replaces old version)
- Archive the processed addendum
Why revision dates matter: When Claude produces an artifact for a reference doc, the revision date makes it clear which version is current. Old version can then be archived/removed from project.
Reference Doc Versioning
Date-in-filename (preferred for periodic revisions):
Identity-Ecosystem-2025-12.md → Identity-Ecosystem-2026-03.md- Old version archived when new version created
Updated-in-content (for incremental updates):
- Keep same filename, update internal
**Updated:** YYYY-MM-DD
- Works when addendums fold in small changes
File Categories
Always Keep (Reference Docs)
Documents with ongoing reference value that don't get "rolled up":
- Protocol docs (training plans, nutrition guidelines, recovery routines)
- Framework docs (goal hierarchies, progress tracking systems)
- Context docs (current status, background information)
- Research plans (active investigation threads)
Keep Current Layer
Most recent documents at each temporal scale:
- Current week's plan + most recent weekly retro
- Current month's plan + most recent monthly retro
- 1-2 most recent daily summaries (bridge to current conversation)
Archive Candidates
Documents whose content has been synthesized into higher-level summaries:
- Daily summaries covered by weekly retro (after extraction complete)
- Weekly retros covered by monthly retro
- Past weekly plans (executed, retro complete)
- Past monthly plans (after monthly retro captures outcomes)
- Processed addendums (folded into main docs)
- Old versions of reference docs (replaced by updated version)
Process
1. Identify Temporal Boundary
What retro just completed?
- Weekly retro → daily summaries for that week can archive
- Monthly retro → weekly retros for that month can archive
2. Review Dailies for Extractable Data
Scan the daily summaries being archived for:
- Quantitative data that belongs in reference docs
- Protocol changes or confirmations
- Progress markers that should persist
3. Extract to Addendums
For each reference doc with extractable data:
- Create or append to addendum file for this week
- Use naming:
{Reference-Doc}-Addendum-YYYY-MM-DD-to-DD.md
4. Compress Addendums into Main Docs
If any addendums exist from previous weeks:
- Review addendum content
- Integrate into appropriate sections of main doc
- Mark addendum for archiving
5. List Archive Candidates
Quick pass through project files:
- Reference docs: List, confirm keeping, check freshness
- Current layer: Identify most recent at each scale
- Archive candidates: List with reasoning
Format:
**EXTRACT - From this week's dailies:**
- [file]: "[data]" → [addendum file]
**COMPRESS - Addendums ready to fold:**
- [addendum file] (N entries) → [main doc]
**KEEP - Reference Docs:**
- [file] - [brief reason if not obvious]
**KEEP - Current Layer:**
- [file] - [which layer: daily/weekly/monthly]
**REFRESH - May Be Stale:**
- [file] - [why it may need updating]
**ARCHIVE - Folded into [Retro Name]:**
- [file]
- [file]
Refresh triggers (reference docs don't get archived, but they do get stale):
- Time-based: Last updated 30+ days ago
- Event-based: Major milestone, level change, protocol shift
- Content-based: Information contradicts recent summaries/retros
6. User Confirms and Archives
User reacts with:
- ✓ (agree with recommendation)
- ✗ (keep/reconsider specific file)
- Additional context ("also archive X" or "actually keep Y because...")
User then:
- Extracts data to addendums
- Compresses addendums into main docs
- Removes archived files from project
Edge Cases
Files Not Clearly Covered
If a time period's retro is missing or incomplete:
- Keep the lower-level docs until coverage exists
- Example: Keep Week 11 retro if December monthly doesn't clearly cover that period
Reference Docs That Need Updates
Some "reference" docs get stale:
- Training plans → update as fitness levels change
- Equipment/gear lists → update as needs evolve
- Goal frameworks → update after major milestone shifts
Flag these for refresh rather than archive.
Blended Summaries
When daily summaries span multiple days (due to missed days or combined entries):
- Still archive after weekly retro covers the period
- The blending itself is captured in the retro
- Extract any quantitative data before archiving
No Extractable Data
If dailies have no quantitative/protocol data to extract:
- Skip the extract step
- Proceed directly to archiving
- Retro synthesis is sufficient
Decision Principles
- Fold before archive: Extract persistent data before removing source
- When in doubt, keep: Can always archive later
- Compression preserves signal: Higher-level synthesis captures what mattered
- Context is finite: Project files affect conversation quality
- Recent > old: Prefer keeping recent docs over historical
- Reference > temporal: Reference docs have longer shelf life than summaries
Example Session
After Week 8 Retro (Rob's running project):
Claude: Let's do context curation. First, any data to extract before archiving?
**EXTRACT - From this week's dailies:**
- Summary-02-16: "3.1mi at 9:45 pace" → Training-Log-Addendum-2026-02-16-to-22.md
- Summary-02-18: "New stretching routine working well" → Recovery-Protocol-Addendum-2026-02-16-to-22.md
- Summary-02-20: "PR: 5K in 28:32" → Training-Log-Addendum-2026-02-16-to-22.md
**COMPRESS - Addendums ready to fold:**
- Training-Log-Addendum-2026-02-09-to-15.md (4 entries) → Training-Log.md
- Recovery-Protocol-Addendum-2026-02-09-to-15.md (2 entries) → Recovery-Protocol.md
**KEEP - Reference Docs:**
- Training-Plan-5K.md
- Race-Schedule-2026.md
- Training-Log.md
- Recovery-Protocol.md
**KEEP - Current Layer:**
- Weekly-Plan-2026-02-23.md (current)
- Weekly-Retro-2026-02-16.md (just created)
- Summary-02-21.md, Summary-02-22.md (most recent)
**REFRESH - May Be Stale:**
- Training-Plan-5K.md - last updated 6 weeks ago, you've progressed past Week 4 intervals
**ARCHIVE - Folded into Week 8 Retro:**
- Weekly-Plan-2026-02-16.md
- Summary-02-16.md through Summary-02-20.md
- Training-Log-Addendum-2026-02-09-to-15.md (after compression)
- Recovery-Protocol-Addendum-2026-02-09-to-15.md (after compression)
User: Extracted the training data to addendums. Compressed last week's addendums into main docs. Archived the rest.
Claude: Good. Data preserved in reference docs. Context curated.
Integration Notes
When to trigger:
- After weekly retro + planning complete
- After monthly retro + planning complete
- When context feels bloated / conversation quality degrading
Typical weekly curation flow:
- Weekly retro (summary-of-summaries)
- Weekly planning
- Context curation:
a. Extract from dailies → addendums
b. Compress addendums → main reference docs
c. Archive dailies (now folded into retro)
d. Archive processed addendums (now folded into main docs)
Cognitive load:
- Keep it lightweight (quick pass, not deep analysis)
- User makes final call on each file
- Don't force decisions when depleted
Skill dependencies:
- Works alongside retrospective skills (uses their outputs)
- Works alongside planning skills (happens after planning complete)
"Fold before archive. Keep most recent at each layer."
