// Analyze recent code changes via git history and extract software engineering lessons. Use when the user asks 'what is the lesson here?', 'what can I learn from this?', 'engineering takeaway', 'what did I just learn?', 'reflect on this code', or wants to extract principles from recent work.
| name | lesson-learned |
| description | Analyze recent code changes via git history and extract software engineering lessons. Use when the user asks 'what is the lesson here?', 'what can I learn from this?', 'engineering takeaway', 'what did I just learn?', 'reflect on this code', or wants to extract principles from recent work. |
Extract specific, grounded software engineering lessons from actual code changes. Not a lecture -- a mirror. Show the user what their code already demonstrates.
Load the principles reference first.
references/se-principles.md to have the principle catalog availablereferences/anti-patterns.md if you suspect the changes include areas for improvementDo not proceed until you've loaded at least se-principles.md.
Ask the user or infer from context what to analyze.
| Scope | Git Commands | When to Use |
|---|---|---|
| Feature branch | git log main..HEAD --oneline + git diff main...HEAD | User is on a non-main branch (default) |
| Last N commits | git log --oneline -N + git diff HEAD~N..HEAD | User specifies a range, or on main (default N=5) |
| Specific commit | git show <sha> | User references a specific commit |
| Working changes | git diff + git diff --cached | User says "what about these changes?" before committing |
Default behavior:
git log with the determined scope to get the commit list and messagesgit diff for the full diff of the scopegit diff --stat first, then selectively read the top 3-5 most-changed filesIdentify the dominant pattern -- the single most instructive thing about these changes.
Look for:
Map findings to specific principles from references/se-principles.md. Be specific -- quote actual code, reference actual file names and line changes.
Use this template:
## Lesson: [Principle Name]
**What happened in the code:**
[2-3 sentences describing the specific change, referencing files and commits]
**The principle at work:**
[1-2 sentences explaining the SE principle]
**Why it matters:**
[1-2 sentences on the practical consequence -- what would go wrong without this, or what goes right because of it]
**Takeaway for next time:**
[One concrete, actionable sentence the user can apply to future work]
If there is a second lesson worth noting (maximum 2 additional):
---
### Also worth noting: [Principle Name]
**In the code:** [1 sentence]
**The principle:** [1 sentence]
**Takeaway:** [1 sentence]
| Avoid | Why | Instead |
|---|---|---|
| Listing every principle that vaguely applies | Overwhelming and generic | Pick the 1-2 most relevant |
| Analyzing files that were not changed | Scope creep | Stick to the diff |
| Ignoring commit messages | They contain intent that diffs miss | Read them as primary context |
| Abstract advice disconnected from the code | Not actionable | Always reference specific files/lines |
| Negative-only feedback | Demoralizing | Lead with what works, then suggest improvements |
| More than 3 lessons | Dilutes the insight | One well-grounded lesson beats seven vague ones |
Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.
Comprehensive guide for creating software diagrams using Mermaid syntax. Use when users need to create, visualize, or document software through diagrams including class diagrams (domain modeling, object-oriented design), sequence diagrams (application flows, API interactions, code execution), flowcharts (processes, algorithms, user journeys), entity relationship diagrams (database schemas), C4 architecture diagrams (system context, containers, components), state diagrams, git graphs, pie charts, gantt charts, or any other diagram type. Triggers include requests to "diagram", "visualize", "model", "map out", "show the flow", or when explaining system architecture, database design, code structure, or user/application flows.
Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
Manual-only skill for minimizing total codebase size. Only activate when explicitly requested by user. Measures success by final code amount, not effort. Bias toward deletion.
Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.
Creates detailed, sectionized implementation plans through research, stakeholder interviews, and multi-LLM review. Use when planning features that need thorough pre-implementation analysis.