auto-improvement（自动改进）

Overview

The auto-improvement skill implements a self-improving feedback loop that tracks effectiveness metrics, learns from errors, identifies recurring failure patterns, and adapts workflows to prevent repeated mistakes. It enables the agent to become measurably better over time through structured self-assessment rather than ad-hoc adjustments. Without this skill, the same mistakes repeat across sessions — with it, every error becomes a permanent improvement.

This skill is ALWAYS active. It runs automatically on every session and cannot be disabled.

Phase 1: Metric Collection

At the start of every task, instrument key decision points:

1. Record task start time and initial estimate
2. Define expected outcome and success criteria
3. Track each decision point (approach chosen, alternatives considered)
4. Log revision count (how many times the output was revised)
5. Track user corrections as improvement signals

Core Metrics

Tracking Template

## Session Metrics -- [Date]

### Tasks
| Task | Estimated | Actual | Revisions | Success | Error Type |
|------|-----------|--------|-----------|---------|------------|
| ...  | 30m       | 45m    | 1         | Partial | Execution  |

### Summary
- Tasks completed: X
- First-attempt success: X/Y (Z%)
- Total revisions: N
- Errors by category: Comprehension(n), Execution(n), Process(n)
- Improvement actions taken: [list]

STOP: Complete metric collection setup before proceeding to error analysis. Do NOT skip instrumentation.

Phase 2: Error Analysis

When an error occurs, classify it immediately using the taxonomy:

Error Taxonomy

Severity Levels

Error Log Format

## Error Log Entry

**ID:** ERR-[YYYY]-[MMDD]-[NNN]
**Date:** [date]
**Task:** [what was being done]
**Severity:** [Critical / Major / Minor / Cosmetic]
**Category:** [Category > Subcategory]

### What Happened
[Description of the error and its observable impact]

### Root Cause
[Why this error occurred — the actual underlying reason]

### What Was Tried
1. [First attempt to resolve]
2. [Second attempt if applicable]
3. [Final resolution]

### Resolution
[What ultimately fixed the problem]

### Time Lost
[Estimated time wasted due to this error]

### Prevention
- **New checklist item:** [if applicable]
- **Memory update:** [what was persisted]
- **Guardrail added:** [if applicable]

### Recurrence Check
- [ ] Similar error seen before? [Yes/No — reference previous ID]
- [ ] Guardrail added? [Yes/No]

STOP: Every error MUST be classified and logged before proceeding to fix it. Do NOT skip the log entry.

Phase 3: Pattern Recognition

After accumulating 3+ errors, analyze for patterns:

1. Group related errors into failure categories
2. Identify environmental triggers (specific file types, frameworks, patterns)
3. Detect workflow bottlenecks causing consistent slowdowns
4. Recognize successful patterns worth reinforcing
5. Map anti-patterns to their corrective actions

Pattern Detection Decision Table

Positive Pattern Reinforcement

When a pattern consistently leads to success, document it:

## Positive Pattern: [Name]
OBSERVATION: [What was done and why it worked]
EVIDENCE: [Sessions/tasks where this pattern succeeded, with success rate]
REINFORCEMENT: [How to ensure this pattern continues to be applied]

STOP: Pattern recognition must be evidence-based. Do NOT create patterns from single occurrences.

Phase 4: Adaptation

Generate and implement improvements based on identified patterns:

Pre-Flight Checklists

Create checklists that run before high-risk operations:

## Pre-Flight: Before Writing [Framework] Code
- [ ] Identify the framework and version (check package.json / composer.json)
- [ ] Identify the routing pattern (pages/ vs app/, file-based vs code-based)
- [ ] Check for existing patterns in the codebase (find similar files)
- [ ] Verify the API surface in documentation (do not assume from memory)
- [ ] Check for project-specific conventions (linter config, type config)

Guardrail Rules

## Guardrail: [Operation Type]
BEFORE [specific operation]:
1. [Check 1]
2. [Check 2]
3. [Check 3]
4. [Check 4]

TRIGGERED BY: [keywords or conditions that activate this guardrail]
ADDED BECAUSE: [Error ID that caused this guardrail to be created]
EFFECTIVENESS: [Track whether this guardrail has prevented errors]

