agentleFS
pfeffpfeff/claude-skills/skills/lessons-learned/SKILL.md

lessons-learned

Skill3 starsChanged 3 months agoMITView on GitHub

Interactive retrospective discussion about session problems, generating actionable recommendations

11 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 8 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When this skill is invoked:

    line 57
  2. Distinctive:

    Step 4: Create output note in Obsidian vault (only after user confirms recommendations)

    line 74
  3. Very specific:

    Frontmatter: Follow obsidian-notes skill conventions:

    line 105
  4. Distinctive:

    Start from verifiable facts — errors, logs, observable behavior

    line 114
  5. Distinctive:

    Ask "why" naturally in conversation — don't rigidly force five levels

    line 116
  6. Distinctive:

    Stop when you reach a cause that is actionable, preventable, and generalizable

    line 117
  7. Distinctive:

    Every problem discussed in Phase 2 gets at least lightweight Five Whys treatment

    line 121
  8. Distinctive:

    Insufficient data: Create partial report with available data

    line 167
  9. Distinctive:

    Analysis fails: Create partial report with completed phases, log errors

    line 169

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Lessons Learned Skill

Interactive retrospective that surfaces problems from the current session, discusses them collaboratively with the user, and captures agreed-upon findings and recommendations.

Core Concepts

Interactive Process:

  1. Surface Problems - Identify friction points and present for discussion
  2. Discuss Each Problem - Collaborative root cause analysis with user
  3. Agree on Recommendations - Synthesize and confirm with user
    • 3b: Propose CLAUDE.md updates
    • 3c: Identify permission whitelist candidates
    • 3d: Bridge to solution docs (problems with concrete fixes → /claude-skills:compound)
  4. Write Output - Capture agreed findings in Obsidian note

Interaction Model: This is a conversation, not a report. Engage the user at each phase. Wait for their input before proceeding. Let them steer which problems to explore and how deep to go.

Output: Obsidian note capturing discussed problems, agreed root causes, and confirmed recommendations. Optionally also creates solution docs via /claude-skills:compound for problems with concrete, reusable fixes.

Implementation Path: Skill/command improvements are submitted via PR to the claude-skills repo. (Skills were previously symlinked from pfeff/cursor-rules, which is now deprecated.)

Target Duration: ~15 minutes

Operations

1. Single Session Analysis (Default)

When: User requests /claude-skills:lessons-learned to analyze current session

Implementation: Load operations/single-session-analysis.md

Quick summary: Surface problems, discuss interactively with user, agree on recommendations, create Obsidian note

2. Pattern Aggregation

When: User requests /lessons-learned --aggregate or wants to identify recurring patterns across sessions

Implementation: Load operations/aggregate-patterns.md for detailed steps

Quick summary: Scan historical lessons learned files, extract patterns/anti-patterns/recommendations, aggregate by frequency, surface top improvement opportunities. Compares against previous aggregation to track effectiveness of skill improvements.

Execution

When this skill is invoked:

Step 1: Determine operation based on arguments

ArgumentsOperation
(none)Single session analysis
--aggregatePattern aggregation across sessions

Step 2: Load appropriate operation file

Read(file_path: "${CLAUDE_PLUGIN_ROOT}/skills/lessons-learned/operations/{operation}.md")

Step 3: Execute operation steps interactively (wait for user input between phases)

Step 4: Create output note in Obsidian vault (only after user confirms recommendations)

  • Before writing: Consult obsidian-notes skill for frontmatter standards (tags vs keywords, required tags)
  • Path: Generated/YYYYMMDDHHmm-Lessons Learned - {topic}.md
  • Format: Structured markdown with frontmatter per obsidian-notes conventions
  • Content: Problems discussed, agreed root causes, confirmed recommendations

Options

OptionTypeDefaultDescription
--aggregatebooleanfalseAggregate patterns across historical sessions
--focusstringallFocus area: efficiency/workflow/commands
--include-summarybooleanfalseInclude detailed conversation summary
--verbosebooleanfalseShow detailed analysis with supporting data
--limitint20Max files to analyze (with --aggregate)
--sincedatenoneOnly analyze files after date (--aggregate)
--min-frequencyint2Min occurrences to include (--aggregate)

