note

name	note
description	The single human-facing vault intake command. Use /note for anything the user wants saved to Obsidian: quick notes, todos, meetings, emails, decisions, people updates, project/matter updates, timelines, and raw pasted material. Routes one input into the readable three-ledger system: daily chronology (通鉴体), people notes (纪传体), and project/matter notes (纪事本末), with optional event artifacts and raw archives. Prefer this over lower-level Obsidian/chronicle skills unless the user explicitly asks for a tool-specific operation. Trigger: /note, note, note this, add to notes, remember this, log this, capture this, intake this.
argument-hint	[free-form content to capture and route]
allowed-tools	Bash, Read, Write, Edit, Grep, Glob
metadata	{"version":"1.2.0","last_updated":"2026-07-08T00:00:00.000Z","summary":"Chat-in → daily chronology + person note when applicable + project/matter note + event artifact when useful, with raw archive and cross-links for review."}
created	2026-06-27T23:52
updated	2026-07-08T00:00

Skill: note (single vault intake router)

Purpose

The user dumps content into chat. This skill captures it without friction and routes it to the right home, then hands control back for the user to review. The user is the reviewer — never assume the generated note is final.

This is the default and preferred entry point for writing into Obsidian. The user should not need to remember a menu of specialized note skills. Lower-level Chronicle/Obsidian skills are implementation details unless the user asks for a specific tool operation such as querying Bases, formatting markdown, or recording audio.

The vault is maintained as three cross-checking ledgers:

• Chronological / 通鉴体: today's diary note records when the thing happened.
• Biographical / 纪传体: people notes record the human-centered history.
• Project-centered / 纪事本末: project/matter notes record how one matter develops from beginning to end.

One user input should therefore create one canonical intake and write pointers to every ledger that applies. Do not duplicate long content across all three; write a short index line in the diary, append or create concise context in the person note when people are involved, and put the matter narrative/details in the project note when there is a bounded project or issue.

Each ledger may also carry its own timeline view:

• Daily timeline: one-day chronological sequence.
• Person timeline: the user's history with a person over months/years.
• Project timeline: the internal history of one project/matter from start to finish. Timeline views are summaries and navigation aids, not the only source of truth.

Readability-first rule

Everything generated for the vault must be easy for the user to scan later. Machine-queryable metadata is secondary to human readability.

• Prefer short sections with obvious headings over dense paragraphs.
• Put the action or decision first; context comes after.
• Keep diary lines, timeline items, and task text short enough to understand at a glance.
• Avoid stuffing long tag chains, bracket metadata, or repeated links into the visible text. Use only the tags/links that materially help retrieval.
• If a note needs structured fields, put them in frontmatter or a compact "Details" section, not inside every sentence.
• Generated notes should look useful in plain Markdown, even without plugins.

Operating mode: GENERATE → then REVIEW

Run the full pipeline in one pass, then show a compact summary of everything created and invite edits. Do NOT stop mid-pipeline to ask routing questions unless the destination is genuinely ambiguous (see Step 3).

Pipeline (every invocation)

Step 0 — Resolve dates