Obsidian 文档工作流

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install obsidian-doc-workflow
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 obsidian-doc-workflow。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

Obsidian 文档工作流是 Openclaw Skills 的一项功能，用于在 Obsidian 仓库中维护一致、易于搜索且相互关联的文档。它将特定于项目的信息与可重复使用的工程知识分开，应用规范模板，并落实统一的文件夹、文件名、frontmatter、标签和链接约定。
它支持完整的文档生命周期，从选择正确的位置和创建文档，到验证元数据和内部链接，再到将过时内容安全地移入 Deprecated、Superseded 或 Historical 归档。这让 Openclaw Skills 适用于需要可靠文档、同时又不删除技术历史或创建空白、不一致页面的工程团队。

应用场景

创建项目文档，从
Project Overview.md
开始，并逐步扩展为架构、开发、测试、部署、API 和维护文档。 02 Shared Knowledge/ 中记录可重复使用的工程模式、技术指南、安全实践和部署策略。
创建文件前，将信息分类为项目专属、共享知识或外部资源。
统一应用 YAML frontmatter、小写 kebab-case 标签、状态值、日期、领域和项目关联。
使用标准 Wikilinks、跨文件夹链接和指向章节标题的深层链接，构建 Obsidian 知识图谱。
验证新建或更新的文档是否包含必需元数据、文件名与标题一致、链接有效、代码语言声明齐全，以及最新更新日期。
归档过时、已替换或历史材料，而不删除原始内容。
将波斯语源材料翻译或总结为以英语为主的文档，同时保留仓库的语言约定。

工作原理

从 OBSIDIAN_VAULT_PATH 解析仓库路径；如果未设置该变量，则使用文档中说明的 Mac 默认路径。
根据内容范围和未来复用可能性，确定内容应放在 01 Projects/{Project}/、02 Shared Knowledge/ 还是 03 Resources/。
从 00 Meta/Templates/ 选择规范模板，例如 Project Overview.md、Architecture.md、Guide.md、Concept.md、Tool.md、Runbook.md 或 Resource.md。
使用必需的 frontmatter 创建文档，并保留 type、status、可选的 project、area、created、updated、tags 及其他字段的属性顺序。
按所选模板撰写内容，确保文件名与文档标题一致，并避免空白页面或仅为改变风格而重写技术材料。
添加相关内部 Wikilinks、跨文件夹链接、章节深层链接和相关文档引用，以强化知识图谱。
添加不超过五个小写 kebab-case 标签，涵盖适当的领域、文档类型、状态、技术和项目分类。
验证最终文档的 frontmatter 是否完整、链接是否可解析、外部链接文本是否具有描述性、代码围栏是否注明语言、日期是否准确，以及是否包含必需的领域和类型标签。
内容过时后，将其移至正确的归档位置，将状态更新为 archived 或 deprecated，并链接替代或取代该内容的文档。

配置指南

