Self correction loop
Skill Trossitec/dotnet-claude-kit/skills/self-correction-loop
Self-improving correction capture system. After ANY user correction, detect it, generalize the lesson, and store it as a reusable rule in MEMORY.md. Ensures Claude's mistake rate drops over time by compounding corrections into permanent knowledge. Load this skill when a user corrects Claude's output, mentions "remember this", "don't do that again", "learn from mistakes", "update memory", or when starting a new session (to review existing rules).From its SKILL.md
npx -y skills add Trossitec/dotnet-claude-kit --skill self-correction-loopAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
7.3 KB, as published. Nobody here has run it
Self-Correction Loop
Core Principles
-
Every correction is a compounding investment — A correction costs the user 30 seconds today but saves hours across all future sessions. Treat every correction as high-priority knowledge capture, not a one-time fix.
-
Generalize before storing — "Use
TimeProvidernotDateTime.Nowin the Orders module" becomes "Always useTimeProviderinstead ofDateTime.Now/UtcNowacross all modules." Specific corrections become class-level rules. -
Categorize for retrieval — Rules organized by category (Code Style, Architecture, Naming, Testing, Data Access, API Design, Configuration, Performance) are findable. Uncategorized rules are forgotten.
-
Deduplicate aggressively — Before adding a rule, scan existing rules for overlap. Update an existing rule rather than adding a near-duplicate. Memory bloat defeats the purpose.
-
Review memory at session start — The first thing Claude should do in a new session is check
MEMORY.mdfor project-specific rules. Knowledge captured but never reviewed is wasted effort.
Patterns
Correction Detection & Capture Flow
When a user corrects Claude's output, follow this exact sequence:
1. DETECT — User says something like:
- "No, use X instead of Y"
- "We don't do it that way here"
- "That's wrong, it should be..."
- "Always/Never do X in this project"
- "Remember this for next time"
2. ACKNOWLEDGE — Confirm understanding of the correction
"Got it — using HybridCache instead of IMemoryCache."
3. GENERALIZE — Extract the class-level rule
Specific: "Don't use IMemoryCache in the Orders endpoint"
General: "Always use HybridCache instead of IMemoryCache — it provides
stampede protection and L1+L2 caching out of the box."
4. CHECK — Scan MEMORY.md for existing related rules
- If a related rule exists, UPDATE it (broader scope, better wording)
- If no related rule exists, ADD a new one under the right category
5. STORE — Write to MEMORY.md under the appropriate category
6. CONFIRM — Tell the user what was captured
"Added to Memory > Data Access: Always use HybridCache over IMemoryCache."
MEMORY.md Organization Format
Structure memory by category with consistent rule formatting:
# Project Memory
## Code Style
- Always use file-scoped namespaces — never block-scoped
- Use primary constructors for DI injection in services and handlers
## Architecture
- This project uses Vertical Slice Architecture — one file per feature operation
## Data Access
- Always use HybridCache over IMemoryCache — stampede protection + L1/L2
- Never use repository pattern over EF Core — use DbContext directly
## Testing
- Integration tests use ApiFixture base class — never raw WebApplicationFactory
Use categories: Code Style, Architecture, Naming, Data Access, API Design, Testing, Configuration, Performance. Each rule: one line, actionable, with rationale after the dash.
Rule Generalization: Specific to Class
Transform specific corrections into broadly applicable rules:
SPECIFIC CORRECTION:
"Don't use DateTime.Now in the CreateOrder handler"
GENERALIZATION STEPS:
1. Is this specific to CreateOrder? → No, it's a .NET-wide concern
2. Is this specific to handlers? → No, applies everywhere
3. What's the underlying principle? → TimeProvider is testable, DateTime is not
4. What's the broadest correct statement?
GENERALIZED RULE:
"Always use TimeProvider instead of DateTime.Now/UtcNow — TimeProvider is
injectable and testable. This applies to all production code."
Periodic Memory Audit
Every 5-10 sessions (or when memory exceeds 50 rules), audit for quality:
AUDIT CHECKLIST:
1. Remove rules that contradict each other — keep the most recent
2. Merge rules that overlap — combine into a single, clearer rule
3. Remove rules that are now obvious (e.g., captured early but now second nature)
4. Verify rules are still accurate — .NET evolves, patterns change
5. Check that categories are balanced — a category with 20+ rules needs subcategories
Session-Start Memory Review
At session start, read MEMORY.md and apply relevant rules proactively. Do not wait to be reminded of rules that were already captured.
Anti-patterns
Ignoring Corrections
// BAD — user corrects, Claude fixes but doesn't capture
User: "No, we use HybridCache here, not IMemoryCache"
Claude: "Fixed. Here's the updated code with HybridCache..."
*Next session: makes the same mistake*
// GOOD — fix AND capture
User: "No, we use HybridCache here, not IMemoryCache"
Claude: "Fixed. Here's the updated code with HybridCache.
Added to Memory > Data Access: Always use HybridCache over IMemoryCache."
*Next session: checks memory, uses HybridCache from the start*
Overly Specific Rules
// BAD — rule is too narrow to be useful
"In the CreateOrder handler on line 47, use TimeProvider"
// GOOD — generalized to apply broadly
"Always use TimeProvider instead of DateTime.Now/UtcNow in all production code"
Never Reviewing Memory
// BAD — 50 rules captured, none ever reviewed
MEMORY.md grows to 200 lines, contains duplicates and contradictions,
Claude doesn't read it because it's too long to be useful
// GOOD — periodic audit keeps memory lean and accurate
MEMORY.md stays under 80 rules, well-categorized, no duplicates,
Claude reads it at session start and applies rules proactively
Storing Session-Specific Context
// BAD — temporary state saved as permanent memory
"Currently working on the Orders module refactor, file is at src/Orders/Handler.cs"
// GOOD — only permanent, reusable knowledge
"The Orders module uses VSA with one file per feature under Features/"
Decision Guide
| Scenario | Action |
|---|---|
| User explicitly corrects Claude's code | Capture generalized rule in MEMORY.md |
| User says "remember this" or "always/never" | Capture exactly as stated, generalize if possible |
| Same correction given twice | High priority — the rule wasn't captured or wasn't reviewed |
| Correction is project-specific | Store in MEMORY.md with project context |
| Correction is universal .NET | Store in MEMORY.md — it applies to this project |
| MEMORY.md exceeds 50 rules | Trigger an audit — deduplicate, merge, prune |
| Starting a new session | Review MEMORY.md before writing any code |
| Rule contradicts an existing rule | Keep the most recent correction, remove the old one |
| Correction is about a one-time task | Don't store — only capture reusable patterns |
| User asks to forget a rule | Remove it from MEMORY.md immediately |
| Pattern observed but not yet confirmed | Create an instinct via instinct-system skill (confidence 0.3) instead of a MEMORY.md rule |
| Instinct reaches 0.9 confidence | Promote to MEMORY.md as a permanent rule (see instinct-system skill) |