Adaptation Decision Table

STOP: Every adaptation must be validated against historical data before being persisted.

Phase 5: Feedback Loop and Validation

Measure whether improvements actually work:

1. Compare current error rates against baseline (pre-improvement)
2. Track each guardrail's prevention count
3. Archive improvements that demonstrably reduce errors
4. Revert improvements that do not reduce errors or add overhead
5. Share learnings across sessions via memory files

Retrospective Template

## Retrospective -- [Period]

### What Went Well
- [Pattern/approach that consistently succeeded]
- [New technique that improved outcomes]

### What Went Poorly
- [Recurring error pattern with frequency]
- [Process gap that caused rework]

### Error Trends
| Category | This Period | Last Period | Trend |
|----------|------------ |-------------|-------|
| Comprehension | 3 | 5 | Improving |
| Execution | 7 | 4 | Worsening -- investigate |
| Process | 1 | 3 | Improving |
| Knowledge | 4 | 4 | Stable |

### Root Cause Analysis (Top 3 Errors)
1. **[Error pattern]** -- Root cause: [analysis] -- Fix: [action]
2. **[Error pattern]** -- Root cause: [analysis] -- Fix: [action]
3. **[Error pattern]** -- Root cause: [analysis] -- Fix: [action]

### Improvement Actions
| Action | Priority | Status | Expected Impact | Actual Impact |
|--------|----------|--------|-----------------|---------------|
| Add pre-flight check for X | High | Done | -30% execution errors | [measured] |
| Update memory with Y pattern | Medium | Done | -20% knowledge errors | [measured] |
| Create guardrail for Z | High | In Progress | Prevent critical error class | [pending] |

### Metrics vs. Targets
| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| First-attempt success | >80% | 75% | Below target |
| Revision count | <1.5 | 1.8 | Below target |
| Error recurrence | <10% | 8% | On target |

Memory File Integration

What to Persist

Update Protocol

1. Identify the learning from the error or success
2. Check if it conflicts with existing memory entries
3. If conflict: update the existing entry with new information and date
4. If new: add entry with context, evidence, and date
5. Remove entries that are no longer valid (tech changed, project evolved)

Do NOT persist gut feelings as patterns. Evidence required: 2+ occurrences minimum.

Continuous Improvement Cycle

Execute Tasks -> Collect Metrics -> Analyze Errors -> Identify Patterns
      ^                                                       |
      |                                                       v
      +-- Persist to Memory <-- Validate Impact <-- Implement Improvements
                                      |
                                      +-- Did not work? -> Revert, try different approach

Anti-Patterns / Common Mistakes

Anti-Rationalization Guards

Do NOT skip error logging. Do NOT skip metric collection. These are mandatory.

Integration Points

Concrete Examples

Guardrail Created from Error Pattern

Error: ERR-2026-0212-003 — Dropped production table during migration
Error: ERR-2026-0301-007 — Applied migration without rollback plan

Pattern: Database operations without safety checks (2 occurrences)

Guardrail Created:
## Guardrail: Database Operations
BEFORE any database migration or schema change:
1. Check if there is an existing migration framework
2. Verify the current schema state
3. Create a rollback plan
4. Test migration on a copy first

TRIGGERED BY: any task involving database, schema, migration, model
ADDED BECAUSE: ERR-2026-0212-003, ERR-2026-0301-007
EFFECTIVENESS: 0 errors in 5 subsequent database tasks

Positive Pattern Documentation

## Positive Pattern: Context Discovery First
OBSERVATION: Tasks where project context was gathered first had
a 92% first-attempt success rate vs. 64% without.
EVIDENCE: Sessions 2026-02-01 through 2026-03-15 (47 tasks)
REINFORCEMENT: Always run context discovery before implementation.
Minimum: check package.json, read existing code in same domain,
identify conventions.

Skill Type

RIGID — Error tracking, classification, and the improvement cycle must be followed consistently. Every recurring error (2+ occurrences) must result in a concrete preventive action. Memory files must be updated with evidence-based patterns only. Metric collection and error logging are mandatory on every session. Do not skip retrospectives.