如果仓库未存放在文档指定的默认路径，请设置仓库位置。
export OBSIDIAN_VAULT_PATH="/path/to/your/obsidian-vault"
确保仓库包含主要分区 00 Meta/、01 Projects/、02 Shared Knowledge/、03 Resources/ 和 04 Archives/。
将规范模板保存在 00 Meta/Templates/ 中，包括项目、架构、指南、API 参考、测试、部署、ADR、决策、研究、概念、工具、运行手册、维护和资源模板。
对于项目，在 01 Projects/{Project}/ 下创建其目录，并从 Project Overview.md 开始。
对于可重复使用的知识，在 02 Shared Knowledge/ 下使用适当的 Concept.md 或 Tool.md 模板。
填写必需的 YAML frontmatter，包括当前日期、有效状态、适当领域、相关标签，以及适用时的项目关联。
无需安装软件包或使用外部服务；此工作流直接操作已配置的 Obsidian 仓库及其中的 Markdown 文件。
Obsidian 文档工作流 数据架构与分类体系
仓库组织
位置 用途 00 Meta/ 仓库规范、模板和指南 01 Projects/{Project}/ 项目专属文档 02 Shared Knowledge/ 可重复使用的工程模式和技术知识 03 Resources/ 外部参考资料 04 Archives/Deprecated/ 过时的技术、模式或工具 04 Archives/Superseded/ 被更新或整合后的文档取代的文档 04 Archives/Historical/ 已完成的评审、旧决策和历史快照 项目文档结构
典型项目包含 Project Overview.md、Architecture & Tech Stack.md、Development Guide.md、Component & API Reference.md、Testing Guide.md、Deployment & Infrastructure.md、Maintenance Board.md、Changelog.md，以及按需添加的架构、服务、数据库或指南文档。
Frontmatter 字段
type：Project、architecture、guide、reference、research、runbook、maintenance、changelog、concept 或 tool 分类。
status：active、archived 或 deprecated；标签约定中也可以使用 draft。
project：项目范围文档的项目名称。
area：例如 frontend、backend、infra、security、testing、devops 或 patterns。
created 和 updated：ISO 格式的文档日期。
tags：最多五个小写 kebab-case 标签，涵盖技术、领域、类型、状态和项目背景。
related_projects：共享知识或跨项目知识所关联的项目名称。
链接和文件规则
内部链接使用 [[Document Name]]，跨文件夹链接使用 [[Folder/Document Name]]，章节深层链接使用 [[Document Name#Section Heading]]。标题必须与去掉 .md 扩展名后的文件名一致，文档内容应以英语为主。

高级特性

基于范围的分类可区分项目实现、可重复使用的知识和外部参考资料。
规范模板确保项目和共享知识中的文档结构保持一致。
元数据分类体系支持文档类型、生命周期状态、技术领域、技术和项目标签。
知识图谱链接支持标准 Wikilinks、跨文件夹引用、双向关系和标题级深层链接。
生命周期验证会检查 frontmatter 完整性、文件名与标题是否一致、Wikilinks 是否失效、外部链接描述、代码块语言、日期和必需标签。
安全归档可保留技术历史，并将已弃用、已取代和历史材料分别归档。
防护措施可避免破坏性删除、空白占位文档、非规范模板结构，以及对技术内容进行不必要的重写。
多语言处理会让文档以英语为主，同时翻译或总结波斯语源材料。
此工作流以文件系统为基础且轻量，无需安装软件包或集成外部 API。

name: obsidian-doc-workflow description: Create, update, classify, and archive Obsidian documentation documents following structured vault conventions and templates. version: 1.0.2

Obsidian Documentation Workflow

This skill manages structured documentation in an Obsidian vault following a formal documentation system with strict conventions.

Vault Path

Resolved vault path is typically(Mac): ${OBSIDIAN_VAULT_PATH:-/Users/${USER}/.obsidian}

The vault uses three main sections:

01 Projects/ - Project-specific documentation 02 Shared Knowledge/ - Reusable engineering patterns 00 Meta/ - Vault standards, templates, and guidance

Document Creation

For Project Documents

Use the project root template. Always start with Project Overview.md in the project root, then architecture, guides, API reference, and so on.

Example project structure:

01 Projects/{Project}/ ├── Project Overview.md
├── Architecture & Tech Stack.md
├── Development Guide.md
├── Component & API Reference.md
├── Testing Guide.md
├── Deployment & Infrastructure.md
├── Maintenance Board.md
├── Changelog.md
└── , , , , etc.

Standard frontmatter: ```yaml
type: project|architecture|guide|reference|research|runbook|maintenace|changelog project: "Project Name" status: active|archived|deprecated area: frontend|backend|infra|security|testing|devops created: 2026-09-19 updated: 2026-09-19 tags: [project-slug, area, type] related_projects: []

For Shared Knowledge Documents

Use the Concept.md or Tool.md templates.

Standard frontmatter:

---
type: concept|tool|architecture|guide
status: active|archived
area: patterns|frontend|backend|testing|devops
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags: [category, subcategory, type]
related_projects: [Project A, Project B]
---

### Classification Rules

### Project vs Shared Knowledge

Project knowledge → 01 Projects/{Project}/ (obsoletes when project disappears)
Reusable patterns → 02 Shared Knowledge/ (remains useful after projects are gone)

### Residence Categories

Project-specific implementations → Project folder
General patterns, tech guides, security practices, deployment strategies → Shared Knowledge
External references → 03 Resources/

Examples:

Backend Integration Guide (specific to a project) → Project folder
Monorepo Patterns (any team can use) → Shared Knowledge
Vercel deployment docs → Resources

## Templates

Respective templates in 00 Meta/Templates/:

Project Overview.md
Architecture.md
Development Guide.md
Technical Guide.md
API Reference.md
Testing Guide.md
Deployment & Infrastructure.md
ADR.md
Decision.md
Research.md
Concept.md
Tool.md
Runbook.md
Maintenance Item.md
Resource.md

## Linking Rules

Use Wikilinks [[Document Name]] for internal links
Cross-folder links: [[Folder/Document Name]]
Deep links: [[Document Name#Section Heading]]
Never create giant navigation pages — use links to build a knowledge graph

## Tagging Convention

Tags are lowercase, kebab-case, max 5 tags per document.