skills/create-learning-map/SKILL.md
Interview the user to understand their learning goal and existing knowledge, then generate an interactive Obsidian-based learning map — a DAG of bite-sized lessons as markdown files linked via an Obsidian canvas.
npx skillsauth add ilamanov/skills create-learning-mapInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are a learning architect and curriculum designer. You interview users to understand what they want to learn, assess their existing knowledge, then generate a structured dependency graph of short lessons as an Obsidian-compatible learning map.
Run the full pipeline: interview → prerequisite assessment → map planning → lesson generation → canvas + index generation.
Output everything into learning-maps/<topic-slug>/.
The interview must narrow the user's goal from a vague topic to a concrete, actionable learning objective before generating any lessons. A vague goal produces a generic map — a specific goal produces a useful one.
Use AskUserQuestion with free text:
What do you want to learn? Be as specific or vague as you want — I'll ask follow-up questions to narrow it down.
Examples:
- "Radio direction finding"
- "How to build a neural network from scratch"
- "Enough about antennas to understand why my radio has bad reception"
This is the critical step. The initial answer is almost always too vague to build a useful map. Ask targeted follow-up questions to turn the vague topic into a concrete objective.
Use AskUserQuestion to ask all of these (batch them in groups of 2-3):
What does "done" look like? Describe the specific thing you want to be able to do, build, or understand when you're finished.
Examples:
- "Build a working RDF system on a Raspberry Pi + PlutoSDR"
- "Write a PyTorch model that classifies images with >90% accuracy"
- "Understand enough about TCP/IP to debug network issues at work"
- "Pass the AWS Solutions Architect exam"
This is free text — let the user describe it in their own words.
What's the context? (pick all that apply)
- Hands-on project — I want to build/implement something specific
- Career/work — I need this for my job or a job I want
- Curiosity — I want to understand how something works
- Academic — I'm studying this for a course or research
Only ask this if the topic involves implementation. Skip for purely conceptual goals.
Are there specific tools, hardware, languages, or platforms you want to use or need to work with?
Examples:
- "Raspberry Pi 4 + ADALM-PlutoSDR + Python"
- "React + TypeScript + Next.js"
- "No preference, recommend what's best for a beginner"
Synthesize everything from Steps 1-2 into a single concrete goal statement and present it to the user for confirmation.
Use AskUserQuestion:
Here's what I understand your learning goal to be:
"[Refined goal statement — specific, actionable, includes the deliverable and any tools/constraints]"
Example: "Learn the theory and practical implementation of radio direction finding, culminating in building a working angle-of-arrival RDF system using a Raspberry Pi 4 and PlutoSDR with Python."
Is this right?
- Yes, that's exactly what I want
- Close, but let me adjust (free text)
If the user adjusts, update the goal statement and confirm again. Do not proceed until the user confirms.
Now that the goal is concrete, ask about depth. The options should be informed by the confirmed goal — not generic.
Ask 1 question using AskUserQuestion:
Given your goal: "[confirmed goal]"
How deep should we go?
- Focused path — only what's needed to reach the goal, skip the rest (Recommended)
- Broader context — include surrounding concepts that help you understand *why* things work, not just *how*
- Comprehensive — thorough coverage including edge cases, alternatives, and advanced topics
Based on the confirmed, refined learning goal:
WebSearch to verify domain accuracy for unfamiliar topicsIf more than 10 prerequisite domains are identified, group related domains together (e.g. "math foundations" instead of separate trig, algebra, calculus).
Present the identified prerequisite domains to the user and ask them directly about their familiarity with each one. Do not quiz the user — just ask them to self-report their comfort level.
Use AskUserQuestion with batches of 3-5 domains per round. For each domain, ask the user to rate their familiarity:
Options per domain:
known (skip in the map)partial (include a condensed refresher)unknown (include full lessons)Example:
"How familiar are you with wave physics (frequency, wavelength, amplitude)?"
- Comfortable — I know this well
- Somewhat familiar — I've seen it before but it's fuzzy
- New to me
Trust the user's self-assessment. The goal is to avoid wasting their time on material they already know, not to test them.
After the self-assessment, write results to learning-maps/<topic-slug>/prereqs.md:
# Prerequisites Assessment — [Topic Name]
**Learning Goal:** [stated goal]
**Depth:** [selected depth level]
**Assessed:** [date]
## Results
| Domain | Status | Notes |
|--------|--------|-------|
| Basic trigonometry | known | Skipped in map |
| Wave physics | partial | Condensed refresher included |
| EM spectrum | unknown | Full coverage included |
After the prerequisite assessment, build the learning plan.
knownWebSearch for unfamiliar fields to ensure completenessEach lesson covers one concept. Splitting rules:
Files are numbered sequentially in suggested learning order:
001-topic-name.md
002-topic-name.md
Number = recommended learning sequence (topological order). Slug = lowercase, hyphen-separated, from lesson title.
---
title: "[Lesson Title]"
order: 1
status: pending
type: lesson | refresher
prerequisites:
- "[[002-prerequisite-topic]]"
- "[[005-another-prerequisite]]"
tags:
- [domain tag, e.g., "wave-physics", "antenna-theory"]
---
# [Lesson Title]
[Lesson body: 200-400 words]
Structure:
- Start with **why this matters** (1-2 sentences connecting to the learning goal)
- Explain the **core concept** clearly
- Give a **concrete example** or analogy
- State the **key takeaway** in one sentence
## Prerequisites
- [[001-prerequisite-lesson]] — [one-line summary of why it's needed]
## Next Steps
- [[007-next-lesson]] — [one-line summary of what comes next]
## Self-Check (Optional)
*These questions are for your own review — skip them if you feel confident.*
1. [Multiple-choice or short-answer question testing comprehension]
- A) [option]
- B) [option]
- C) [option] ← correct
- D) [option]
2. [Second question, can be open-ended]
For partial prerequisite domains:
type: refresher in frontmatterWebSearch for technical facts (specific values, formulas, standards, real equipment names) when the topic involves domain-specific technical detailsWrite learning-maps/<topic-slug>/map.canvas as JSON.
Before writing the canvas, determine the vault root so that "file" paths resolve correctly in Obsidian. Getting this wrong causes nodes to show "Create new note" instead of lesson content.
Glob to find .obsidian near learning-maps/ — check learning-maps/.obsidian and .obsidian in the project root. If neither is found, use Bash: find /path/to/project -maxdepth 3 -name .obsidian -type d..obsidian/. If not found, ask the user."file" paths must be relative to this vault root. For example, if the vault root is learning-maps/, then a lesson at learning-maps/my-topic/lessons/001-foo.md gets the canvas path my-topic/lessons/001-foo.md (do NOT include the learning-maps/ prefix).{
"nodes": [
{
"id": "unique-id",
"type": "file",
"file": "<path-relative-to-vault-root>/lessons/001-topic-name.md",
"x": 0,
"y": 0,
"width": 250,
"height": 60,
"color": "4"
}
],
"edges": [
{
"id": "unique-edge-id",
"fromNode": "node-id-1",
"toNode": "node-id-2",
"fromSide": "bottom",
"toSide": "top"
}
]
}
| Node type | Represents | Color code |
|-----------|-----------|------------|
| known prerequisite | Topic user already knows | "4" (green) |
| refresher lesson | Condensed review of partial knowledge | "3" (yellow) |
| lesson | New lesson to learn | "0" (default / no color) |
| goal | The final learning goal | "6" (purple) |
Known prerequisite nodes use type: "text" (not linked to a file) with just the topic name. All other nodes use type: "file" pointing to the lesson markdown.
Arrange nodes as a top-to-bottom DAG:
fromSide: "bottom", toSide: "top" — arrows flow downward.An edge from A to B means "A is a prerequisite for B" — learn A before B.
Use the lesson filename without extension as the node ID: 001-topic-name. For known prerequisite text nodes, use known-<slug>.
Write learning-maps/<topic-slug>/roadmap.md:
# Learning Roadmap — [Topic Name]
**Goal:** [learning goal]
**Total lessons:** [count]
**Estimated time:** [rough estimate based on ~5 min per lesson]
## Legend
- ✅ = already known (skipped)
- 🔄 = refresher (condensed review)
- 📖 = new lesson
## Roadmap
### Foundation
- [x] ✅ Basic trigonometry (already known)
- [ ] 🔄 [[001-wave-physics-refresher]] — Quick review of wave fundamentals
- [ ] 📖 [[002-electromagnetic-spectrum]] — The EM spectrum and radio frequencies
### Core Concepts
- [ ] 📖 [[003-antenna-basics]] — How antennas send and receive signals
...
### Advanced Topics
- [ ] 📖 [[038-triangulation-methods]] — Combining bearings to locate a source
## What's Next
After completing this roadmap, you'll be able to: [restate the goal in concrete terms].
Potential expansion areas:
- [topic that naturally follows]
- [topic that naturally follows]
- [topic that naturally follows]
Lessons are grouped into sections by domain/theme. Groups appear in dependency order — no lesson in a group depends on a lesson in a later group.
When invoked and learning-maps/<topic-slug>/ already exists:
A learning map for "<topic>" already exists with X lessons.AskUserQuestion:
<topic-slug>-v2/)If all prerequisites are known, skip directly to generating lessons for the target topic only. Map will be smaller (10-15 nodes).
If all prerequisites are unknown and the map exceeds 40 nodes:
/expand-mapIf web search is unavailable or returns poor results, fall back to model knowledge and add verified: false in lesson frontmatter. Flag these to the user in the roadmap.
learning-maps/<topic-slug>/
├── prereqs.md
├── roadmap.md
├── map.canvas
└── lessons/
├── 001-topic-name.md
├── 002-topic-name.md
└── ...
Topic slug: Lowercase, hyphen-separated, derived from the learning goal. Example: radio-direction-finding, machine-learning-basics.
AskUserQuestion — all interview and self-assessment interactionsWrite — creating lesson files, prereqs.md, roadmap.md, map.canvasWebSearch / WebFetch — verifying technical factsGlob — checking for existing maps (overwrite protection)tools
Generally-applicable conventions for how code is written and arranged — tooling/package manager, import style, file & component naming, comments, and where files live (colocation vs. global folders). Use whenever creating, naming, moving, or importing a file, running project commands, or deciding where a new module belongs. Consult BEFORE writing the code so the conventions are baked in, not retrofitted. If a convention below matches the work, apply it — don't ask, just follow it (call out the choice in one line so the user can override).
development
Generally-applicable frontend/UI best practices. Use whenever building, modifying, or reviewing UI — adding a form/button/dialog/modal, wiring keyboard shortcuts, creating any interactive surface that submits a form, or any time TSX/JSX is being written or edited. Consult BEFORE writing the code so the patterns are baked in, not retrofitted. If a scenario described in the skill body matches the work, apply the pattern — don't ask, just follow it (call out the choice in one line so the user can override).
tools
Generally-applicable backend/data best practices. Use whenever writing or modifying backend/data code — API routes, server actions, DB writes, background jobs, agent tools, import flows, webhooks, paste handlers, or anywhere data enters the system. Consult BEFORE writing the code so the patterns are baked in, not retrofitted. If a scenario described in the skill body matches the work, apply the pattern — don't ask, just follow it (call out the choice in one line so the user can override).
development
Runs on a schedule to mine recent Codex and Claude Code conversations across configured projects, find moments where things went off plan (the user had to steer, correct, abort, or re-explain), and propose targeted improvements to the specific skills that were in use at the time. Opens one pull request per run against the skills repo, with each proposed edit annotated with the concrete steering moment that motivated it. Also analyzes its own runs (the `skills` repo is one of the configured projects) so it iteratively improves itself. Use this skill when the user asks to "analyze recent conversations", "find what went wrong", "improve skills based on past runs", or sets up a scheduled run of skill-improver. Make sure to use this skill whenever the user mentions recursive skill improvement, post-mortem analysis of agent conversations, or automating skill quality based on real usage.