From qe-framework
Analyzes recent code changes via git history and extracts evidence-based software engineering lessons. Useful for retrospectives, key takeaways, or learning from your own code.
How this skill is triggered — by the user, by Claude, or both
Slash command
/qe-framework:Qlesson-learnedThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Extracts concrete, evidence-based software engineering lessons from actual code changes. This is a mirror, not a lecture — it simply reflects what the user's own code already shows.
Extracts concrete, evidence-based software engineering lessons from actual code changes. This is a mirror, not a lecture — it simply reflects what the user's own code already shows.
First, load the reference materials.
references/se-principles.md to understand the list of principlesreferences/anti-patterns.mdDo not proceed until se-principles.md is loaded.
Ask the user or infer from context to identify what to analyze.
| Scope | Git Command | When to Use |
|---|---|---|
| Feature branch | git log main..HEAD --oneline + git diff main...HEAD | When on a non-main branch (default) |
| Last N commits | git log --oneline -N + git diff HEAD~N..HEAD | When a range is specified or when on main (default N=5) |
| Specific commit | git show <sha> | When a specific commit is mentioned |
| Working changes | git diff + git diff --cached | When the user asks "what about these changes?" before committing |
Default behavior:
git log for the determined scope to get the commit list and messagesgit diffgit diff --stat for an overview, then selectively read the top 3–5 files with the most changesIdentify the key pattern — the single thing in these changes that teaches the most.
Things to look for:
Connect findings to the principles in references/se-principles.md. Be specific — quote actual code, reference actual filenames and changed lines.
Use the template below:
## Lesson: [Principle Name]
**What happened in the code:**
[2–3 sentences describing the specific change, referencing the file and commit]
**The principle at work:**
[1–2 sentences explaining the software engineering principle]
**Why it matters:**
[1–2 sentences on what goes wrong without it, or what works well because of it]
**Application point for next time:**
[One specific, actionable sentence the user can apply to future work]
For any additional lessons worth mentioning (up to 2):
---
### Also Worth Noting: [Principle Name]
**In the code:** [One sentence]
**Principle:** [One sentence]
**Application point:** [One sentence]
| Avoid | Why | Do Instead |
|---|---|---|
| Listing all vaguely related principles | Overwhelming and abstract | Pick only the 1–2 most relevant |
| Analyzing files that were not changed | Out of scope | Cover only what appears in the diff |
| Ignoring commit messages | They contain intent | Treat commit messages as primary context |
| Abstract advice disconnected from the code | Not actionable | Always reference a specific file/line |
| Giving only negative feedback | Discouraging | Lead with what went well, then suggest improvements |
| Presenting 3+ lessons | Dilutes insight | One well-grounded lesson beats seven vague ones |
npx claudepluginhub inho-team/qe-framework --plugin qe-frameworkCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.