Workflow Compound

Compound: Knowledge Compounding Workflow

You are orchestrating the Compound phase of the Compound Knowledge Work loop. Your job is to extract learnings from completed work and feed them back into the system so the next task is easier than the last.

The magic is in the compounding. Skip this phase and you're just working, not building.

Philosophy

Each documented pattern, template, and preference makes the next similar task faster and better. First attempt at a board update takes 4 hours of planning and drafting. Document the approach, and the next one takes 1 hour. That's compounding.

Process

Phase 1: Parallel Analysis

Launch these research agents in parallel:

1. Pattern Extractor - Analyze the completed work and conversation history:

   • What approach was taken?
   • What worked well? What didn't?
   • What would you do differently next time?
   • What frameworks or structures proved effective?

2. Template Assessor - Evaluate if this work could serve as a model:

   • Is this output reusable as a template?
   • What parts are situation-specific vs. generalizable?
   • How would you parameterize this for future use?

3. Preference Detector - Capture user preferences revealed:

   • What formatting or style preferences emerged?
   • What level of detail does the user prefer?
   • What communication style resonates?
   • What frameworks does the user gravitate toward?

4. Failure Analyzer (if things didn't go well):

   • What went wrong and why?
   • Was it execution, planning, or assumptions?
   • What early warning signs were missed?
   • What would prevent this next time?

Phase 2: Produce Discrete Insights

From the analysis, produce individual, self-contained insights. Each insight should stand alone - it may be read months later in a completely different context, or surfaced by a relevance filter alongside unrelated insights.

Every task should produce at least one insight. Most will produce 2-5. Each insight gets its own type:

Insight Format:

---
type: [pattern | template | preference | failure | insight]
date: [YYYY-MM-DD]
category: [communication | decision | analysis | meeting | coaching | operations]
task: [Brief description of the original task]
outcome: [success | partial | failure]
tags: [comma-separated: stakeholder names, frameworks, topics, projects]
takeaway: [One sentence - the key thing to remember. This is what gets searched.]
---

# [Descriptive Title]

## Context
[2-3 sentences: What task this came from, what the situation was]

## The Learning
[The actual insight, pattern, template, preference, or failure analysis. Self-contained - a reader should understand this without seeing anything else.]

## When to Apply
[Specific situations where this insight is relevant. Be concrete.]

## Related
[References to related insights by filename, if any]

Keep each insight focused. One pattern per file, one preference per file, one template per file. If a task yielded a good pattern AND a template AND a preference, that's three separate insight files. This granularity is what makes retrieval work.

Phase 3: Store and Index

Insights must be stored so the Research phase can find them quickly by category, keyword, or tag. This is how the loop closes.

1. Save each insight to a category subdirectory under .context/learnings/:

   • Path: .context/learnings/[category]/YYYY-MM-DD-[type]-[brief-description].md
   • Categories: communication/, decision/, analysis/, meeting/, coaching/, operations/
   • Create the directory if it doesn't exist
   • Use descriptive filenames that are greppable (e.g., 2026-02-12-pattern-premortem-board-prep.md)

2. Update the learnings index at .context/learnings/INDEX.md:

   • Add a row per insight with all searchable fields
   • Create the index with the table header if it doesn't exist

   Index format:

   # Learnings Index
   
   | Date | Type | Category | Title | Outcome | Tags | Takeaway | File |
   |------|------|----------|-------|---------|------|----------|------|
   | 2026-02-12 | pattern | decision | Pre-mortem for board decisions | success | board, pre-mortem, risk | Pre-mortem surfaces risks the team glosses over in optimistic planning | decision/2026-02-12-pattern-premortem-board.md |

   The Research phase searches this index by: type, category, tags, and full-text grep across the Takeaway column. Every field matters for retrieval.

3. Tag deliberately. Tags should include:

   • People/stakeholders involved (e.g., board, sarah, investors)
   • Frameworks used (e.g., SPADE, pre-mortem)
   • Topic area (e.g., pricing, hiring, product-launch)
   • Anything you'd search for when facing a similar task