Output Format

Creates Obsidian note in vault with:

Structure:

  • Session Overview (date, duration, tasks completed)
  • Problems Discussed (with root causes from Five Whys analysis)
  • Recommendations (confirmed by user)
  • Positive Patterns (what worked well)
  • Action Items (agreed-upon next steps)

Location: Generated/YYYYMMDDHHmm-Lessons Learned - {topic}.md

Frontmatter: Follow obsidian-notes skill conventions:

  • Required tag: generated_note
  • Keywords: Use wikilinks with capitalized, space-separated terms (e.g., "[[Lessons Learned]]", "[[Workflow Improvement]]")

Five Whys Strategy

The Five Whys is the core analytical technique for this skill. Apply it conversationally during Phase 2 for each problem discussed:

Approach:

  • Start from verifiable facts — errors, logs, observable behavior
  • Progress through system layers: Symptom → Tool → Platform → Process → Organization
  • Ask "why" naturally in conversation — don't rigidly force five levels
  • Stop when you reach a cause that is actionable, preventable, and generalizable
  • Engage the user at each level — they often have context Claude lacks

When to apply:

  • Every problem discussed in Phase 2 gets at least lightweight Five Whys treatment
  • Significant bottlenecks (>10 min impact) get deeper analysis
  • Skip only when root cause is immediately obvious to both parties

Example conversational flow:

"The deploy script failed three times before we found the issue.
 Why did it fail? — Missing env var.
 Why was it missing? — The skill doesn't document required vars.
 Why not? — No reference section for environment setup.
 → Fix: Add env requirements to the skill's references/"

Common Patterns

Problem Categories (what to surface in Phase 1):

  • Tasks that took longer than expected
  • Approaches that didn't work on first attempt
  • Unexpected errors or blockers
  • Places where Claude went down the wrong path
  • Missing information that caused rework
  • Tools or skills that didn't behave as expected
  • Repeated manual approvals for the same tool/command (permission whitelist candidates)

Recommendations (focused on skills/commands/agents):

  • Priority: High / Medium / Low
  • Effort: Quick (<30m) / Medium (30-120m) / Complex (>2h)
  • Impact: High / Medium / Low
  • Category: Workflow / Commands / Utilities / Skills / Documentation / Permission Whitelist / User Practices
  • Target: File path in claude-skills repo
  • Implementation: Via PR to claude-skills

Progressive Disclosure

Load operation details on-demand:

Operations:

  • operations/single-session-analysis.md - Interactive retrospective with Five Whys discussion
  • operations/aggregate-patterns.md - Pattern aggregation across historical sessions

Error Handling

No conversation context: Display message "No conversation to analyze."

Obsidian vault not found: Fall back to docs/lessons-learned/ directory

Insufficient data: Create partial report with available data

Analysis fails: Create partial report with completed phases, log errors

Integration Points

  • Task Progress Tracker: Extract task completion metrics
  • Change Analytics: Detect conversation patterns
  • Content Summarizer: Compress analysis into concise insights
  • obsidian-notes skill: Frontmatter standards, tag vocabulary, keyword format (must load before writing)
  • compound skill: Solution doc bridge — Phase 3d creates searchable solution docs for problems with concrete fixes

See Also

  • /obsidian-notes - Note conventions and frontmatter standards (required before writing)
  • /analyze-project - Parallel architecture analysis
  • /create-task - Interactive task definition
  • /status - Current workflow progress
  • /claude-skills:compound - Document solved problems as searchable solution docs (Phase 3d bridge target)
  • /claude-skills:self-improvement - Apply recommendations to skills
  • self-improvement/references/improvement-workflow.md - Complete improvement cycle
  • improvement-loop - Reads this skill's retro artifacts as one of its experience sources and hands actionable findings to self-improvement as PR-gated changes

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.