Self-Correction Loop

SkillDocs & knowledge

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 Codex's mistake rate drops over time by compounding corrections into permanent knowledge. Load this skill when a user corrects Codex'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).

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Self-Correction Loop skill

What this skill tells your AI

The instructions your AI receives, as published by resgrid/core in .agents/skills/self-correction-loop/SKILL.md and read by ahel’s review.

Core Principles

  1. 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.

  2. Generalize before storing — "Use TimeProvider not DateTime.Now in the Orders module" becomes "Always use TimeProvider instead of DateTime.Now/UtcNow across all modules." Specific corrections become class-level rules.

  3. Categorize for retrieval — Rules organized by category (Code Style, Architecture, Naming, Testing, Data Access, API Design, Configuration, Performance) are findable. Uncategorized rules are forgotten.

  4. 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.

  5. Review memory at session start — The first thing Codex should do in a new session is check MEMORY.md for project-specific rules. Knowledge captured but never reviewed is wasted effort.

Patterns

Correction Detection & Capture Flow

When a user corrects Codex'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, Codex fixes but doesn't capture
User: "No, we use HybridCache here, not IMemoryCache"
Codex: "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"
Codex: "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,
Codex 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,
Codex 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

ScenarioAction
User explicitly corrects Codex's codeCapture generalized rule in MEMORY.md
User says "remember this" or "always/never"Capture exactly as stated, generalize if possible
Same correction given twiceHigh priority — the rule wasn't captured or wasn't reviewed
Correction is project-specificStore in MEMORY.md with project context
Correction is universal .NETStore in MEMORY.md — it applies to this project
MEMORY.md exceeds 50 rulesTrigger an audit — deduplicate, merge, prune
Starting a new sessionReview MEMORY.md before writing any code
Rule contradicts an existing ruleKeep the most recent correction, remove the old one
Correction is about a one-time taskDon't store — only capture reusable patterns
User asks to forget a ruleRemove it from MEMORY.md immediately
Pattern observed but not yet confirmedCreate an instinct via instinct-system skill (confidence 0.3) instead of a MEMORY.md rule
Instinct reaches 0.9 confidencePromote to MEMORY.md as a permanent rule (see instinct-system skill)

Signals

GitHub stars
226
Forks
86
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
self-correction-loop
Source
github.com/resgrid/core