From coworkpowers
Extracts patterns, templates, and preferences from completed knowledge work to store learnings and improve future tasks. Activates on reflection requests like 'what did we learn' or after high-stakes work.
npx claudepluginhub nabeelhyatt/coworkpowers --plugin coworkpowersThis skill uses the workspace's default tool permissions.
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.
Extracts 1-3 key learnings (insights, playbooks, corrections, patterns) from completed knowledge work sessions and saves to docs/knowledge/ after approval, duplicate, and stale checks. Use after plans, analysis, or strategy.
Analyzes conversations after significant work or 'reflect' triggers to extract learnings, classify them, and integrate into laws, skills, rules, or documentation via structured tasks.
Extracts patterns, quirks, and decisions from conversations; persists to Markdown files in knowledge/learnings/. Use /learn for quick or /learn --deep for thorough analysis.
Share bugs, ideas, or general feedback.
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.
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.
Launch these research agents in parallel:
Pattern Extractor - Analyze the completed work and conversation history:
Template Assessor - Evaluate if this work could serve as a model:
Preference Detector - Capture user preferences revealed:
Failure Analyzer (if things didn't go well):
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 Type | What It Captures | Example |
|---|---|---|
pattern | An approach that worked or didn't | "Pre-mortem before board presentations surfaces risks the team glosses over" |
template | A reusable structure for future work | A generalized board update template with section placeholders |
preference | A user style/tone/detail preference | "Prefers bullet points over prose in executive summaries" |
failure | What went wrong and how to prevent it | "Announcing reorgs by email before 1:1s caused trust damage" |
insight | A non-obvious learning or connection | "Investors respond better when bad news is framed as decisions, not problems" |
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.
Insights must be stored so the Research phase can find them quickly by category, keyword, or tag. This is how the loop closes.
Save each insight to a category subdirectory under .context/learnings/:
.context/learnings/[category]/YYYY-MM-DD-[type]-[brief-description].mdcommunication/, decision/, analysis/, meeting/, coaching/, operations/2026-02-12-pattern-premortem-board-prep.md)Update the learnings index at .context/learnings/INDEX.md:
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.
Tag deliberately. Tags should include:
board, sarah, investors)SPADE, pre-mortem)pricing, hiring, product-launch)Based on what was learned, suggest improvements to the system:
Present these suggestions to the user for approval.
preference type insights alongside patterns and templatestemplate type insights with the generalized template in the body| Situation | Compound? | Focus On |
|---|---|---|
| Completed high-stakes work | Always | Full analysis - patterns, templates, preferences |
| Work received positive feedback | Yes | What worked, template creation |
| Work received negative feedback | Absolutely | Failure insights, prevention |
| Routine work done well | Sometimes | Efficiency patterns |
| New type of work attempted | Yes | Approach and framework learnings |
| Discovered user preference | Yes | Preference insight |
The loop is complete. For your next task, start again with: /coworkpowers:workflow-research