| name | learned |
| description | Log a learning, discovery, or decision to the vault with full context from the current conversation. |
| user-invocable | true |
| argument-hint | <what you learned> [--type correction|decision|discovery|pattern|gotcha] |
| allowed-tools | ["Read","Write","Edit","Glob","Grep"] |
Learned — Explicit Knowledge Capture
Log something you or the user discovered during the current conversation to the vault. This is for learnings that hooks can't auto-detect — debugging insights, root cause discoveries, architecture gotchas, performance findings, etc.
When to use
- After debugging a tricky bug (log the root cause + fix)
- When the user shares project knowledge that isn't in code
- After discovering a non-obvious behavior or gotcha
- When making an architecture decision with rationale
- When a pattern emerges across multiple interactions
Steps
-
Parse the argument — extract what was learned and the type. Default type is discovery.
-
Determine metadata from conversation context:
- Which project does this relate to? (check
vault/shared/project-knowledge/ for registered projects, or general)
- What area? (
architecture, debugging, deployment, api, database, tooling, workflow, etc.)
- Severity/priority:
high if it caused a bug or could cause one again, medium for useful knowledge, low for nice-to-know
-
Check for duplicates — search vault/learnings/ for similar entries. If one exists, update its recurrence-count and last-seen instead of creating a new file.
-
Write the vault entry to vault/learnings/<TYPE>-<YYYYMMDD>-<SEQ>.md:
---
id: <TYPE>-<YYYYMMDD>-<SEQ>
logged: <ISO timestamp>
type: learning
priority: <high|medium|low>
status: new
category: <type from arg>
area: <determined from context>
agent: main
project: <determined from context>
pattern-key: <short kebab-case key for dedup>
recurrence-count: 1
first-seen: <YYYY-MM-DD>
last-seen: <YYYY-MM-DD>
tags: [<relevant tags>]
related: [<wikilinks to related entries if any>]
---
# <Concise title>
## What happened
<Brief description of />
- Confirm — tell the user what was logged and the file path.
Type reference
| Type | Prefix | Use for |
|---|
correction | LRN | User corrected Claude's approach |
decision | LRN | Architecture or design choice with rationale |
discovery | LRN | Found something non-obvious while working |
pattern | LRN | Recurring theme across interactions |
gotcha | ERR | Something that fails silently or is easy to get wrong |
Important
- Be specific — "SQLite WAL mode is fast enough" is better than "database works well"
- Include file paths and line numbers as evidence when applicable
- Don't log trivial things — if it's obvious from reading the code, skip it
- Fill in ALL fields — no placeholders. This is the whole point of this skill vs auto-hooks.
