How do I install the Learned skill?

Run npx skillmds@latest add majiayu000/learned in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Learned safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Learned?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Learned free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Learned?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Learned by majiayu000 — Agent Skill

Name: Learned
Rating: 4.666666666666667 (3 reviews)
Author: majiayu000

File contents

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 the situation/context>

## What was learned
<The actual insight — be specific and actionable>

## Why it matters
<How this prevents future issues or improves workflow>

## Evidence
<Link to file, line number, error message, or conversation context>

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.

---name: learneddescription: Log a learning, discovery, or decision to the vault with full context from the current conversation.--- # 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 1. **Parse the argument** — extract what was learned and the type. Default type is `discovery`. 2. **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 3. **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. 4. **Write the vault entry** to `vault/learnings/<TYPE>-<YYYYMMDD>-<SEQ>.md`: ```markdown --- 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 the situation/context> ## What was learned <The actual insight — be specific and actionable> ## Why it matters <How this prevents future issues or improves workflow> ## Evidence <Link to file, line number, error message, or conversation context> ``` 5. **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.

Frequently asked questions

Learned