skills/expand-learning-map/SKILL.md
Expand an existing Obsidian-based learning map in any direction. User describes where to go deeper or what prerequisites to add, and the skill generates new lesson nodes, updates the canvas and index incrementally.
npx skillsauth add ilamanov/skills expand-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 expanding an existing learning map. You understand the current map structure, identify where the user wants to grow, generate new lessons, and incrementally update the canvas and roadmap without disturbing existing content.
Expand an existing learning map by generating new lesson nodes in a user-specified direction, writing lesson files, and incrementally updating the canvas and roadmap index.
The expansion interview must produce a concrete, specific objective — not just a vague direction like "go deeper into X." A vague direction produces generic filler lessons; a specific one produces useful content.
Ask the user what they want to expand using AskUserQuestion with free text:
Which part of the map do you want to expand? Describe a direction, e.g.:
- "Go deeper into antenna theory"
- "I want to understand Doppler-based direction finding in more detail"
- "What prerequisites am I missing for understanding phased arrays?"
- "Expand the signal processing branch"
After the user responds, ask targeted follow-ups to make the expansion concrete. Use AskUserQuestion to ask:
Concrete outcome:
What specifically do you want to be able to do or understand after this expansion?
Examples:
- "Implement a MUSIC algorithm in Python for angle-of-arrival estimation"
- "Understand the math behind beamforming well enough to tune parameters"
- "Know how to choose between different RDF techniques for my use case"
Scope check (if the direction is broad):
"[User's direction]" covers a lot of ground. Which of these is closest to what you want?
- [Interpretation A — specific sub-topic]
- [Interpretation B — different specific sub-topic]
- [Interpretation C — different angle]
Only ask the scope check if the direction is genuinely ambiguous. Skip it if the user was already specific.
Synthesize the answers into a concrete expansion statement and confirm:
Here's what I'll expand the map with:
"[Specific expansion objective — what new capability or understanding the user will gain, and what it connects to in the existing map]"
Is this right?
- Yes, that's what I want
- Close, but let me adjust (free text)
Do not proceed until the user confirms.
Use Glob to scan learning-maps/*/roadmap.md and list available maps.
AskUserQuestion to let the user pick which map to expand/create-map insteadRead the following files to understand the current map:
learning-maps/<topic-slug>/roadmap.md — current lesson list and groupinglearning-maps/<topic-slug>/map.canvas — current DAG layout and node positionslearning-maps/<topic-slug>/prereqs.md — prerequisite assessment resultsGlob on learning-maps/<topic-slug>/lessons/*.md to list all existing lesson filesBased on the expansion direction and current map state:
If the expansion requires knowledge domains not covered in the original prerequisite assessment:
/create-map Phase 2 — comfortable / somewhat familiar / new to me)prereqs.mdWrite new .md files to learning-maps/<topic-slug>/lessons/ using the same format as existing lessons.
---
title: "[Lesson Title]"
order: [number]
status: pending
type: lesson | refresher
prerequisites:
- "[[NNN-prerequisite-topic]]"
tags:
- [domain tag]
---
# [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
- [[NNN-prerequisite-lesson]] — [one-line summary of why it's needed]
## Next Steps
- [[NNN-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]
WebSearch for technical facts (specific values, formulas, standards, real equipment names)verified: false in lesson frontmatterRead the existing map.canvas JSON, then modify it.
Before writing canvas paths, 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).| 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) |
fromSide: "bottom", toSide: "top"040-topic-name)known-<slug>An edge from A to B means "A is a prerequisite for B."
Write the modified JSON back to map.canvas using Write.
Read roadmap.md and update it using Edit:
New lessons use the same format:
- [ ] 📖 [[040-new-topic]] — One-line description
If the expansion required assessing new prerequisite domains, append the new self-assessment results to prereqs.md using Edit:
After completion, summarize to the user:
AskUserQuestion — expansion direction, map selection, prerequisite self-assessmentRead — reading existing map state (roadmap, canvas, lessons, prereqs)Glob — scanning for existing maps and lesson filesWrite — creating new lesson files, rewriting canvasEdit — updating roadmap.md and prereqs.mdWebSearch / WebFetch — verifying technical factstools
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.