Claude-skill-registry learning-taxonomy
Expert knowledge for categorizing learnings and routing them to appropriate improvement targets. Use when analyzing session learnings to determine where context improvements should be applied.
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/learning-taxonomy" ~/.claude/skills/majiayu000-claude-skill-registry-learning-taxonomy && rm -rf "$T"
skills/data/learning-taxonomy/SKILL.mdLearning Taxonomy
Expert reference for categorizing session learnings and routing them to appropriate targets for context improvement.
Learning Categories
| Category | Description | Keywords | Priority | Typical Source |
|---|---|---|---|---|
| caveat | Gotcha, workaround, required setup, edge case | must, required, careful, watch out, gotcha | High | Config issues, env setup, surprising behavior |
| pattern | Convention, best practice, coding style | always, never, prefer, convention, standard | Medium | Code reviews, refactoring, style decisions |
| error_fix | Solution to recurring error or bug | fix, error, resolved, workaround, hack | High | Debugging sessions, stack traces, test failures |
| dependency | Tool, library, version requirement | install, requires, upgrade, package, version | Medium | Package updates, compatibility issues |
| command | Useful shell command, script, or CLI invocation | run, npm, python, bash, script, command | Low | Build/test/deploy workflows |
| architecture | Design decision, structural pattern, component relationship | design, structure, pattern, component, layer | Medium | System design, refactoring, API design |
Claude Code Memory Hierarchy
Claude Code uses a hierarchical memory system. Understanding this is critical for routing learnings correctly.
Memory Locations (Highest to Lowest Priority)
| Memory Type | Location | Purpose | Shared With |
|---|---|---|---|
| Enterprise policy | (macOS) | Org-wide standards | All org users |
| Project memory | or | Team-shared project instructions | Team via git |
| Project rules | | Modular topic-specific rules | Team via git |
| User memory | | Personal preferences (all projects) | Just you |
| User rules | | Personal modular rules | Just you |
| Project local | | Personal project-specific (gitignored) | Just you |
Memory Scope Decision
| Is this learning... | Route to |
|---|---|
| Personal workflow/preference for ALL projects | |
| Personal preference for THIS project only | |
| Team knowledge everyone should know | |
| Topic-specific (testing, API, security) | |
| Path-specific (only certain file types) | with frontmatter |
| Organization standard | Enterprise policy (escalate to IT) |
Path-Specific Rules
For learnings that only apply to certain files:
--- paths: src/api/**/*.ts --- # API Rules - Validate all inputs with zod
Glob patterns:
**/*.ts, src/**/*, *.md, {src,lib}/**/*.ts
Import Syntax
CLAUDE.md files can import other files:
See @README for project overview. Individual preferences: @~/.claude/my-prefs.md
Target Routing
By Learning Scope
| Scope | Target | Section to Add |
|---|---|---|
| team + broad | | Category-specific section |
| team + topic-specific | | Topic section |
| team + file-specific | with | Topic section |
| personal + all projects | | |
| personal + this project | | |
By Category (Default: Project Memory)
| Category | Target Section | Create If Missing |
|---|---|---|
| caveat | | Yes |
| pattern | | Yes |
| error_fix | | Yes |
| dependency | | Yes |
| command | | Yes |
| architecture | | Yes |
Secondary Targets
| Learning Context | Secondary Target | Condition |
|---|---|---|
| Specific to subdirectory | Subdirectory CLAUDE.md | Content mentions directory name |
| Agent behavior | Agent definition | Architecture or pattern learnings |
| Skill knowledge | Skill SKILL.md | Domain-specific expertise |
| README content | README.md | Setup, installation, usage |
Suggestion Format Templates
Caveat Entry
### [Short Title] - [Specific caveat or gotcha] - [Workaround or required action if applicable]
Pattern Entry
### [Pattern Name] - **When**: [When to use this pattern] - **How**: [How to implement] - **Example**: [Brief example if helpful]
Error Fix Entry
### [Error Name or Symptom] **Symptoms:** [What the user sees] **Cause:** [Root cause] **Fix:** ```bash [Commands to fix if applicable]
### Dependency Entry ```markdown ### [Package/Tool Name] - **Version**: [Required version] - **Purpose**: [Why it's needed] - **Install**: `[install command]`
Command Entry
### [What the Command Does] ```bash [command with arguments]
[Brief explanation if not obvious]
### Architecture Entry ```markdown ### [Component/Pattern Name] - **Purpose**: [What it does] - **Location**: [Where to find it] - **Interactions**: [What it connects to]
Priority Calculation
High Priority
All of these must be true:
- Category is
orcaveaterror_fix - Confidence >= 0.8
- Target is primary (root CLAUDE.md)
Medium Priority
Any of these:
- Confidence >= 0.6
- Target is primary
- Category is
ordependencyarchitecture
Low Priority
Default when neither High nor Medium criteria met.
Source Analysis
Git Commits
- Prefix patterns boost confidence:
,fix:
,bugfix:
→ error_fix (0.85)hotfix:
,feat:
→ pattern (0.60)feature:
,docs:
→ pattern (0.70)doc:
,chore:
→ dependency (0.75)deps:
Git Diff Analysis
- Files modified 3+ times in session → potential caveat area
- TODO/FIXME comments added → high-confidence caveats
- New entries in package.json/requirements.txt → dependency
User Input
- Direct input always gets confidence 0.9
- User explicitly categorizes → use their category
Integration with Other Plugins
backlog-md / simbl
If these plugins are present, also extract learnings from:
- Task notes (
content)--append-notes - Implementation plans
- Acceptance criteria comments
Check for these directories:
(backlog-md)backlog/tasks/
(simbl).simbl/
documentation-tools
After applying suggestions, consider running:
- Update documentation links/link-docs-to-claude
- Sync CLAUDE.md → AGENTS.md/sync-agents-md
Best Practices
When Extracting Learnings
- Prefer specific over generic (not "be careful" but "restart server after config changes")
- Include context (file paths, command examples)
- Capture the "why" not just the "what"
- Date-stamp session learnings for freshness tracking
When Generating Suggestions
- Match learning to most specific target available
- Use existing section if present, create if not
- Format consistently with existing content
- Keep suggestions atomic (one learning per suggestion)
When Reviewing Suggestions
- Present highest priority first
- Show diff preview with context
- Allow modification before applying
- Track applied vs discarded for learning
Common Mistakes to Avoid
| Mistake | Better Approach |
|---|---|
| Too vague: "Watch out for auth" | Specific: "OAuth tokens expire after 1 hour; implement refresh logic" |
| Missing context: "Run this first" | With context: "Before running tests: " |
| Duplicate suggestions | Check if learning already exists in target |
| Wrong target | Architecture patterns → CLAUDE.md, not random files |
| Over-suggesting | Only suggest if confidence >= 0.5 |
| Personal pref in project memory | Your shortcuts → or |
| Team knowledge in local file | Team caveats → , not |
| Everything in root CLAUDE.md | Topic-specific → |
| Ignoring existing rules structure | Check for before suggesting new location |