obsidianize-module

Obsidianize a topic

Apply the vault's structured-indexing conventions to one freshly-added course topic. The contract you are enforcing is notes/_meta/SCHEMA.md — read it first; it is canonical. This skill is the procedure; SCHEMA.md is the spec. Topics 01 and 02 are the golden reference — when unsure of a field's shape, copy the corresponding note there.

This vault compiles four Neo4j GraphAcademy "Fundamentals" courses (neo4j-fundamentals, cypher-fundamentals, modeling-fundamentals, importing-fundamentals) into a nine-topic graduate-style course. Topic and lecture-note pages are synthesized from the raw asciidoc lessons (no slide decks, no recorded video to transcribe) plus the course_manifest.json crosswalk that ties each leaf back to its source course/module/lesson.

Before you start

1. Read notes/_meta/SCHEMA.md in full. If it has changed since this skill was written, the spec wins.
2. Locate the vault root: the notes/ folder containing _bases/, _concepts/, _meta/, and the NN-<slug> topic folders.
3. Identify the target topic folder and confirm it is in the raw, pre-integration state (leaves have source_course/source_module/ source_lesson but no type:; topic README has no frontmatter). If it already has type:, it may be partially done — diff against SCHEMA.md rather than blindly rewriting.
4. Establish the baseline. Run the checker once so you know which findings are pre-existing vs. introduced by your work: bash ${CLAUDE_PLUGIN_ROOT}/scripts/check-vault.sh <project-dir> (It self-locates the vault and reports ERROR/WARN findings. The new topic will show as a block of "missing required frontmatter" ERRORs — that is your worklist.)
5. Work from the committed clean state, not working-tree drift. If the tree has uncommitted edits, ask whether to proceed on top of them.

Pipeline

Run these in order. Mark each note done as you go. Commit at the end (one commit for the topic, or split topic vs leaves if the diff is large).

Step 1 — Frontmatter schema (mostly deterministic)

For the topic README (NN-<slug>/README.md): add the topic block from SCHEMA.md §2.1. Set module to the bare topic number (1..9, NOT zero-padded). Set section_count to the number of lecture-note leaves under this topic and lesson_count to the number of distinct source lessons compiled in — both are mechanical counts, stated in the topic README's header line. Set source_courses to the source-course slugs feeding this topic (from the course_manifest.json crosswalk; do not invent). Set aliases to ["NN-<slug>"] (the topic's own folder name, verbatim). Set prereqs to a wikilink to the previous topic's folder (e.g. topic N → [[<NN-1 topic folder name>]]), or [] for topic 01.

For each leaf (lecture-notes/<slug>/README.md): add the lecture-note block from SCHEMA.md §2.2. Preserve existing source_course/source_module/ source_lesson (merge, don't overwrite) — these tie the synthesized note back to its exact GraphAcademy origin, where source_lesson is the .adoc lesson directory name. Set aliases to ["<slug>"] — the leaf's own folder name, verbatim; this is required so [[slug]] wikilinks resolve in Obsidian (folder notes are README.md, see SCHEMA §4). There is no slide_count — GraphAcademy lessons have no slides; an images/ folder, if present, is optional and uncounted. Set topic to the parent topic's title verbatim. Leave concepts and prereqs for the judgment steps below.

Step 2 — concepts and prereqs (judgment)

• concepts: read each leaf and list the cross-cutting technical objects it introduces or leans on, as kebab-case slugs (SCHEMA.md §2.2). These are the curated vocabulary, distinct from tags. Reuse existing concept slugs from other notes where the same idea recurs (grep _concepts/ and sibling notes' concepts: lists for the canonical spelling).
• prereqs: derive from the note's own "Setup" / "Recap" / "where this starts" framing — what must the reader already understand? Usually the previous leaf in the topic's pedagogical chain; the topic's first leaf often points back to a prior topic's leaf. Use note-folder wikilinks. [] is valid when a note is genuinely standalone.

Step 3 — Tag taxonomy (deterministic given kind)

Replace each note's raw tags: with the nested scheme (SCHEMA.md §3): status/<state>, kind/<…>, module/<NN zero-padded>, and family/<name> when the leaf develops a specific topic family. Note the deliberate split: the module/ tag is zero-padded (module/03) while the module: frontmatter field is a bare integer (module: 3). The only judgment is picking kind/ per leaf — use the §3 semantics (intro / foundations / cypher / modeling / import / tooling / capstone).

Step 4 — Concept wikilinks (judgment; may hand off)

For each concept that has a hub in _concepts/, add one [[slug|alias]] wikilink at its first meaningful prose mention in each note that uses it (SCHEMA.md §4). Respect the no-self-link rule. Keep existing markdown links.

If this topic introduces a genuinely new cross-cutting concept that recurs across notes but has no hub yet, do not invent an inline hub here — invoke the concept-hub skill to create it properly (slug, body, appears_in, related, back-links), then return and link it. The checker's "hub-gap candidates" WARNs (Step 5) name these explicitly — use them as your worklist.

Step 5 — Verify (deterministic gate, not vibes)

Run the checker in strict mode and resolve everything it reports:

bash ${CLAUDE_PLUGIN_ROOT}/scripts/check-vault.sh <project-dir> --strict

• It must exit 0 (no ERROR-class findings): every note has the frontmatter its type requires, and every [[wikilink]] resolves.
• Triage the WARNs: appears_in backlink gaps and hub-gap candidates. Fix, or consciously accept each (a hub-gap may legitimately stay a plain tag — that is a judgment call, but make it deliberately, don't ignore it).
• Cross-check against the baseline from "Before you start": you should have removed the new topic's ERRORs and introduced none elsewhere.
• Known gotcha (verify): syllabus.base's "Lecture notes" view should filter on type == "lecture-note", not a pinned module == N. If a future edit re-pins it, the new topic won't appear.

Step 6 — Commit

One commit for the topic (split if the diff is large). Describe what was applied and follow the repo's existing commit-trailer convention (see git log). Do not git add -A blind — stage only the topic's notes (and any hub files the concept-hub skill created). The Bases need no edits and should not appear in the diff.

Out of scope

• Creating Bases views (one-time; already done — new topics flow in via §5).
• Editing Phase-1 sources under raw/ (the GraphAcademy transcripts and the course_manifest.json crosswalk).
• Reconciling deviations from out-of-band edits — that's the vault-librarian agent's job (run it, or the checker, after any Claude Cowork / MCP session).