Obsidian Core Notes

Keep source files, generated .core.md notes, topic-level 专题综合.core.md notes, and Obsidian relationship indexes synchronized.

Workflow

1. Confirm the vault/workspace root. Use the current working directory unless the user names another root.
2. Before writing, run a scan when scope is broad:
   bash python <skill-dir>/scripts/obsidian_core_notes.py scan --root <vault-root> --json
3. Decide the note type before writing:
   - File sidecar: one generated .core.md for a non-Markdown business source attachment.
   - Folder index: 资料索引.md for navigation and direct source lists.
   - Topic synthesis: 专题综合.core.md only for high-value folders that can support V3-like synthesis.
4. Before revising source Markdown, folder indexes, or topic synthesis notes, apply the vault document-governance fields from 个人/公司相关个人资料/个人知识库实现路径/文档分类分级与技能取信准则.md.
5. For create/edit/move/rename/delete operations, update the matching .core.md note and nearest 资料索引.md in the same turn.
6. For bulk refreshes, run:
   bash python <skill-dir>/scripts/obsidian_core_notes.py refresh --root <vault-root>
refresh creates lightweight sidecars and indexes; it does not replace human/LLM synthesis for 专题综合.core.md.
7. For broad topic work, screen candidates before writing:
   bash python <skill-dir>/scripts/obsidian_core_notes.py topic-candidates --root <vault-root> --json
8. Validate after any bulk operation:
   bash python <skill-dir>/scripts/obsidian_core_notes.py validate --root <vault-root>
9. Clean generated notes only when explicitly requested:
   bash python <skill-dir>/scripts/obsidian_core_notes.py clean-generated --root <vault-root>

Rules

• Treat non-Markdown business source files as attachments and generate distinct sidecar notes named <source filename>.core.md.
• Do not generate .core.md sidecars for code, config, scripts, tests, runtime output, trained model output, parser output, checkpoints, vendor bundles, or generated result folders. Existing Markdown project documents such as README or planning notes may be referenced directly.
• Reference existing Markdown core files directly; do not duplicate them.
• Put folder navigation in 资料索引.md; put the workspace entrypoint in 核心文件索引.md.
• Generated .core.md sidecars must use doc_role: source, doc_authority: supporting, and doc_rule: wiki-doc-governance-v1.
• Generated 资料索引.md and 核心文件索引.md must use doc_role: common, doc_authority: preferred, and doc_rule: wiki-doc-governance-v1.
• Deep 专题综合.core.md notes that carry durable judgments should use doc_role: result; lightweight source maps may use doc_role: common. Preserve existing higher-authority values unless the user asks to reclassify.
• If modifying an original Markdown source file, do not overwrite result files with process/source/evidence content. Prefer adding provenance links such as related_process, related_result, or validation.
• Do not make every folder look deeply summarized. Most 专题综合.core.md files should remain lightweight source maps unless the folder passes topic-synthesis screening.
• V3-like topic synthesis must include source provenance, version/history cues, core judgments, content map, reusable patterns/templates/components, actions, and open questions.
• When a user asks for aggressive cleanup, back up overwritten/deleted generated notes outside the vault before deletion.
• Use only generated markers for safe overwrite or deletion:
• <!-- CORE_FILE_NOTE_V1 -->
• <!-- CORE_FOLDER_INDEX_V1 -->
• <!-- CORE_WORKSPACE_INDEX_V1 -->
• Never delete hand-written Markdown notes unless the user explicitly asks.
• Exclude dependencies, caches, logs, build output, code/config files, model artifacts, training output, parser output, static vendor bundles, generated result folders, and temporary Office lock files.

References

• Read references/core-file-rules.md before changing core-file classification.
• Read references/obsidian-linking.md before changing note names, tags, markers, or relationship link conventions.
• Read references/topic-synthesis-core-notes.md before screening folders for V3-like 专题综合.core.md notes or rewriting many topic notes.

Scripts

• scripts/obsidian_core_notes.py scan: count core candidates and summarize scope.
• scripts/obsidian_core_notes.py refresh: create or update .core.md, 资料索引.md, and 核心文件索引.md.
• scripts/obsidian_core_notes.py topic-candidates: rank folders whose direct sources may justify V3-like 专题综合.core.md.
• scripts/obsidian_core_notes.py validate: verify generated marker counts and common corruption patterns.
• scripts/obsidian_core_notes.py clean-generated: remove files with generated markers; use --noise-only for code/model/output cleanup.

Common Pitfall

If the user wants "像 V3 一样的专题综合", do not stop after refresh. refresh is a graph-maintenance pass; it can produce version/source statistics, but the V3-style note is a curated synthesis pass over selected folders.