vt-c-continuous-learning¶
Close the feedback loop so the system learns from every bug and gets smarter over time. Consults past solutions before investigating, auto-detects patterns, and ensures institutional knowledge informs all future work.
Plugin: core-standards
Category: Knowledge Capture
Command: /vt-c-continuous-learning
Continuous Learning Skill¶
Purpose: Ensure the system gets smarter with every bug fixed. Past solutions should inform future work automatically - not just when someone remembers to search.
The Feedback Loop¶
┌─────────────────────────────────────────────────────────┐
│ NEW BUG REPORTED │
└─────────────────────────────┬───────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ STEP 0: CONSULT PAST SOLUTIONS (THIS SKILL) │
│ 1. Search docs/solutions/ for similar symptoms │
│ 2. Check critical-patterns.md │
│ 3. Search session journal for related learnings │
│ 4. If match found → "Apply this solution?" │
└─────────────────────────────┬───────────────────────────┘
│
┌───────────────┴───────────────┐
│ │
▼ ▼
┌────────────────┐ ┌────────────────┐
│ MATCH FOUND │ │ NO MATCH │
│ Apply solution │ │ Investigate │
└────────────────┘ └───────┬────────┘
│
▼
┌─────────────────────────────┐
│ FIX BUG (bugfix-orchestrator)│
└───────────────┬─────────────┘
│
▼
┌─────────────────────────────┐
│ DOCUMENT (compound-docs) │
│ - Root cause │
│ - Solution │
│ - Prevention │
└───────────────┬─────────────┘
│
▼
┌─────────────────────────────┐
│ PATTERN DETECTION │
│ 3+ similar bugs? → Promote │
│ to Required Reading │
└───────────────┬─────────────┘
│
▼
┌─────────────────────────────┐
│ FUTURE BUGS BENEFIT │
│ System already knows answer │
└─────────────────────────────┘
Step 0: Consult Past Solutions¶
CRITICAL: Run this BEFORE investigating any bug.
Implementation¶
### Before investigating ANY bug:
1. **Extract search terms from bug report:**
- Error messages (exact text)
- Symptom description
- Affected component/module
- Stack trace patterns
2. **Search docs/solutions/:**
```bash
# Search by error message
grep -r "exact error text" docs/solutions/
# Search by symptom category
ls docs/solutions/[category]/
# Search by component
grep -r "component: ComponentName" docs/solutions/
```
3. **Check critical-patterns.md:**
```bash
# Load required reading
cat docs/solutions/patterns/critical-patterns.md
```
4. **Search session journal:**
```bash
grep -r "related keyword" docs/vt-c-journal/
```
5. **Present findings:**
```
Found N similar past issues:
1. [Issue Title] (docs/solutions/category/filename.md)
- Symptom: [symptom]
- Root cause: [cause]
- Solution: [solution]
- Similarity: 85%
Options:
[1] Apply this solution (skip investigation)
[2] Review but continue investigation
[3] Different issue - proceed with investigation
```
Similarity Scoring¶
**High similarity (>70%) - Suggest applying:**
- Same error message
- Same component
- Same symptom pattern
**Medium similarity (40-70%) - Review recommended:**
- Similar error type
- Related component
- Partial symptom match
**Low similarity (<40%) - FYI only:**
- Same category
- Tangentially related
Pattern Auto-Detection¶
When to Promote to Required Reading¶
Automatically suggest promotion when: - 3+ bugs share same root_cause type - Same mistake made in different modules - Same symptom appears repeatedly - Non-obvious solution that's easy to miss
Detection Algorithm¶
1. After documenting a bug fix, scan recent solutions:
```bash
# Find solutions in last 30 days
find docs/solutions/ -mtime -30 -name "*.md" -exec grep -l "root_cause:" {} \;
```
2. Group by root_cause type:
```yaml
missing_include: 5 occurrences
null_check: 3 occurrences
race_condition: 2 occurrences
```
3. If any type has 3+ occurrences:
```
Pattern detected: "missing_include" appears in 5 bugs
Bugs:
- Brief generation N+1 (2024-01-15)
- Email thread loading (2024-01-18)
- User preferences (2024-01-20)
- Report generation (2024-01-22)
- Dashboard widgets (2024-01-25)
Suggest promotion to Required Reading?
[1] Yes - Add to critical-patterns.md
[2] No - These are different issues
[3] Review details first
```
Required Reading Format¶
# Critical Pattern: [Pattern Name]
## Pattern ID: CP-[NNN]
## The Mistake
[Description of what goes wrong]
## ❌ WRONG
```code
// Code that causes the problem
✅ CORRECT¶
Why This Matters¶
[Technical explanation]
Detection¶
How to spot this in code review: - [Signal 1] - [Signal 2]
Related Solutions¶
- [Link to solution 1]
- [Link to solution 2]
- [Link to solution 3]
--- ## Required Reading Protocol ### All Orchestrators Must Load Add to every orchestrator's Step 0: ```markdown ### Step 0: Load Institutional Knowledge **BEFORE starting any work:** 1. Check for critical patterns file: ```bash if [ -f "docs/solutions/patterns/critical-patterns.md" ]; then # Load and internalize all patterns fi ``` 2. Apply patterns during work: - Flag code that matches ❌ WRONG patterns - Suggest ✅ CORRECT alternatives - Reference pattern ID in feedback 3. For bug investigations: - Search docs/solutions/ for similar issues - Check if bug matches known pattern - If match → suggest documented solution
Orchestrator Integration¶
| Orchestrator | How to Apply Patterns |
|---|---|
| bugfix-orchestrator | Search past bugs BEFORE investigating |
| implementation-orchestrator | Check patterns BEFORE writing code |
| conceptual-orchestrator | Reference past decisions in planning |
| finalization-orchestrator | Check past deployment issues |
Learning Metrics¶
Track Effectiveness¶
## Learning Metrics (Updated Monthly)
### Bugs Prevented by Pattern Recognition
| Month | Bugs Caught by Patterns | Time Saved |
|-------|------------------------|------------|
| Jan | 5 | ~8 hours |
| Feb | 12 | ~18 hours |
### Pattern Utilization
| Pattern | Times Applied | Last Used |
|---------|--------------|-----------|
| CP-001: Missing includes | 8 | 2024-01-25 |
| CP-002: Null checks | 5 | 2024-01-20 |
### Knowledge Base Growth
| Metric | Count |
|--------|-------|
| Total solutions documented | 45 |
| Critical patterns | 12 |
| Journal entries | 89 |
### Recurring Issues (Need Attention)
Patterns that keep appearing despite documentation:
- [ ] N+1 queries (7 occurrences) - Need better tooling?
- [ ] Missing input validation (4 occurrences) - Add to linter?
Integration Points¶
With compound-docs¶
After documenting a solution: 1. compound-docs captures the fix 2. This skill checks for pattern emergence 3. If pattern detected → prompt for Required Reading promotion
With session-journal¶
When searching for context: 1. Search docs/solutions/ for bugs 2. Also search docs/vt-c-journal/ for decisions/learnings 3. Combine insights for fuller picture
With session-consolidator¶
On task completion: 1. session-consolidator synthesizes journal entries 2. This skill checks if any learnings should become patterns 3. Update critical-patterns.md if applicable
Commands¶
/learn-search <query>¶
Search past solutions and learnings:
/learn-search "N+1 query"
Found 3 solutions:
1. Brief generation N+1 (docs/solutions/performance-issues/...)
2. Email thread loading (docs/solutions/performance-issues/...)
3. User preferences query (docs/solutions/performance-issues/...)
Found 2 journal entries:
1. 2024-01-15: Learning about eager loading patterns
2. 2024-01-20: Decision to use bullet gem
/learn-patterns¶
Show all critical patterns:
/learn-patterns
12 Critical Patterns:
CP-001: Missing includes (8 applications)
CP-002: Null safety checks (5 applications)
CP-003: Race condition in async (4 applications)
...
/learn-promote¶
Manually promote a solution to Required Reading:
/learn-promote docs/solutions/performance-issues/n-plus-one.md
Promoting to Required Reading...
- Extracting pattern
- Generating WRONG vs CORRECT examples
- Adding to critical-patterns.md
✓ Added as CP-013: N+1 Query Prevention
Directory Structure¶
docs/
├── solutions/
│ ├── performance-issues/
│ │ ├── n-plus-one-briefs.md
│ │ └── slow-dashboard.md
│ ├── configuration-issues/
│ ├── runtime-errors/
│ └── patterns/
│ ├── critical-patterns.md ← Required Reading
│ └── common-solutions.md ← Less critical patterns
├── journal/
│ ├── 2024-01/
│ │ └── entries/
│ └── consolidations/
└── learning-metrics.md ← Track effectiveness
Success Criteria¶
The learning loop is working when:
- [ ] Before investigating bugs, past solutions are automatically searched
- [ ] Pattern detection surfaces when 3+ similar bugs occur
- [ ] Required Reading is loaded by all orchestrators
- [ ] Time to resolution decreases for known issue types
- [ ] Recurring bugs are identified and escalated
- [ ] Monthly metrics show knowledge base growth and utilization