lesson-learned-175401 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited lesson-learned-175401 (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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 |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.