source-command-learn-eval
Use this skill when the user asks to run the migrated source command learn-eval.
Command Template
/learn-eval - Extract, Evaluate, then Save
Extends /learn with a quality gate, save-location decision, and knowledge-placement awareness before writing any skill file.
What to Extract
Look for:
- Error Resolution Patterns — root cause + fix + reusability
- Debugging Techniques — non-obvious steps, tool combinations
- Workarounds — library quirks, API limitations, version-specific fixes
- Project-Specific Patterns — conventions, architecture decisions, integration patterns
Process
Review the session for extractable patterns
Identify the most valuable/reusable insight
Determine save location:
- Ask: "Would this pattern be useful in a different project?"
- Global (
~/.Codex/skills/learned/): Generic patterns usable across 2+ projects (bash compatibility, LLM API behavior, debugging techniques, etc.)
- Project (
.Codex/skills/learned/ in current project): Project-specific knowledge (quirks of a particular config file, project-specific architecture decisions, etc.)
- When in doubt, choose Global (moving Global → Project is easier than the reverse)
Draft the skill file using this format:
---
name: pattern-name
description: "Under 130 characters"
user-invocable: false
origin: auto-extracted
---
# [Descriptive Pattern Name]
**Extracted:** [Date]
**Context:** [Brief description of when this applies]
## Problem
[What problem this solves - be specific]
## Solution
[The pattern/technique/workaround - with code examples]
## When to Use
[Trigger conditions]
Quality gate — Checklist + Holistic verdict
5a. Required checklist (verify by actually reading files)
Execute all of the following before evaluating the draft:
5b. Holistic verdict
Synthesize the checklist results and draft quality, then choose one of the following:
| Verdict |
Meaning |
Next Action |
| Save |
Unique, specific, well-scoped |
Proceed to Step 6 |
| Improve then Save |
Valuable but needs refinement |
List improvements → revise → re-evaluate (once) |
| Absorb into [X] |
Should be appended to an existing skill |
Show target skill and additions → Step 6 |
| Drop |
Trivial, redundant, or too abstract |
Explain reasoning and stop |
Guideline dimensions (informing the verdict, not scored):
- Specificity & Actionability: Contains code examples or commands that are immediately usable
- Scope Fit: Name, trigger conditions, and content are aligned and focused on a single pattern
- Uniqueness: Provides value not covered by existing skills (informed by checklist results)
- Reusability: Realistic trigger scenarios exist in future sessions
- Verdict-specific confirmation flow
- Improve then Save: Present the required improvements + revised draft + updated checklist/verdict after one re-evaluation; if the revised verdict is Save, save after user confirmation, otherwise follow the new verdict
- Save: Present save path + checklist results + 1-line verdict rationale + full draft → save after user confirmation
- Absorb into [X]: Present target path + additions (diff format) + checklist results + verdict rationale → append after user confirmation
- Drop: Show checklist results + reasoning only (no confirmation needed)
- Save / Absorb to the determined location
Output Format for Step 5
### Checklist
- [x] skills/ grep: no overlap (or: overlap found → details)
- [x] MEMORY.md: no overlap (or: overlap found → details)
- [x] Existing skill append: new file appropriate (or: should append to [X])
- [x] Reusability: confirmed (or: one-off → Drop)
### Verdict: Save / Improve then Save / Absorb into [X] / Drop
**Rationale:** (1-2 sentences explaining the verdict)
Design Rationale
This version replaces the previous 5-dimension numeric scoring rubric (Specificity, Actionability, Scope Fit, Non-redundancy, Coverage scored 1-5) with a checklist-based holistic verdict system. Modern frontier models (Opus 4.6+) have strong contextual judgment — forcing rich qualitative signals into numeric scores loses nuance and can produce misleading totals. The holistic approach lets the model weigh all factors naturally, producing more accurate save/drop decisions while the explicit checklist ensures no critical check is skipped.
Notes
- Don't extract trivial fixes (typos, simple syntax errors)
- Don't extract one-time issues (specific API outages, etc.)
- Focus on patterns that will save time in future sessions
- Keep skills focused — one pattern per skill
- When the verdict is Absorb, append to the existing skill rather than creating a new file
1---2name: source-command-learn-eval3description: Extract reusable patterns from the session, self-evaluate quality before saving, and determine the right save location (Global vs Project).4---5
6# source-command-learn-eval
7
8Use this skill when the user asks to run the migrated source command `learn-eval`.
9
10## Command Template
11
12# /learn-eval - Extract, Evaluate, then Save
13
14Extends `/learn` with a quality gate, save-location decision, and knowledge-placement awareness before writing any skill file.
15
16## What to Extract
17
18Look for:
19
201. **Error Resolution Patterns** — root cause + fix + reusability
212. **Debugging Techniques** — non-obvious steps, tool combinations
223. **Workarounds** — library quirks, API limitations, version-specific fixes
234. **Project-Specific Patterns** — conventions, architecture decisions, integration patterns
24
25## Process
26
271. Review the session for extractable patterns
282. Identify the most valuable/reusable insight
29
303. **Determine save location:**
31 - Ask: "Would this pattern be useful in a different project?"
32 - **Global** (`~/.Codex/skills/learned/`): Generic patterns usable across 2+ projects (bash compatibility, LLM API behavior, debugging techniques, etc.)
33 - **Project** (`.Codex/skills/learned/` in current project): Project-specific knowledge (quirks of a particular config file, project-specific architecture decisions, etc.)
34 - When in doubt, choose Global (moving Global → Project is easier than the reverse)
35
364. Draft the skill file using this format:
37
38```markdown
39---
40name: pattern-name
41description: "Under 130 characters"
42user-invocable: false
43origin: auto-extracted
44---
45
46# [Descriptive Pattern Name]
47
48**Extracted:** [Date]
49**Context:** [Brief description of when this applies]
50
51## Problem
52[What problem this solves - be specific]
53
54## Solution
55[The pattern/technique/workaround - with code examples]
56
57## When to Use
58[Trigger conditions]
59```
60
615. **Quality gate — Checklist + Holistic verdict**
62
63 ### 5a. Required checklist (verify by actually reading files)
64
65 Execute **all** of the following before evaluating the draft:
66
67 - [ ] Grep `~/.Codex/skills/` and relevant project `.Codex/skills/` files by keyword to check for content overlap
68 - [ ] Check MEMORY.md (both project and global) for overlap
69 - [ ] Consider whether appending to an existing skill would suffice
70 - [ ] Confirm this is a reusable pattern, not a one-off fix
71
72 ### 5b. Holistic verdict
73
74 Synthesize the checklist results and draft quality, then choose **one** of the following:
75
76 | Verdict | Meaning | Next Action |
77 |---------|---------|-------------|
78 | **Save** | Unique, specific, well-scoped | Proceed to Step 6 |
79 | **Improve then Save** | Valuable but needs refinement | List improvements → revise → re-evaluate (once) |
80 | **Absorb into [X]** | Should be appended to an existing skill | Show target skill and additions → Step 6 |
81 | **Drop** | Trivial, redundant, or too abstract | Explain reasoning and stop |
82
83**Guideline dimensions** (informing the verdict, not scored):
84
85- **Specificity & Actionability**: Contains code examples or commands that are immediately usable
86- **Scope Fit**: Name, trigger conditions, and content are aligned and focused on a single pattern
87- **Uniqueness**: Provides value not covered by existing skills (informed by checklist results)
88- **Reusability**: Realistic trigger scenarios exist in future sessions
89
906. **Verdict-specific confirmation flow**
91
92- **Improve then Save**: Present the required improvements + revised draft + updated checklist/verdict after one re-evaluation; if the revised verdict is **Save**, save after user confirmation, otherwise follow the new verdict
93- **Save**: Present save path + checklist results + 1-line verdict rationale + full draft → save after user confirmation
94- **Absorb into [X]**: Present target path + additions (diff format) + checklist results + verdict rationale → append after user confirmation
95- **Drop**: Show checklist results + reasoning only (no confirmation needed)
96
977. Save / Absorb to the determined location
98
99## Output Format for Step 5
100
101```
102### Checklist
103- [x] skills/ grep: no overlap (or: overlap found → details)
104- [x] MEMORY.md: no overlap (or: overlap found → details)
105- [x] Existing skill append: new file appropriate (or: should append to [X])
106- [x] Reusability: confirmed (or: one-off → Drop)
107
108### Verdict: Save / Improve then Save / Absorb into [X] / Drop
109
110**Rationale:** (1-2 sentences explaining the verdict)
111```
112
113## Design Rationale
114
115This version replaces the previous 5-dimension numeric scoring rubric (Specificity, Actionability, Scope Fit, Non-redundancy, Coverage scored 1-5) with a checklist-based holistic verdict system. Modern frontier models (Opus 4.6+) have strong contextual judgment — forcing rich qualitative signals into numeric scores loses nuance and can produce misleading totals. The holistic approach lets the model weigh all factors naturally, producing more accurate save/drop decisions while the explicit checklist ensures no critical check is skipped.
116
117## Notes
118
119- Don't extract trivial fixes (typos, simple syntax errors)
120- Don't extract one-time issues (specific API outages, etc.)
121- Focus on patterns that will save time in future sessions
122- Keep skills focused — one pattern per skill
123- When the verdict is Absorb, append to the existing skill rather than creating a new file