一套指导 AI Coding Agent 进行 Obsidian 定制开发的工程 Skill：先理解 Obsidian 的层级架构和用户现有工作台，再选择正确的实现层，完成开发并在真实 Obsidian 中验收。
如果你想让 AI 帮你定制 Obsidian，这套 Skill 会告诉 AI 应该先看什么、在哪一层开发、哪些东西不能乱动，以及做到什么程度才算真的完成。
AI 会写 TypeScript、CSS 和脚本，但它未必理解 Obsidian。
一个真实的 Obsidian 工作台可能同时包含 Markdown、Properties、Canvas、core plugins、社区插件、本地插件、主题、CSS snippets、命令、快捷键、系统自动化和外部发布服务。没有一套 Obsidian 专用框架时，AI 很容易：
- 没找到真正生效的控制点就开始改代码；
- 重复开发已有设置或插件已经提供的能力；
- 把 UI 症状一律当成 CSS 问题；
- 覆盖用户内容、Canvas 布局或已有改动；
- 把语法通过、构建成功或按钮出现当成功能完成；
- 从故障现象直接猜根因；
- 在没有确认的情况下上传、部署或公开发布。
这个 Skill 不替你实现某一个固定功能。它给 AI 一套从理解、选路、开发到验收的完整方法。
- 第一次想用 Codex、Claude Code 等 Agent 定制 Obsidian；
- 已经做过一些插件、CSS、Canvas 或自动化，希望继续扩展；
- 过去让 AI 改过很多地方，现在控制点和依赖关系已经不清楚；
- 正在排查插件加载、主题冲突、刷新、快捷键或发布链路问题；
- 准备把自己的 Obsidian 定制整理成可维护、可交付的项目。
它不是 Obsidian 入门教程、知识管理方法论或插件 API 替代品。
目标与工作流
↓
内容与数据
Markdown、Properties、附件、Canvas
↓
Obsidian 核心能力
Core plugins、Settings、Commands、Workspace
↓
扩展与呈现
本地/社区插件、主题、Style Settings、CSS snippets
↓
交互与运行
Views、Commands、Events、Hotkeys、状态与刷新
↓
系统集成
URI、命令行、系统自动化、脚本与定时任务
↓
外部服务与交付
图床、GitHub、Blog、API、部署与插件市场
AI 先定位需求在哪一层，再决定应该配置、复用、扩展插件、新建插件、做系统集成，还是建立独立发布链路。
- 从零开发：只有目标，还没有实现。
- 扩展已有能力：继续修改现有插件、主题、snippet、Canvas 或自动化。
- 梳理并接手已有定制：先盘点过去的实现、依赖、重复能力和风险，再决定保留、整合或重写。
- 故障诊断：沿因果链找到首次偏离点，不从现象猜根因。
- 发布交付：脱敏、审计、发布并从远端回读。
建立当前工作台画像
→ 找到真实入口、真相源和控制点
→ 判断最小正确实现路线
→ 建立变更合同和保护对象
→ 在隔离环境实现与测试
→ Reload / Restart 并检查运行状态
→ 从真实 GUI 入口完成操作
→ 回读最终文件或外部结果
→ 审计越界变化与敏感信息
验证被拆成五层：
- 源码
- 产物
- 加载
- 交互
- 最终结果
最高通过哪一层，AI 就只能声称到哪一层。
使用 $develop-obsidian-workbench，帮我判断这个功能应该配置现有插件、扩展本地插件，还是新建插件。
使用 $develop-obsidian-workbench，先梳理并接手我以前做过的 Obsidian 定制，不要直接重写。
使用 $develop-obsidian-workbench，排查插件文件已经写好但 Obsidian 中没有生效的问题。
使用 $develop-obsidian-workbench，为我的 Canvas 工作台设计功能；先保护现有节点、连线和布局。
将 develop-obsidian-workbench/ 复制到支持 Skills 的 Agent 目录。例如项目级安装：
your-project/
└── .agents/
└── skills/
└── develop-obsidian-workbench/
如果你的工具使用其他 Skill 目录，请按对应产品的约定安装。安装后可显式调用：
$develop-obsidian-workbench
develop-obsidian-workbench/
├── SKILL.md
├── agents/openai.yaml
├── references/
│ ├── obsidian-architecture.md
│ ├── official-baseline.md
│ ├── workspace-profile.md
│ ├── control-points.md
│ └── scenario-playbooks.md
└── scripts/
├── inspect-obsidian-scope.sh
├── validate-change-contract.sh
├── verify-plugin-runtime.sh
├── audit-change-scope.sh
└── scan-sensitive-info.sh
- 优先使用独立开发 vault，不直接在主 vault 试错。
- 不自动覆盖用户已有改动。
- 不把真实内容、Canvas 布局和开放文件真相源当可随意重建的缓存。
- 外部上传、付费 API、部署和公开发布需要明确授权。
- 公开交付前扫描并人工检查路径、账户、凭据、内部 URL、截图和 Git 历史。
工程基线优先采用 Obsidian 官方 Developer Docs、Help 和团队公开规范；CEO 或社区成员的公开写作只作为设计原则或候选惯例，不包装成官方强制规范。
当前版本来自真实定制问题复盘、脚本正反测试和多轮独立前向验证。它提供的是通用开发基线，不保证任何单一 vault、插件或平台可以跳过当前环境发现与真实运行验收。
MIT