continuous-improvement-protocol-l-gevity.md

name	description
Continuous Improvement Protocol	Protocol for updating skills based on user feedback and root-cause analysis to prevent recurring mistakes.

L-GEVITY Continuous Improvement Protocol (Meta-Learning)

This protocol governs the agent's meta-learning process. It does not contain specific coding standards, architectural rules, or framework guidelines. Instead, it defines how and when to update other skills (like architecture-guidelines or coding-standard) based on new learnings.

0. Reasoning Chain (Mental Models)

Execute these phases during complex feature design or debugging:

• Phase 1: Foundation (Ground Truth)
  • First Principles: Rebuild from biological/mathematical truth (e.g., Gompertz Law).
  • Socratic Questioning: Challenge every claim with "Why?" and "How do we know?".
• Phase 2: Synthesis (The Solution)
  • Analogical Reasoning: Apply patterns from other domains (e.g., J-curve/Athlete phenotypes).
  • Constraint Removal: Briefly imagine the "perfect" solution without legacy debt.
• Phase 3: Validation (The Stress Test)
  • Inversion: Ask "How do I guarantee systemic failure?" then avoid it.
  • Pre-mortem: Assume the fix already failed; work backward to find the oversight.
  • Red Team vs Blue Team: Attack your own implementation to find edge cases.

1. Triggers for Learning

Initiate this protocol to examine and update existing SKILL.md files when:

• User Correction: User explicitly corrects a pattern, approach, or rule.
• Regression: A fix for one issue breaks another (indicating a missing rule about system boundaries).
• New Pattern Established: A new architectural pattern is introduced and validated.
• Systematic Failure: You notice the same type of error, anti-pattern, or fragile workaround happening multiple times.
• Pipeline/Automation Break: Recurring CI/CD failures or linter bottlenecks indicating a process flaw.

2. Analyze Root Cause

Determine the underlying reason:

• Missing/Ambiguous: Requirement not documented or misinterpretable?
• Conflict: Rules contradict each other?
• Ignored Rule: Clear but not followed? Strengthen wording or promote to Critical.
• Technical Constraint: Misunderstood framework behavior?

3. Update Skills

Update or create the relevant SKILL.md:

• Minimalist Wording: Rules MUST be short. Use bullet points and code snippets; avoid paragraphs.
• Shrink, Don't Grow: Refactor existing rules to be more concise when adding new ones. A SKILL should become denser and sharper, not longer. If a SKILL file grows too large, extract subsets or aggressively prune.
• Anti-patterns: Include what not to do if rules are insufficiently clear.
• Zero Redundancy: Keep minimal overlap; never duplicate rules across files.
• Code > Docs: Before adding a rule, ask: "Can this be a Test or a Linter Rule?" Prioritize automated guardrails over manual instructions.
• Actionable: Ensure new rules are testable and don't conflict with existing ones.

4. Verify & Notify

Ensure the learning "sticks":

• Verification: Add a test case or perform a code audit that proves the previous mistake is now caught or impossible.
• Notify: Conclude with a concise summary:

  "Updated [Skill/Test] to prevent [issue] by mandating [new practice]."