Learning from mistakes
Skill syahiidkamil/Software-Engineer-AI-Agent-Atlas/.claude/skills/learning-from-mistakes
ATLAS: a senior-engineer layer for Claude Code. Explore with wireframes & prototypes, clarify the essentials, capture it in HTML spec doc then let Claude Code's native plan/goal/workflow loop build. Fewer tokens, less ceremony, faster to what people pictured. KISS/YAGNI/DRY, context decides. No overengineering. Clean architecture that works.
npx -y skills add syahiidkamil/Software-Engineer-AI-Agent-Atlas --skill learning-from-mistakesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
What its author says it does
Copied from the file, not written here
Record a hard-won engineering lesson after a bug or mistake is resolved. Use when a bug resisted ATLAS until Boss's guidance cracked it, or when a long debugging hunt ended in an aha moment worth never relearning.
SKILL.md
1.9 KB, as published. Nobody here has run it
Capture the lesson so future-ATLAS does not pay the same debugging cost twice.
When to write an entry
Write one — without being asked — when either is true:
- Boss had to step in. A bug or mistake ATLAS could not solve alone; Boss's guidance is what cracked it.
- Aha moment after a long hunt. A debugging session that ran long and ended in a non-obvious realization.
Skip routine fixes. The bar is surprise: would this genuinely save someone — likely future-ATLAS — from a hard time? If the cause was obvious in hindsight to anyone, it is not worth an entry. Apply the same high-entropy filter as NOTES.md: record what is surprising, not what is expected.
Where
One file per lesson: docs/learning-from-mistakes/<kebab-case-slug>.md. The slug names the problem, so the folder is self-indexing — e.g. stale-closure-in-useeffect.md, timezone-off-by-one-on-date-parse.md.
Format
Keep it brief — important information only. Four short sections:
# <Lesson title — the problem in one line>
**Date**: YYYY-MM-DD · **Area**: <project / module / domain>
## Symptom
What looked wrong — the observable behavior or the assumption that failed.
## Root cause
The non-obvious truth. Why it actually happened.
## Resolution
The fix, or the insight that cracked it. Credit Boss's guidance if that is what unblocked it.
## Lesson
The transferable rule — how to recognize or avoid this next time.
A few tight sentences per section beats a padded template. If a section adds nothing, drop it.
Recall
Before concluding a hard bug is unsolvable, scan docs/learning-from-mistakes/ — a past lesson may already name the cause.