From fulcrum
Use when the user invokes /compound, says "capture learnings", "what did we learn", or when suggesting post-cycle knowledge capture after completing a development branch
How this skill is triggered — by the user, by Claude, or both
Slash command
/fulcrum:compound-learningThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Compound learning captures knowledge from completed development cycles — what worked, what didn't, patterns discovered, gotchas encountered — and feeds it back into project configuration to improve future cycles. It is optional, engineer-driven, and never forced.
Compound learning captures knowledge from completed development cycles — what worked, what didn't, patterns discovered, gotchas encountered — and feeds it back into project configuration to improve future cycles. It is optional, engineer-driven, and never forced.
/compoundWhen NOT to use:
Identify the most recently completed cycle by examining:
Git history — Check git log for recent commits on the current branch. What was the scope of work?
Spec document — Look in docs/specs/ for a spec associated with this work. If found, it provides the original intent and requirements.
Plan document — Check if a plan was created (/spec or /write-plan output). This shows the intended approach.
Files changed — Run git diff --stat against the base branch to see what was actually modified.
Session notes — Check docs/session-notes/ for debrief files left by subagent implementers. These capture gotchas, false starts, and decisions that never appear in commits. Read all notes from this cycle (match by task name or recency). These are the richest source of learnings — don't skip them.
Cycle context summary:
Present the cycle summary to the engineer for confirmation before proceeding:
I found the following cycle: [summary]. Is this the work you want to capture learnings from?
Analyze the cycle for notable learnings in these categories:
| Category | What to look for |
|---|---|
| Patterns | Recurring code patterns or architectural decisions that worked well |
| Gotchas | Problems encountered and how they were resolved |
| Tools | Libraries, frameworks, or tools that were particularly useful or problematic |
| Process | Aspects of the development workflow that helped or hindered |
| Project-specific | Conventions or constraints specific to this project |
| False starts | Approaches tried and abandoned (and why) |
For each proposed learning, provide:
Present proposed learnings one at a time. For each one, the engineer can:
If no notable learnings are found, say so honestly:
This cycle was clean — no notable learnings to capture. The existing patterns and standards worked well.
For each approved learning:
Save to docs/learnings/YYYY-MM-DD-topic.md:
# Learning: [Topic]
**Date:** YYYY-MM-DD
**Category:** Pattern | Gotcha | Tool | Process | Project-specific
**Cycle:** [Related spec or feature description]
## Description
[What was learned]
## Context
[When does this apply? When is it not relevant?]
## Example
[Concrete instance from the cycle that demonstrates this learning]
## Applied To
- [x] `docs/learnings/` — This document
- [ ] `CLAUDE.md` — [pending or description of what was added]
- [ ] `.claude/project-config.md` — [pending or not needed]
If the learning implies a rule or guideline that should apply to future work:
CLAUDE.mdCLAUDE.md doesn't exist yet, create it with a minimal structureDo NOT bloat CLAUDE.md. Each entry should be actionable and specific. Prefer:
"Always use parameterized queries for database access — see docs/learnings/2026-02-11-sql-injection.md"
Over:
"We learned that SQL injection is a risk when building database queries, and we should always use parameterized queries to prevent this. This was discovered when building the user search feature where we initially used string concatenation..."
If a learning implies a project-specific standard that should be codified:
.claude/project-config.mdBefore proposing any learning, check for duplicates:
docs/learnings/ — Read existing learning documents. Does this learning already exist?CLAUDE.md — Is this already captured as a rule or guideline?.claude/project-config.md — Is this already a project standard?If a learning overlaps with an existing one:
fulcrum:spec-driven-development — specs provide the original intent for comparisonCLAUDE.md — project rules and guidelines.claude/project-config.md — project-specific standards (with engineer approval)fulcrum:finishing-a-development-branch — natural point to suggest running /compoundBefore considering compound learning complete:
docs/learnings/npx claudepluginhub raphavr/fulcrum --plugin fulcrumCaptures learnings from completed development sessions into reusable knowledge files organized by pattern, pitfall, decision, tool insight, and process improvement.
Captures post-task learnings, promotes patterns to docs/ADRs, updates workflows/systems from failures and user corrections. Auto-invokes on task completion or 'done'.
Reviews completed work to extract learnings, validate shipping, and promote insights. Activates after tasks, PR arcs, or sessions finish, or after 5+ PRs.