netanel-abergel Self-Learning
Use this skill to turn corrections and failures into concrete local improvements.
Scope
Default storage is:
.learnings/LEARNINGS.mdfor reusable lessons.learnings/ERRORS.mdfor failures and breakages.learnings/FEATURE_REQUESTS.mdfor missing capabilities
Prefer updating the specific local skill or workflow that caused the issue. Do not change core identity/bootstrap files unless the owner explicitly asks for that level of system change.
Immediate loop
- Log the event before closing the task.
- State the root cause in one sentence.
- Apply the smallest durable fix you can make now.
- If no concrete fix is possible, say why and what evidence would unblock it.
When to log
| Trigger | File | Category |
|---|---|---|
| Owner correction | LEARNINGS.md |
correction |
| Task failure | ERRORS.md |
failure |
| Skill produced bad output | ERRORS.md |
skill_failure |
| Better approach discovered | LEARNINGS.md |
best_practice |
| Missing capability | FEATURE_REQUESTS.md |
feature_request |
| Repeated mistake | LEARNINGS.md |
pattern |
| Good result worth repeating | LEARNINGS.md |
positive_signal |
Entry format
## YYYY-MM-DD | category | short title
- Trigger: what happened
- Context: what you were trying to do
- Root cause: why it happened
- Durable fix: file/process/skill you changed, or `none yet`
- Verification: how to tell the problem is gone
Promotion rules
Promote a learning when it is specific and repeatable.
- If the issue belongs to one skill, update that skill's
SKILL.md. - If the issue belongs to a reusable local workflow, update the nearest local checklist/script.
- If the issue depends on missing credentials, external systems, or policy decisions, log it and stop. Do not invent a fake fix.
Pattern review
During reflection or cleanup work:
- Scan
.learnings/for repeated categories or titles. - Group duplicates.
- Make one concrete change per pattern.
- Add a short verification note to the newest entry.
Quality bar
A learning is only complete when at least one of these is true:
- a local skill was improved
- a broken instruction was removed
- a missing prerequisite was documented clearly
- a recurring mistake was converted into a shorter, safer workflow
Not enough:
- "be more careful"
- generic promises
- long postmortems without a file or process change
Skill Failure Tracking (inspired by agentic-stack)
Track when a skill fails or produces bad output. After a threshold, flag it for review.
How to track
When a skill fails or gives wrong results, log it in .learnings/ERRORS.md with category skill_failure:
## YYYY-MM-DD | skill_failure | <skill-name>: short description
- Trigger: what the user asked
- Skill: <skill-name>
- Root cause: why the skill failed
- Durable fix: what was changed, or `none yet`
Auto-flag threshold
During pattern review, count skill_failure entries per skill in the last 14 days:
- 3+ failures in 14 days → flag the skill for rewrite/review
- Add a
## FLAGGED FOR REVIEWsection at the top of that skill's SKILL.md - Notify owner in the next daily summary: "Skill X failed 3+ times in 2 weeks, flagged for review"
Resolution
- Fix the skill → remove the FLAGGED section
- If the skill is unfixable → document the limitation and stop routing to it for those cases
Weekly Retro (inspired by gstack /retro)
Every Sunday (or when owner asks "what did we ship"), generate a structured weekly retrospective:
Data Sources
- Git log from workspace repo (last 7 days)
.learnings/entries from the week- Daily memory notes (
memory/daily/) - Cron execution history
Retro Format
## Weekly Retro — YYYY-MM-DD
### Shipped
- [commit/action]: what was delivered
### Patterns
- Recurring issues or wins from the week
### Learnings Applied
- Which learnings led to concrete skill/workflow changes
### Failures
- What broke, root cause, fix status
### Next Week
- Top 3 priorities based on patterns
Trend Tracking
Store retros in memory/retros/YYYY-WXX.md (e.g., 2026-W16.md).
Compare with previous week's retro when generating:
- Are the same issues recurring? Flag them.
- Did last week's priorities get addressed?
- Is failure count trending up or down?
Cron Setup
Add as a Sunday cron (low-cost model, ~60s):
Schedule: 0 10 * * 0 Asia/Jerusalem
Model: haiku
Prompt: "Run weekly retro. Check git log, learnings, daily notes from past 7 days. Write retro to memory/retros/. DM summary to owner."
Cost tips
- Use short factual entries.
- Batch pattern review; do not re-scan logs after every single correction.
- Prefer editing one skill precisely over writing large reflective notes.