Skill Learning from Correction
Trigger: Use when a user corrects your approach, shows a better way, or points out a mistake — convert that into skill knowledge.
The Correction → Skill Pipeline
User correction or feedback
│
┌────▼──────────────┐
│ Was I using a │
│ skill when this │──YES──► Patch the skill with correction
│ happened? │
└────┬──────────────┘
│ NO
┌────▼──────────────┐
│ Is this a │
│ repeatable │──YES──► Create a new skill
│ procedure? │
└────┬──────────────┘
│ NO
┌────▼──────────────┐
│ Is this a │
│ personal │──YES──► Save to memory, not skill
│ preference? │
└────┬──────────────┘
│ NO
└──► Acknowledge, no action needed
Correction Types
| Type | Example | Action |
|---|---|---|
| Command error | "Use docker compose not docker-compose" |
Patch skill's commands |
| Wrong approach | "We use Helm, not raw k8s YAML" | Patch skill's procedure |
| Missing step | "You need to set up RBAC first" | Add step to skill |
| Wrong tool | "We use PostgreSQL not MySQL" | Add context to skill |
| Order error | "Tests before lint, not after" | Reorder skill steps |
| Pitfall discovered | "That flag is deprecated in v2" | Add pitfall to skill |
| New workflow | "We always add this config after deploy" | Create new skill |
Correction Capture Template
CORRECTION CAPTURE
──────────────────
What I did wrong: <description>
Correct approach: <what user said>
Applies to skill: <skill-name if applicable>
Category: command/approach/step/tool/order/pitfall
Action taken: patched/created/noted/saved to memory
---
Example: Patching a Skill from Correction
CONTEXT:
- User asked me to deploy a Node.js app
- I used docker-compose-patterns skill
- User: "We use `docker compose` v2, not docker-compose"
ACTION:
skill_manage(
action="patch",
name="docker-compose-patterns",
old_string="docker-compose up -d",
new_string="docker compose up -d"
)
Also check for all other `docker-compose` references in the skill
and update them — the old CLI is deprecated across the board.
Example: Creating a Skill from Correction
CONTEXT:
- User corrected me on their team's deploy process 3 times
- Process: feature branch → staging → QA → prod
- Has 6 clear steps with approval gates
ACTION:
Propose: "I notice I've been corrected on the deployment process
a few times. Should I create a 'team-deploy-process' skill so I
get it right every time?"
When to Save to Memory vs. Skill
SAVE TO MEMORY (not skill):
- User preference ("I prefer tabs not spaces")
- Personal details ("I use Chrome not Firefox")
- One-off context ("This project uses port 8080")
SAVE AS SKILL:
- Repeatable procedures (5+ steps, reusable)
- Technical workflows (deploy, migrate, configure)
- Domain knowledge (API endpoints, tool-specific commands)
Memory = small durable facts
Skill = longer procedures loaded on demand
Pitfalls
- Over-correction: Not every correction needs a skill update — one-off context goes in memory
- Premature patching: Patching a skill mid-task when the issue might be specific to this context
- Confirmation required: Don't silently patch skills — confirm with user or use write_approval gate
- Skill scope expansion: Patching "fix a bug in Python" with deployment info makes the skill unfocused
Verification
After a correction-led update:
- Does the skill now reflect the correct approach?
- Did I check all instances of the old pattern (not just the first)?
- Should I inform the user that the skill was updated?