Capture learnings from the workflow into reusable documentation. Stage 7 of the development workflow.
Scanned 9/6/2026
Install to Claude Code
npx -y skills add Kastalien-Research/thoughtbox --skill workflows-compound --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Workflows Compound?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/kastalien-research-workflows-compound-thoughtbox)More formats (shields.io, HTML) on the badges page.
---
name: workflows-compound
description: Capture learnings from the workflow into reusable documentation. Stage 7 of the development workflow.
argument-hint: "[optional focus area]"
user-invocable: true
---
Capture learnings from the current workflow: $ARGUMENTS
## Purpose
You are executing Stage 7 (Compound) of the development workflow. Implementation is reviewed and revised. Your job is to extract reusable learnings from this workflow and persist them so future workflows benefit. You are NOT writing code — you are documenting what was learned.
## Pre-Conditions
Before starting, verify:
1. `.workflow/state.json` exists and `currentStage` is `"compound"`
2. Review has passed (check `stages.review.status` is `"completed"`)
3. If revision happened, it's also completed
If pre-conditions are not met, report what's missing and halt.
## Process
### Step 1: Gather Evidence
Read all workflow artifacts:
1. **Workflow state**: `.workflow/state.json` — timeline, iterations, stage notes
2. **Sub-agent summaries**: `.workflow/summaries/*.md` — what was built
3. **Review report**: `.workflow/review-report.md` — what was found
4. **Spec and ADR**: The original design documents
5. **Git log**: What actually changed
```bash
git log --oneline --since="$(jq -r .startedAt .workflow/state.json)" -- .
```
### Step 2: Extract Learnings
Identify three categories of learnings:
**Solutions** — Reusable patterns for solving specific problems:
- What problem was solved?
- What approach worked?
- What approach was tried and didn't work?
- What would you do differently next time?
**Discoveries** — Things learned about the codebase or domain:
- Unexpected behaviors encountered
- Undocumented constraints discovered
- Performance characteristics measured
**Process** — What worked or didn't in the workflow itself:
- Which stages were smooth vs. painful?
- Where did revision loops happen and why?
- What spec assumptions were wrong?
### Step 3: Write Solution Document
If a reusable solution was produced, write it to `docs/solutions/`:
```markdown
# <Problem Title>
## Problem
[What problem this solves, in 2-3 sentences]
## Solution
[The approach that worked, with code references]
## Context
- Workflow: <id>
- Spec: <path>
- Date: <ISO date>
## Key Decisions
- [Decision 1]: [Why this choice was made]
- [Decision 2]: [Why this choice was made]
## What Didn't Work
- [Approach that was tried and abandoned, with brief explanation]
## Related
- [Links to specs, ADRs, or other solutions]
```
### Step 4: Update Agent Memory
If significant patterns or discoveries should persist across sessions:
1. Check existing memory files for related entries
2. Update or add entries as appropriate
3. Include fitness tags (HOT/WARM/COLD) per the DGM calibration rules
### Step 5: Record and Handoff
1. **Update workflow state** (`.workflow/state.json`):
- Set `stages.compound.status` to `"completed"`
- Set `stages.compound.completedAt` to current ISO timestamp
- Set `stages.compound.artifacts.solution` to the solution doc path (if created)
- Set `currentStage` to `"reflection"`
- Update `updatedAt`
2. **Present the handoff**:
```
COMPOUND COMPLETE
==================
Solutions captured: N
Discoveries: N
Process notes: N
Solution doc: <path or "none — no reusable pattern identified">
Next: Stage 8 - Reflection (/workflow-reflection)
```
## What Makes a Good Learning
A learning is worth capturing if it meets ANY of these:
- It would save >30 minutes if encountered again
- It contradicts documentation or common assumptions
- It reveals a non-obvious interaction between components
- It's a pattern that applies beyond this specific feature
A learning is NOT worth capturing if:
- It's specific to this feature with no broader applicability
- It's already documented in the codebase or specs
- It's a trivial fix that anyone would find quickly
## Anti-Patterns
- Do NOT capture every detail — focus on what's reusable
- Do NOT write vague learnings like "testing is important" — be specific
- Do NOT skip this stage because "nothing interesting happened" — every workflow teaches something
- Do NOT write code — this is a documentation stage
- Do NOT create solution docs for trivial changes — only for patterns worth reusing
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!