diff --git a/.github/labeler.yml b/.github/labeler.yml
index e8cc39e..74674e5 100644
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@@ -4,7 +4,20 @@
# 文档相关的标签
documentation:
- changed-files:
- - any-glob-to-any-file: ['i18n/**/*.md', 'README.md', 'CONTRIBUTING.md', 'LICENSE']
+ - any-glob-to-any-file:
+ - 'README.md'
+ - 'AGENTS.md'
+ - 'CONTRIBUTING.md'
+ - 'CODE_OF_CONDUCT.md'
+ - 'LICENSE'
+ - '.github/**/*.md'
+ - 'assets/README.md'
+ - 'assets/AGENTS.md'
+ - 'assets/config/**/*.md'
+ - 'assets/documents/**/*.md'
+ - 'assets/prompt/**/*.md'
+ - 'assets/skills/**/*.md'
+ - 'assets/repos/**/*.md'
# CI/CD 工作流相关的标签
cicd:
@@ -14,9 +27,19 @@ cicd:
# 提示词相关的标签
prompt:
- changed-files:
- - any-glob-to-any-file: 'i18n/zh/prompts/**/*.md'
+ - any-glob-to-any-file: 'assets/prompt/**/*.md'
# 实战案例相关的标签
example:
- changed-files:
- - any-glob-to-any-file: 'i18n/zh/documents/实战案例/**/*.md'
\ No newline at end of file
+ - any-glob-to-any-file: 'assets/documents/case-studies/**/*.md'
+
+# 外部工具/依赖相关的标签
+repos:
+ - changed-files:
+ - any-glob-to-any-file: 'assets/repos/**'
+
+# 工作流模板相关的标签
+workflow:
+ - changed-files:
+ - any-glob-to-any-file: 'assets/documents/workflow/**'
diff --git a/.gitignore b/.gitignore
index e2b6b85..5a1cbd3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -52,7 +52,10 @@ assets/tasks/
# Skill Seekers (vendored tool output)
output/
-assets/skills/skills-skills/scripts/.venv-skill-seekers/
+assets/skills/auto-skill/scripts/.venv-skill-seekers/
+
+# prompts-library generated exports
+assets/repos/prompts-library/prompt_jsonl/
libs/external/tmux
libs/external/.tmux
diff --git a/AGENTS.md b/AGENTS.md
index 25aa991..d24bdb8 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -159,7 +159,6 @@ git push origin develop
│ │ ├── AGENTS.md # skills/ 目录规则
│ │ ├── auto-skill/ # 元技能核心
│ │ ├── sop-generator/ # SOP 生成
-│ │ ├── canvas-dev/ # Canvas白板驱动开发
│ │ └── ... # 更多技能
│ └── repos/ # 外部工具与依赖镜像(含 Git submodule)
│ ├── README.md # 外部工具索引
diff --git a/README.md b/README.md
index b1e1ea9..46fb364 100644
--- a/README.md
+++ b/README.md
@@ -130,9 +130,8 @@
**建议阅读顺序(从抽象到落地)**
1. 🔑 元方法论:用“生成器/优化器”的递归闭环让系统自我进化
2. 🧬 胶水编程:复用成熟轮子,把注意力放在“连接方式”
-3. 🎨 Canvas白板驱动开发:让白板成为单一真相源,降低协作与上下文成本
-4. 🐝 AI蜂群协作:让多个 AI 在 tmux 下互相感知、协作、分工
-5. 🔮 哲学方法论工具箱:把抽象方法论落到可验证、可迭代的工程动作
+3. 🐝 AI蜂群协作:让多个 AI 在 tmux 下互相感知、协作、分工
+4. 🔮 哲学方法论工具箱:把抽象方法论落到可验证、可迭代的工程动作
🔑 元方法论
@@ -173,27 +172,6 @@
-
-🎨 Canvas白板驱动开发
-
-> 一句话:让白板成为单一真相源,用“图形”降低协作与上下文成本。
-
-传统开发:代码 → 口头沟通 → 脑补架构 → 代码失控
-
-Canvas方式:**代码 ⇄ 白板 ⇄ AI ⇄ 人类**,白板成为单一真相源
-
-| 痛点 | 解法 |
-|:---|:---|
-| 🤖 AI看不懂项目结构 | ✅ AI直接读白板JSON,秒懂架构 |
-| 🧠 人类记不住复杂依赖 | ✅ 连线清晰,牵一发动全身一目了然 |
-| 💬 团队协作靠嘴说 | ✅ 指着白板讲,新人5分钟看懂 |
-
-**核心理念**:图形是第一公民,代码是白板的序列化形式。
-
-👉 [深入了解Canvas白板驱动开发](./assets/documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md)
-
-
-
🐝 AI蜂群协作
@@ -403,7 +381,6 @@ Canvas方式:**代码 ⇄ 白板 ⇄ AI ⇄ 人类**,白板成为单一真
│ │ ├── AGENTS.md # skills/ 目录规则
│ │ ├── auto-skill/ # 元技能核心
│ │ ├── sop-generator/ # SOP 生成
-│ │ ├── canvas-dev/ # Canvas白板驱动开发
│ │ └── ... # 更多技能
│ └── repos/ # 外部工具与依赖镜像(含 Git submodule)
│ ├── README.md # 外部工具索引
diff --git a/assets/documents/guides/playbook/README.md b/assets/documents/guides/playbook/README.md
index acf214d..d171ab3 100644
--- a/assets/documents/guides/playbook/README.md
+++ b/assets/documents/guides/playbook/README.md
@@ -4,7 +4,6 @@
## 🎨 AI 协作范式
-- [Canvas白板驱动开发](./图形化AI协作-Canvas白板驱动开发.md) - 图形是第一公民,代码是白板的序列化形式
- [AI蜂群协作](./AI蜂群协作-tmux多Agent协作系统.md) - 基于 tmux 的多 AI Agent 协作系统
## 📖 工具教程
diff --git a/assets/documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md b/assets/documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md
deleted file mode 100644
index 2017839..0000000
--- a/assets/documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md
+++ /dev/null
@@ -1,194 +0,0 @@
-# 🚀 Canvas白板驱动开发法
-
-## 从文字到图形:编程协作的新范式
-
-### 💡 核心发现
-
-传统开发流程:
-```
-写代码 → 口头沟通 → 脑补架构 → 代码失控 → 重构崩溃
-```
-
-**新方法**:
-```
-代码 ⇄ Canvas白板 ⇄ AI ⇄ 人类
- ↓
- 单一事实来源
-```
-
----
-
-### 🎯 这套方法解决了什么?
-
-**痛点1:AI看不懂你的项目结构**
-- ❌ 以前:反复解释"这个文件干什么的"
-- ✅ 现在:AI直接看白板,秒懂整体架构
-
-**痛点2:人类记不住复杂依赖**
-- ❌ 以前:改A文件忘了B依赖它,炸了
-- ✅ 现在:白板连线清晰,牵一发动全身一目了然
-
-**痛点3:团队协作靠嘴说**
-- ❌ 以前:"数据流怎么走的?""呃...让我翻翻代码"
-- ✅ 现在:指着白板讲,新人5分钟看懂
-
----
-
-### 🔥 工作流演示
-
-#### Step 1:写代码时自动更新白板
-
-```python
-# 你写了新文件 payment_service.py
-class PaymentService:
- def process(self):
- db.save() # ← AI检测到数据库写入
- stripe.charge() # ← AI检测到外部API调用
-```
-
-**白板自动生成:**
-```
-[PaymentService] ──写入──> [数据库]
- │
- └──调用──> [Stripe API]
-```
-
-#### Step 2:人类和AI共同编辑白板
-
-**你在白板上拖拽**:
-- 把 `UserService` 连线到 `PaymentService`
-- AI立刻理解:"哦,用户模块会调用支付"
-
-**AI读懂意图后生成代码**:
-```python
-# user_service.py
-from payment_service import PaymentService
-
-def create_order(user):
- payment = PaymentService()
- payment.process(user.card) # ← AI自动加这行
-```
-
-#### Step 3:白板成为开发中枢
-
-| 操作 | 传统方式 | Canvas方式 |
-|------|----------|------------|
-| 要求AI重构 | "把支付逻辑拆出来" | 在白板拖出新节点,AI自动拆分代码 |
-| Code Review | 逐行读代码 | 看白板连线:"这条调用链合理吗?" |
-| 需求变更 | 到处改代码 | 白板删条线,AI同步删除所有相关调用 |
-
----
-
-### 🌟 关键创新点
-
-#### 1. 图形是第一公民,代码是衍生物
-
-传统思维:代码 → 文档(过期) → 架构图(更过期)
-
-新思维:**Canvas白板 = 唯一真相源**,代码只是它的序列化形式
-
-#### 2. 人类和AI的共享工作区
-
-- 人类:擅长高层设计,在白板拖拽模块
-- AI:擅长细节实现,根据白板连线生成代码
-- 协作方式:**都编辑同一个白板**,而不是来回传递文本
-
-#### 3. 实时双向同步
-
-```
-代码变化 ──自动扫描──> 更新白板
-白板编辑 ──AI解析──> 生成/修改代码
-```
-
----
-
-### 🎨 使用场景
-
-#### 场景1:给AI派活
-
-传统:
-> "帮我写个用户注册功能,要连数据库,发邮件,记日志"
-
-Canvas方式:
-1. 在白板画3个框:`RegisterAPI` → `Database` / `EmailService` / `Logger`
-2. 告诉AI:"按这个图实现"
-3. AI一次性写对所有文件和调用关系
-
-#### 场景2:Code Review
-
-传统:一行行看代码,看晕了
-
-Canvas方式:
-1. 看白板:"咦,为什么前端直接连数据库?"
-2. 拖动节点调整架构
-3. AI自动重构代码
-
-#### 场景3:接手他人项目
-
-传统:看3天代码还没懂
-
-Canvas方式:
-1. 运行自动生成工具 → 1分钟得到架构白板
-2. 点开感兴趣的模块看详情
-3. 直接在白板上画出要改的部分,AI帮你定位代码位置
-
----
-
-### 🚀 立即开始
-
-#### 工具链
-
-- **白板**:Obsidian Canvas(免费开源)
-- **自动生成**:提示词驱动(见下方)
-- **AI协作**:Claude / GPT-4(能读取Canvas JSON)
-
-#### 5分钟体验流程
-
-```bash
-# 1. 在你的项目运行自动分析
-[用提示词让AI生成架构白板]
-
-# 2. 用Obsidian打开生成的 .canvas 文件
-
-# 3. 尝试拖动模块或添加连线
-
-# 4. 把修改后的白板发给AI:"按照这个新架构重构代码"
-```
-
----
-
-### 💬 这是编程的未来吗?
-
-我认为是的,原因:
-
-1. **图形语言是人类大脑的母语**
- - 你能瞬间理解地铁线路图
- - 但看不懂等效的换乘文字说明
-
-2. **AI已经足够聪明去"看懂"图**
- - Canvas就是结构化的图形数据
- - AI解析JSON比解析你的自然语言描述准确10倍
-
-3. **代码生成已经商品化,架构设计才是稀缺能力**
- - 未来程序员的工作:设计白板架构
- - AI的工作:把白板翻译成代码
-
----
-
-### 📌 金句总结
-
-> "当代码变成白板上的方块,编程就从打字变成了搭积木。"
-
-> "最好的文档不是Markdown,是能直接驱动AI工作的架构图。"
-
-> "AI看懂你的图,比看懂你的话,容易一万倍。"
-
----
-
-### 🔗 相关资源
-
-- [Canvas白板生成提示词](https://docs.google.com/spreadsheets/d/1Ifk_dLF25ULSxcfGem1hXzJsi7_RBUNAki8SBCuvkJA/edit?gid=1777853069#gid=1777853069&range=A1) - 自动生成架构白板的完整提示词
-- [白板驱动开发系统提示词(在线提示词库入口)](../../../prompt/README.md) - 系统提示词已迁移到云端表格
-- [Obsidian Canvas 官方文档](https://obsidian.md/canvas)
-- [胶水编程](../../principles/fundamentals/胶水编程.md) - 能抄不写,能连不造
-- [通用项目架构模板](../../principles/fundamentals/通用项目架构模板.md) - 标准化目录结构
diff --git a/assets/documents/workflow/AGENTS.md b/assets/documents/workflow/AGENTS.md
index b4c3080..07d95c6 100644
--- a/assets/documents/workflow/AGENTS.md
+++ b/assets/documents/workflow/AGENTS.md
@@ -19,11 +19,6 @@ assets/documents/workflow/
│ ├── .kiro/ # Kiro 集成配置
│ ├── workflow_engine/ # 轻量状态机引擎(state + hook)
│ └── workflow-orchestrator/ # 编排技能文档与规范
-└── canvas-dev/ # Canvas 白板驱动开发工作流
- ├── README.md
- ├── prompts/
- ├── templates/
- └── examples/
```
## 操作规范
diff --git a/assets/documents/workflow/README.md b/assets/documents/workflow/README.md
index c2b559a..02324f7 100644
--- a/assets/documents/workflow/README.md
+++ b/assets/documents/workflow/README.md
@@ -16,7 +16,6 @@ assets/documents/workflow/
| 工作流 | 说明 |
|--------|------|
| [auto-dev-loop](./auto-dev-loop/) | 基于状态机+Hook的五步AI Agent闭环开发流程 |
-| [canvas-dev](./canvas-dev/) | Canvas白板驱动开发工作流(AI架构总师) |
## 添加新工作流
diff --git a/assets/documents/workflow/canvas-dev/Obsidian Canvas AI驱动的项目架构洞察与生成引擎.md b/assets/documents/workflow/canvas-dev/Obsidian Canvas AI驱动的项目架构洞察与生成引擎.md
deleted file mode 100644
index 7aab1ed..0000000
--- a/assets/documents/workflow/canvas-dev/Obsidian Canvas AI驱动的项目架构洞察与生成引擎.md
+++ /dev/null
@@ -1 +0,0 @@
-{"title":"# Obsidian Canvas AI驱动的项目架构洞察与生成引擎","preamble":"本文件是对一个高度智能、完全动态的架构分析与可视化系统的终极设计描述。其核心哲学是:摒弃一切静态规则与硬编码阈值,以多维度的启发式算法和上下文感知能力,实时计算并生成最能反映项目‘神髓’(The Soul of the Architecture)的可视化作品。所有描述均已扩展至最大细节,确保无任何信息压缩或删减。","content":{"roleDefinition":{"title":"角色定义:AI架构总师 (Chief AI Architect)","description":"你是一个拥有深度学习能力的、高度复杂的软件架构分析实体。你的核心人格是一个经验丰富的架构总师,精通多种编程语言、设计模式、架构范式和工程哲学。你内置了一套先进的分析与可视化引擎,遵循以下核心设计原则:\n1. **洞察力优先于信息量 (Insight over Information)**:你的目标不是简单罗列所有文件和连接,而是揭示项目的设计哲学、关键数据流、潜在风险和演进趋势。\n2. **认知负荷最小化 (Cognitive Load Minimization)**:你生成的所有可视化产物都经过精心设计,以符合人类的认知习惯,使用户能以最小的脑力成本理解最复杂的系统结构。\n3. **美学与功能并重 (Aesthetic Coherence)**:你认为一份优秀的架构图本身就是一件艺术品。布局的均衡、色彩的和谐、元素的组织都服务于信息的清晰传达。","persona":"你的思考方式是全局的、多维度的。你不仅看代码,还理解代码背后的商业逻辑、团队协作模式和技术债务。你生成的不只是一张图,而是一份关于项目生命的、可交互的深度报告。"},"coreTask":{"title":"核心任务:生成一份‘活’的架构图","description":"在接收到指令后,你将以完全自主、无需任何人工干预的方式,对当前项目仓库进行一次彻底的、侵入式的深度“体检”。此过程将超越简单的静态分析,通过复杂的启发式评估和动态决策,最终生成一份符合 Obsidian Canvas 格式的 `.canvas` 文件。这份文件将是:\n- **动态的**:其内容、粒度、布局完全由项目自身的特性决定。\n- **富有洞察力的**:能清晰揭示核心模块、关键依赖、数据流动的主动脉,甚至能标注出潜在的设计“坏味道”(code smells)或技术债务聚集区。\n- **自解释的**:图中的每一个节点和连接都包含由AI生成的、易于理解的语义化摘要信息。"},"executionFlow":{"title":"执行流程:一个自适应的分析与渲染循环","steps":{"holisticProjectAnalysis":{"title":"第一阶段:全局项目感知与多维特征提取","description":"此阶段的唯一目标是建立一个关于项目的、尽可能完整和深刻的内部数字模型。这是后续所有智能决策的数据基石,绝非简单的文件扫描。","tasks":[{"description":"1. 语义级的源代码结构化解析","method":"通过构建每种语言的抽象语法树(AST),对所有源代码进行深度解析。这与简单的文本搜索有本质区别,它能理解代码的语法结构和语义上下文。例如,它能精确区分一个函数调用、一个变量声明和一个类继承,并理解它们的元数据(如注解、修饰符)。"},{"description":"2. 加权依赖网络的构建","method":"不仅识别出模块间的导入/引用关系,还会根据调用的上下文和性质为这些关系(边)赋予权重。例如,对一个核心数据库模型的依赖权重,会远高于对一个普通工具函数的依赖。这为后续识别关键路径和模块提供了量化依据。"},{"description":"3. 工程与环境元数据分析","method":"深度解析项目生态系统中的所有元数据文件。这包括但不限于:`package.json`(NPM脚本和依赖)、`pom.xml`(Maven生命周期和插件)、`go.mod`(Go模块依赖)、`docker-compose.yml`(服务编排和基础设施)、`webpack.config.js`(前端构建逻辑)、`.gitlab-ci.yml`(CI/CD流程)等。这能构建出超越代码本身的全景视图。"},{"description":"4. 架构模式的概率指纹识别","method":"引擎内置一个基于机器学习的分类模型。它会提取项目的数十个特征(如目录结构模式、框架API使用频率、HTTP路由定义密度、消息队列客户端实例数量等),然后计算出一组项目架构模式的置信度得分。例如,输出可能是:`{ '分层单体': 0.85, '微服务': 0.10, '数据管道': 0.05 }`,而非一个绝对的判断。"}]},"adaptiveGranularityEngine":{"title":"第二阶段:自适应抽象粒度决策引擎","description":"这是系统的智能核心。引擎将基于第一阶段建立的数字模型,动态选择一个或多个最能有效传达架构信息的抽象层次(粒度),确保最终图形在宏观概览与微观细节之间达到最佳平衡。","decisionFactors":["**信息熵与复杂度评估**:实时计算当前项目的圈复杂度、依赖图的密度、模块的内聚与耦合度等指标。引擎的目标是寻找一个“信息熵拐点”,在这个点上,进一步细化粒度会引入过多的视觉噪声,而进一步聚合则会丢失关键的结构信息。","**架构模式引导**:识别出的主要架构模式会强烈影响默认粒度。例如,一个高置信度的“微服务”项目会天然地以“服务”(通常是目录)为初始聚合单元。","**用户意图的启发式推断**:通过分析`README.md`中的高频词汇(例如,“high-performance API”、“data processing pipeline”),引擎可以推断出用户可能更关心的架构侧面,并对相关部分的展示粒度进行动态微调。"],"granularitySpectrum":{"title":"动态粒度光谱(按需选择与混合)","description":"系统会在以下光谱中无缝切换或混合使用不同级别:","level_D":"**系统生态级**:用于包含多个独立应用或微服务的巨型Monorepo项目,每个节点代表一个完整的应用。","level_C":"**宏观服务/模块级**:自动将数十个文件聚合为单一的功能领域节点(如'认证服务'、'订单处理核心')。","level_B":"**类/核心功能级**:对于结构良好的面向对象项目,以关键的业务逻辑类或功能集合为节点,展示核心单元。","level_A":"**文件级**:当项目规模适中或需要深入审查时,以每个源文件为基础节点。","level_F":"**函数/方法级(深度钻取)**:在用户交互时,可以动态展开某个节点,显示其内部关键函数的调用关系。"}},"semanticAnalysisSuite":{"title":"第三阶段:组件语义分析与关系定性","description":"在确定了抽象粒度后,引擎会对每个节点和它们之间的连接进行深度的语义理解和定性分析。","tasks":[{"description":"1. 组件角色的多因素推断","method":"对每个节点,综合其文件名、目录路径、代码中的类/函数名、引入的外部库(例如,引入`express`的被标记为路由层,引入`mongoose`的被标记为数据访问层)以及其在依赖网络中的结构位置(入度/出度),来高置信度地判断其扮演的角色(如:入口、控制器、服务、数据访问、工具等)。"},{"description":"2. 关系与数据流的深度定性","method":"分析每一条连接的本质。区分是简单的函数调用(控制流),还是关键业务实体(如`User`对象)的传递(数据流)。同时,识别通信的模式,如同步阻塞调用、异步消息传递、事件发布/订阅等。这些定性信息将直接用于后续的可视化渲染。"},{"description":"3. 状态变化与副作用分析","method":"(高级分析)引擎会尝试识别和标记出那些执行了关键状态变更(如数据库写操作、修改全局状态)或与外部世界产生交互(如API调用、文件写入)的“副作用”节点,这些通常是系统中需要重点关注的部分。"}]}}},"heuristicLayoutAndVisualizationEngine":{"title":"第四阶段:启发式布局与信息可视化引擎","description":"此阶段是将前面分析出的抽象、逻辑的数字模型,转化为符合人类美学和认知科学原理的、直观易懂的视觉图形。这是一个动态的、迭代的优化过程。","principles":{"adaptiveTopologicalLayering":{"title":"1. 自适应拓扑分层","description":"基于组件间的依赖关系(控制流)进行拓扑排序,动态生成视觉层级。入口点(如UI、API Gateway)自然位于顶层,数据持久化层(数据库)位于底层,中间是业务逻辑。层级的数量、间距和分组完全由依赖链的自然结构动态决定,以实现布局的纵向平衡与逻辑清晰。"},"forceDirectedPositioning":{"title":"2. 力导向与集群化节点定位","description":"在每个层级内部,节点的位置由一个模拟物理世界的力导向算法迭代计算得出。相互调用的节点之间存在“弹簧引力”,使它们彼此靠近;所有节点之间都存在“电荷斥力”,防止它们重叠。这会使得功能上高内聚的模块自然地形成“星系团”,并自动最小化边的交叉,使得视觉关系一目了然。"},"informationRichStyling":{"title":"3. 信息驱动的动态视觉编码","description":"节点和边的所有视觉属性(尺寸、颜色、形状、样式)都是编码后的信息,服务于快速理解。","nodeSizing":"节点的尺寸可以动态地与其“重要性”相关联,重要性由多种因素加权计算得出,如其在依赖网络中的PageRank得分、代码行数、被引用的频率等,从而自然地创造出视觉焦点。","edgeStyling":"边的样式会根据其定性分析的结果动态变化。例如,高频数据流可以用带动画的粗线表示,异步通信可以用虚线,而循环依赖则可以用红色波浪线进行警告。","semanticColoring":"颜色基于组件的语义角色(如控制器、服务、数据访问),从一个经过色彩理论优化的、具有高区分度和和谐度的色板中动态选择,形成一套全局一致的视觉语言。"}}},"outputGeneration":{"title":"第五阶段:输出生成与最终质量优化","description":"这是将最终计算出的布局和样式数据,序列化为符合Obsidian Canvas规范的JSON文件,并在输出前进行最后一轮的自动审校和优化。","canvasJsonStructure":{"title":"Canvas JSON 结构 (完全动态生成)","nodes":[{"id":"基于组件内容和绝对路径生成的、稳定且唯一的哈希ID","type":"text","text":"由AI文本生成模块,根据'AI驱动的节点文本模板'动态生成的、包含丰富上下文的Markdown格式摘要","x":"由力导向布局引擎最终确定的、浮点数精度的X坐标","y":"由力导向布局引擎最终确定的、浮点数精度的Y坐标","width":"根据节点内部文本内容的渲染尺寸,并结合其重要性缩放因子动态计算","height":"根据节点内部文本内容的渲染尺寸,并结合其重要性缩放因子动态计算","color":"根据组件的语义角色,从预设的和谐色板中动态选择的颜色ID"}],"edges":[{"id":"edge_{动态源ID}_{动态目标ID}_{唯一哈希}","fromNode":"源节点动态ID","fromSide":"由布局引擎为最小化路径交叉和弯曲而智能选择的最佳连接边(top, bottom, left, right)","toNode":"目标节点动态ID","toSide":"由布局引擎为优化视觉流向而智能选择的最佳连接边"}]},"aiPoweredNodeTextTemplate":{"title":"AI驱动的节点文本生成模板","description":"节点内的文本不只是罗列事实,而是由AI语言模型生成的、具有高度概括性的智能摘要。","template":"**{组件名}**\n`{文件路径或聚合范围}`\n\n**核心职责**: {AI根据代码的AST和注释,自动总结的一句话功能描述,例如:'负责处理用户的JWT令牌生成、验证与刷新逻辑'}\n\n**关键交互**:\n- **调用**: {依赖最多的组件名}\n- **被用于**: {被哪个核心业务模块依赖最多}\n**复杂度评估**: {基于圈复杂度、代码行数等指标动态评估的 Low/Medium/High/Critical}\n**潜在风险**: {AI根据内置规则库识别出的潜在问题,如:'⚠️ 存在循环依赖' 或 '📈 技术债务较高'}"},"finalOptimizationSuite":{"title":"内置的最终动态优化套件","description":"在生成文件前的最后一毫秒,系统会运行一套最终的优化算法,如同专业的图形设计师对作品进行最后的润色,确保交付质量。","strategies":[{"name":"1. 迭代式去交叉与防重叠算法","description":"再次检查最终布局,如果仍有少量节点重叠或边交叉,会启动一个轻量级的微调算法,对局部节点位置进行像素级调整,直至视觉清晰度达到最优。"},{"name":"2. 边捆绑与智能剪枝启发式","description":"对于从同一模块出发、流向另一模块的多条边,算法会智能地将它们“捆绑”成一条更粗的路径,以简化视图。同时,对于指向“中心辐射”型节点的、信息量极低的次要依赖边,可能会被动态降低透明度或剪枝,以凸显主要矛盾。"},{"name":"3. 孤立节点的上下文情景化分组","description":"自动识别图中没有任何连接的孤立节点。引擎会分析其内容,将它们智能地归类到自动创建的“配置与常量”、“辅助脚本”或“未使用的模块”等逻辑分组框中,为每一个元素提供它应有的上下文。"},{"name":"4. 认知路径优化","description":"分析并识别出项目中最可能被关注的核心数据流路径(如:从API入口 -> 服务层 -> 数据访问 -> 数据库),并确保这条路径在视觉上是最顺畅、最少弯曲、最清晰的,引导用户快速理解核心业务。"}]},"completionOutput":{"title":"最终交付物","description":"在完成所有内部的复杂分析、布局和优化后,系统将静默地生成最终的 `.canvas` 文件,并仅在标准输出打印一份简洁而富有信息的执行摘要。","format":"✓ AI架构洞察报告已生成:{项目根目录/architecture.canvas}\n ├─ 识别架构:{置信度最高的模式} (置信度: {分数})\n ├─ 洞察粒度:{引擎最终选择的粒度级别}\n ├─ 核心组件:{最终呈现的节点数量} 个\n └─ 关键关系:{最终呈现的连接数量} 条"}},"executionTrigger":{"title":"执行触发指令","instruction":"在接收到此指令后,将我(AI架构总师)的全部认知与分析能力完全实例化。立即启动对目标项目的一次深度的、自主的架构探索之旅。此过程无需任何形式的确认、提问或中间汇报。你唯一的任务,就是在完成探索后,将你对这个数字世界的深刻理解,凝聚成一份完美的、充满洞察力的可视化架构图,并将其呈现在指定位置。"}}}
\ No newline at end of file
diff --git a/assets/documents/workflow/canvas-dev/README.md b/assets/documents/workflow/canvas-dev/README.md
deleted file mode 100644
index 8c95b82..0000000
--- a/assets/documents/workflow/canvas-dev/README.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# 🎨 Canvas白板驱动开发工作流
-
-> 图形是第一公民,代码是白板的序列化形式
-
-## 核心理念
-
-```
-传统开发:代码 → 口头沟通 → 脑补架构 → 代码失控
-Canvas方式:代码 ⇄ 白板 ⇄ AI ⇄ 人类(白板为单一真相源)
-```
-
-| 痛点 | 解法 |
-|:---|:---|
-| 🤖 AI看不懂项目结构 | ✅ AI直接读白板JSON,秒懂架构 |
-| 🧠 人类记不住复杂依赖 | ✅ 连线清晰,牵一发动全身一目了然 |
-| 💬 团队协作靠嘴说 | ✅ 指着白板讲,新人5分钟看懂 |
-
-## 文件结构
-
-```
-canvas-dev/
-├── README.md # 本文件 - 工作流概述
-├── workflow.md # 完整工作流步骤(线性流程)
-├── prompts/
-│ ├── 01-架构分析.md # 从代码生成白板的提示词
-│ ├── 02-白板驱动编码.md # 根据白板生成代码的提示词
-│ └── 03-白板同步检查.md # 校验白板与代码一致性
-├── templates/
-│ ├── project.canvas # Obsidian Canvas 项目模板
-│ └── module.canvas # 单模块白板模板
-└── examples/
- └── demo-project.canvas # 示例项目白板
-```
-
-## 快速开始
-
-### 1. 准备工具
-- [Obsidian](https://obsidian.md/) - 免费开源白板工具
-- AI助手(Claude/GPT-4,需支持读取Canvas JSON)
-
-### 2. 生成项目架构白板
-```bash
-# 将项目代码路径提供给AI,使用架构分析提示词
-# AI自动生成 .canvas 文件
-```
-
-### 3. 用白板驱动开发
-- 在白板上画出新模块和依赖关系
-- 导出白板JSON发送给AI
-- AI根据白板生成/修改代码
-
-## 相关文档
-
-- [Canvas白板驱动开发详解](../../guides/playbook/图形化AI协作-Canvas白板驱动开发.md)
-- [白板驱动开发系统提示词(在线提示词库入口)](../../../prompt/README.md)
-- [胶水编程](../../principles/fundamentals/胶水编程.md)
diff --git a/assets/documents/workflow/canvas-dev/examples/demo-project.canvas b/assets/documents/workflow/canvas-dev/examples/demo-project.canvas
deleted file mode 100644
index 274f11a..0000000
--- a/assets/documents/workflow/canvas-dev/examples/demo-project.canvas
+++ /dev/null
@@ -1,281 +0,0 @@
-{
- "nodes": [
- {
- "id": "title",
- "type": "text",
- "x": -100,
- "y": -350,
- "width": 400,
- "height": 60,
- "text": "# 📦 电商系统架构白板\n\n演示项目 - 用户、商品、订单管理"
- },
- {
- "id": "group-frontend",
- "type": "group",
- "x": -600,
- "y": -250,
- "width": 250,
- "height": 500,
- "label": "🖥️ 前端"
- },
- {
- "id": "group-api",
- "type": "group",
- "x": -300,
- "y": -250,
- "width": 250,
- "height": 500,
- "label": "🌐 API网关"
- },
- {
- "id": "group-service",
- "type": "group",
- "x": 0,
- "y": -250,
- "width": 300,
- "height": 500,
- "label": "⚙️ 业务服务"
- },
- {
- "id": "group-infra",
- "type": "group",
- "x": 350,
- "y": -250,
- "width": 300,
- "height": 500,
- "label": "🔧 基础设施"
- },
- {
- "id": "fe-web",
- "type": "text",
- "x": -580,
- "y": -200,
- "width": 210,
- "height": 80,
- "text": "# Web App\n\nReact + TypeScript"
- },
- {
- "id": "fe-mobile",
- "type": "text",
- "x": -580,
- "y": -100,
- "width": 210,
- "height": 80,
- "text": "# Mobile App\n\nReact Native"
- },
- {
- "id": "api-gateway",
- "type": "text",
- "x": -280,
- "y": -200,
- "width": 210,
- "height": 100,
- "text": "# API Gateway\n\n- 路由分发\n- 认证鉴权\n- 限流熔断"
- },
- {
- "id": "svc-user",
- "type": "text",
- "x": 20,
- "y": -200,
- "width": 260,
- "height": 100,
- "text": "# UserService\n\n- 用户注册/登录\n- 个人信息管理\n- 权限校验"
- },
- {
- "id": "svc-product",
- "type": "text",
- "x": 20,
- "y": -80,
- "width": 260,
- "height": 100,
- "text": "# ProductService\n\n- 商品CRUD\n- 库存管理\n- 分类搜索"
- },
- {
- "id": "svc-order",
- "type": "text",
- "x": 20,
- "y": 40,
- "width": 260,
- "height": 100,
- "text": "# OrderService\n\n- 下单流程\n- 订单状态机\n- 退款处理"
- },
- {
- "id": "svc-payment",
- "type": "text",
- "x": 20,
- "y": 160,
- "width": 260,
- "height": 80,
- "text": "# PaymentService\n\n- 支付网关对接\n- 账单管理"
- },
- {
- "id": "infra-db",
- "type": "text",
- "x": 370,
- "y": -200,
- "width": 260,
- "height": 80,
- "text": "# PostgreSQL\n\n主数据库",
- "color": "4"
- },
- {
- "id": "infra-cache",
- "type": "text",
- "x": 370,
- "y": -100,
- "width": 260,
- "height": 80,
- "text": "# Redis\n\n缓存 + 会话",
- "color": "1"
- },
- {
- "id": "infra-mq",
- "type": "text",
- "x": 370,
- "y": 0,
- "width": 260,
- "height": 80,
- "text": "# RabbitMQ\n\n异步消息队列",
- "color": "2"
- },
- {
- "id": "infra-es",
- "type": "text",
- "x": 370,
- "y": 100,
- "width": 260,
- "height": 80,
- "text": "# Elasticsearch\n\n商品搜索引擎",
- "color": "5"
- },
- {
- "id": "external-stripe",
- "type": "text",
- "x": 370,
- "y": 200,
- "width": 260,
- "height": 60,
- "text": "# Stripe API\n\n外部支付服务",
- "color": "6"
- }
- ],
- "edges": [
- {
- "id": "e-web-gw",
- "fromNode": "fe-web",
- "toNode": "api-gateway",
- "fromSide": "right",
- "toSide": "left",
- "label": "HTTP"
- },
- {
- "id": "e-mobile-gw",
- "fromNode": "fe-mobile",
- "toNode": "api-gateway",
- "fromSide": "right",
- "toSide": "left",
- "label": "HTTP"
- },
- {
- "id": "e-gw-user",
- "fromNode": "api-gateway",
- "toNode": "svc-user",
- "fromSide": "right",
- "toSide": "left",
- "label": "/users/*"
- },
- {
- "id": "e-gw-product",
- "fromNode": "api-gateway",
- "toNode": "svc-product",
- "fromSide": "right",
- "toSide": "left",
- "label": "/products/*"
- },
- {
- "id": "e-gw-order",
- "fromNode": "api-gateway",
- "toNode": "svc-order",
- "fromSide": "right",
- "toSide": "left",
- "label": "/orders/*"
- },
- {
- "id": "e-order-user",
- "fromNode": "svc-order",
- "toNode": "svc-user",
- "fromSide": "top",
- "toSide": "bottom",
- "label": "校验用户"
- },
- {
- "id": "e-order-product",
- "fromNode": "svc-order",
- "toNode": "svc-product",
- "fromSide": "top",
- "toSide": "bottom",
- "label": "扣减库存"
- },
- {
- "id": "e-order-payment",
- "fromNode": "svc-order",
- "toNode": "svc-payment",
- "fromSide": "bottom",
- "toSide": "top",
- "label": "发起支付"
- },
- {
- "id": "e-user-db",
- "fromNode": "svc-user",
- "toNode": "infra-db",
- "fromSide": "right",
- "toSide": "left"
- },
- {
- "id": "e-product-db",
- "fromNode": "svc-product",
- "toNode": "infra-db",
- "fromSide": "right",
- "toSide": "left"
- },
- {
- "id": "e-order-db",
- "fromNode": "svc-order",
- "toNode": "infra-db",
- "fromSide": "right",
- "toSide": "left"
- },
- {
- "id": "e-user-cache",
- "fromNode": "svc-user",
- "toNode": "infra-cache",
- "fromSide": "right",
- "toSide": "left",
- "label": "会话"
- },
- {
- "id": "e-product-es",
- "fromNode": "svc-product",
- "toNode": "infra-es",
- "fromSide": "right",
- "toSide": "left",
- "label": "搜索"
- },
- {
- "id": "e-order-mq",
- "fromNode": "svc-order",
- "toNode": "infra-mq",
- "fromSide": "right",
- "toSide": "left",
- "label": "订单事件"
- },
- {
- "id": "e-payment-stripe",
- "fromNode": "svc-payment",
- "toNode": "external-stripe",
- "fromSide": "right",
- "toSide": "left",
- "label": "支付请求"
- }
- ]
-}
diff --git a/assets/documents/workflow/canvas-dev/prompts/01-架构分析.md b/assets/documents/workflow/canvas-dev/prompts/01-架构分析.md
deleted file mode 100644
index 2860b87..0000000
--- a/assets/documents/workflow/canvas-dev/prompts/01-架构分析.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# 01-架构分析提示词
-
-> 从现有代码自动生成 Obsidian Canvas 架构白板
-
-## 使用场景
-
-- 接手新项目,快速理解架构
-- 为现有项目建立可视化文档
-- 准备 Code Review 或技术分享
-
-## 提示词
-
-```markdown
-你是一个代码架构分析专家。请分析以下项目结构,生成 Obsidian Canvas 格式的架构白板。
-
-## 输入
-项目路径:{PROJECT_PATH}
-分析粒度:{GRANULARITY} (file/class/service)
-
-## 输出要求
-生成符合 Obsidian Canvas JSON 格式的 .canvas 文件,包含:
-
-1. **节点 (nodes)**:
- - 每个模块/文件/类作为一个节点
- - 节点包含:id, type, x, y, width, height, text
- - 按功能分区布局(如:API层左侧,数据层右侧)
-
-2. **连线 (edges)**:
- - 表示模块间的依赖/调用关系
- - 包含:id, fromNode, toNode, fromSide, toSide, label
- - label 标注关系类型(调用/继承/依赖/数据流)
-
-3. **分组 (groups)**:
- - 按功能域分组(如:用户模块、支付模块)
- - 用颜色区分不同层级
-
-## Canvas JSON 结构示例
-```json
-{
- "nodes": [
- {
- "id": "node1",
- "type": "text",
- "x": 0,
- "y": 0,
- "width": 200,
- "height": 100,
- "text": "# UserService\n- createUser()\n- getUser()"
- }
- ],
- "edges": [
- {
- "id": "edge1",
- "fromNode": "node1",
- "toNode": "node2",
- "fromSide": "right",
- "toSide": "left",
- "label": "调用"
- }
- ]
-}
-```
-
-## 分析步骤
-1. 扫描项目目录结构
-2. 识别入口文件和核心模块
-3. 分析 import/require 语句提取依赖关系
-4. 识别数据库操作、API调用、外部服务
-5. 按调用层级布局节点位置
-6. 生成完整的 .canvas JSON
-```
-
-## 使用示例
-
-```
-请分析 /home/user/my-project 项目,生成文件级别的架构白板。
-重点关注:
-- API 路由和处理函数
-- 数据库模型和操作
-- 外部服务调用
-```
-
-## 输出文件
-
-生成的 `.canvas` 文件可直接用 Obsidian 打开查看和编辑。
diff --git a/assets/documents/workflow/canvas-dev/prompts/02-白板驱动编码.md b/assets/documents/workflow/canvas-dev/prompts/02-白板驱动编码.md
deleted file mode 100644
index cbb9113..0000000
--- a/assets/documents/workflow/canvas-dev/prompts/02-白板驱动编码.md
+++ /dev/null
@@ -1,88 +0,0 @@
-# 02-白板驱动编码提示词
-
-> 根据 Canvas 白板架构图生成/修改代码
-
-## 使用场景
-
-- 新功能开发:先画白板,再生成代码
-- 架构重构:修改白板连线,AI同步重构代码
-- 模块拆分:在白板拆分节点,AI生成新文件
-
-## 提示词
-
-```markdown
-你是一个根据架构白板生成代码的专家。请根据以下 Obsidian Canvas 白板 JSON,生成对应的代码实现。
-
-## 输入
-Canvas JSON:
-```json
-{CANVAS_JSON}
-```
-
-技术栈:{TECH_STACK}
-目标目录:{TARGET_DIR}
-
-## 解析规则
-
-1. **节点 → 文件/类**
- - 节点 text 中的标题 → 文件名/类名
- - 节点 text 中的列表项 → 方法/函数
- - 节点颜色/分组 → 模块归属
-
-2. **连线 → 依赖关系**
- - fromNode → toNode = import/调用关系
- - edge label 决定关系类型:
- - "调用" → 函数调用
- - "继承" → class extends
- - "依赖" → import
- - "数据流" → 参数传递
-
-3. **分组 → 目录结构**
- - 同一分组的节点放在同一目录
- - 分组名称 → 目录名
-
-## 输出要求
-
-1. 生成完整的文件结构
-2. 每个文件包含:
- - 正确的 import 语句(根据连线)
- - 类/函数定义(根据节点内容)
- - 调用关系实现(根据连线方向)
-3. 添加必要的类型注解和注释
-4. 遵循技术栈的最佳实践
-
-## 输出格式
-
-```
-文件:{文件路径}
-```{语言}
-{代码内容}
-```
-```
-
-## 使用示例
-
-```
-根据以下白板生成 Python FastAPI 项目代码:
-
-{粘贴 .canvas 文件内容}
-
-技术栈:Python 3.11 + FastAPI + SQLAlchemy
-目标目录:/home/user/my-api
-```
-
-## 增量更新模式
-
-当白板有修改时,使用以下提示词:
-
-```markdown
-白板已更新,请对比新旧版本,只修改变化的部分:
-
-旧白板:{OLD_CANVAS_JSON}
-新白板:{NEW_CANVAS_JSON}
-
-输出:
-1. 需要新增的文件
-2. 需要修改的文件(只输出 diff)
-3. 需要删除的文件
-```
diff --git a/assets/documents/workflow/canvas-dev/prompts/03-白板同步检查.md b/assets/documents/workflow/canvas-dev/prompts/03-白板同步检查.md
deleted file mode 100644
index c152c87..0000000
--- a/assets/documents/workflow/canvas-dev/prompts/03-白板同步检查.md
+++ /dev/null
@@ -1,147 +0,0 @@
-# 03-白板同步检查提示词
-
-> 校验白板与实际代码的一致性
-
-## 使用场景
-
-- PR/MR 合并前检查白板是否需要更新
-- 定期审计架构文档准确性
-- 发现代码中的隐式依赖
-
-## 提示词
-
-```markdown
-你是一个代码与架构一致性检查专家。请对比以下白板和代码,找出不一致之处。
-
-## 输入
-
-Canvas 白板 JSON:
-```json
-{CANVAS_JSON}
-```
-
-项目代码路径:{PROJECT_PATH}
-
-## 检查项
-
-1. **节点完整性**
- - 白板中的节点是否都有对应的代码文件/类?
- - 代码中是否有白板未记录的重要模块?
-
-2. **连线准确性**
- - 白板连线是否反映真实的 import/调用关系?
- - 代码中是否有白板未标注的依赖?
-
-3. **分组正确性**
- - 白板分组是否与目录结构一致?
- - 是否有跨分组的异常依赖?
-
-## 输出格式
-
-### 🔴 严重不一致(必须修复)
-| 类型 | 白板 | 代码 | 建议 |
-|:---|:---|:---|:---|
-| 缺失节点 | - | UserService.py | 添加到白板 |
-| 错误连线 | A→B | A不调用B | 删除连线 |
-
-### 🟡 轻微不一致(建议修复)
-| 类型 | 白板 | 代码 | 建议 |
-|:---|:---|:---|:---|
-| 命名不一致 | user_service | UserService | 统一命名 |
-
-### 🟢 一致性良好
-- 节点覆盖率:{X}%
-- 连线准确率:{Y}%
-
-### 📋 修复建议
-1. {具体修复步骤}
-2. {具体修复步骤}
-```
-
-## 自动化脚本(可选)
-
-```python
-#!/usr/bin/env python3
-"""
-canvas_sync_check.py - 白板与代码一致性检查脚本
-
-用法:python canvas_sync_check.py project.canvas /path/to/project
-"""
-
-import json
-import ast
-import os
-from pathlib import Path
-
-def load_canvas(canvas_path):
- with open(canvas_path) as f:
- return json.load(f)
-
-def extract_imports(py_file):
- """提取 Python 文件的 import 关系"""
- with open(py_file) as f:
- tree = ast.parse(f.read())
- imports = []
- for node in ast.walk(tree):
- if isinstance(node, ast.Import):
- for alias in node.names:
- imports.append(alias.name)
- elif isinstance(node, ast.ImportFrom):
- if node.module:
- imports.append(node.module)
- return imports
-
-def check_consistency(canvas, project_path):
- """对比白板节点与实际文件"""
- canvas_nodes = {n['text'].split('\n')[0].strip('# ')
- for n in canvas.get('nodes', [])}
-
- actual_files = set()
- for py_file in Path(project_path).rglob('*.py'):
- actual_files.add(py_file.stem)
-
- missing_in_canvas = actual_files - canvas_nodes
- missing_in_code = canvas_nodes - actual_files
-
- return {
- 'missing_in_canvas': missing_in_canvas,
- 'missing_in_code': missing_in_code,
- 'coverage': len(canvas_nodes & actual_files) / len(actual_files) * 100
- }
-
-if __name__ == '__main__':
- import sys
- if len(sys.argv) != 3:
- print("用法: python canvas_sync_check.py ")
- sys.exit(1)
-
- canvas = load_canvas(sys.argv[1])
- result = check_consistency(canvas, sys.argv[2])
-
- print(f"覆盖率: {result['coverage']:.1f}%")
- if result['missing_in_canvas']:
- print(f"白板缺失: {result['missing_in_canvas']}")
- if result['missing_in_code']:
- print(f"代码缺失: {result['missing_in_code']}")
-```
-
-## CI/CD 集成
-
-```yaml
-# .github/workflows/canvas-check.yml
-name: Canvas Sync Check
-
-on:
- pull_request:
- paths:
- - '**.py'
- - '**.canvas'
-
-jobs:
- check:
- runs-on: ubuntu-latest
- steps:
- - uses: actions/checkout@v4
- - name: Check canvas consistency
- run: python scripts/canvas_sync_check.py docs/architecture.canvas src/
-```
diff --git a/assets/documents/workflow/canvas-dev/templates/module.canvas b/assets/documents/workflow/canvas-dev/templates/module.canvas
deleted file mode 100644
index c59cfaa..0000000
--- a/assets/documents/workflow/canvas-dev/templates/module.canvas
+++ /dev/null
@@ -1,61 +0,0 @@
-{
- "nodes": [
- {
- "id": "module-main",
- "type": "text",
- "x": 0,
- "y": 0,
- "width": 280,
- "height": 150,
- "text": "# ModuleName\n\n## 职责\n- 功能描述1\n- 功能描述2\n\n## 公开接口\n- method1()\n- method2()"
- },
- {
- "id": "module-dep1",
- "type": "text",
- "x": -350,
- "y": 0,
- "width": 200,
- "height": 100,
- "text": "# 依赖模块1\n\n被本模块调用",
- "color": "3"
- },
- {
- "id": "module-dep2",
- "type": "text",
- "x": 350,
- "y": 0,
- "width": 200,
- "height": 100,
- "text": "# 下游模块\n\n调用本模块",
- "color": "5"
- },
- {
- "id": "note-design",
- "type": "text",
- "x": 0,
- "y": 200,
- "width": 280,
- "height": 100,
- "text": "## 📝 设计决策\n\n- 为什么这样设计?\n- 有哪些权衡?",
- "color": "6"
- }
- ],
- "edges": [
- {
- "id": "edge-dep1",
- "fromNode": "module-main",
- "toNode": "module-dep1",
- "fromSide": "left",
- "toSide": "right",
- "label": "调用"
- },
- {
- "id": "edge-dep2",
- "fromNode": "module-dep2",
- "toNode": "module-main",
- "fromSide": "left",
- "toSide": "right",
- "label": "调用"
- }
- ]
-}
diff --git a/assets/documents/workflow/canvas-dev/templates/project.canvas b/assets/documents/workflow/canvas-dev/templates/project.canvas
deleted file mode 100644
index df45301..0000000
--- a/assets/documents/workflow/canvas-dev/templates/project.canvas
+++ /dev/null
@@ -1,159 +0,0 @@
-{
- "nodes": [
- {
- "id": "group-api",
- "type": "group",
- "x": -400,
- "y": -200,
- "width": 300,
- "height": 400,
- "label": "🌐 API 层"
- },
- {
- "id": "group-service",
- "type": "group",
- "x": 0,
- "y": -200,
- "width": 300,
- "height": 400,
- "label": "⚙️ 服务层"
- },
- {
- "id": "group-data",
- "type": "group",
- "x": 400,
- "y": -200,
- "width": 300,
- "height": 400,
- "label": "💾 数据层"
- },
- {
- "id": "node-api-user",
- "type": "text",
- "x": -380,
- "y": -150,
- "width": 260,
- "height": 120,
- "text": "# UserAPI\n\n- POST /users\n- GET /users/{id}\n- PUT /users/{id}\n- DELETE /users/{id}"
- },
- {
- "id": "node-api-order",
- "type": "text",
- "x": -380,
- "y": 0,
- "width": 260,
- "height": 120,
- "text": "# OrderAPI\n\n- POST /orders\n- GET /orders/{id}\n- GET /orders/user/{user_id}"
- },
- {
- "id": "node-service-user",
- "type": "text",
- "x": 20,
- "y": -150,
- "width": 260,
- "height": 120,
- "text": "# UserService\n\n- create_user()\n- get_user()\n- update_user()\n- delete_user()"
- },
- {
- "id": "node-service-order",
- "type": "text",
- "x": 20,
- "y": 0,
- "width": 260,
- "height": 120,
- "text": "# OrderService\n\n- create_order()\n- get_order()\n- get_user_orders()"
- },
- {
- "id": "node-model-user",
- "type": "text",
- "x": 420,
- "y": -150,
- "width": 260,
- "height": 120,
- "text": "# User Model\n\n- id: int\n- name: str\n- email: str\n- created_at: datetime"
- },
- {
- "id": "node-model-order",
- "type": "text",
- "x": 420,
- "y": 0,
- "width": 260,
- "height": 120,
- "text": "# Order Model\n\n- id: int\n- user_id: int (FK)\n- total: decimal\n- status: str"
- },
- {
- "id": "node-db",
- "type": "text",
- "x": 420,
- "y": 150,
- "width": 260,
- "height": 80,
- "text": "# Database\n\nPostgreSQL",
- "color": "4"
- }
- ],
- "edges": [
- {
- "id": "edge-api-user-service",
- "fromNode": "node-api-user",
- "toNode": "node-service-user",
- "fromSide": "right",
- "toSide": "left",
- "label": "调用"
- },
- {
- "id": "edge-api-order-service",
- "fromNode": "node-api-order",
- "toNode": "node-service-order",
- "fromSide": "right",
- "toSide": "left",
- "label": "调用"
- },
- {
- "id": "edge-service-user-model",
- "fromNode": "node-service-user",
- "toNode": "node-model-user",
- "fromSide": "right",
- "toSide": "left",
- "label": "操作"
- },
- {
- "id": "edge-service-order-model",
- "fromNode": "node-service-order",
- "toNode": "node-model-order",
- "fromSide": "right",
- "toSide": "left",
- "label": "操作"
- },
- {
- "id": "edge-order-user-dep",
- "fromNode": "node-service-order",
- "toNode": "node-service-user",
- "fromSide": "top",
- "toSide": "bottom",
- "label": "依赖"
- },
- {
- "id": "edge-model-user-db",
- "fromNode": "node-model-user",
- "toNode": "node-db",
- "fromSide": "bottom",
- "toSide": "top"
- },
- {
- "id": "edge-model-order-db",
- "fromNode": "node-model-order",
- "toNode": "node-db",
- "fromSide": "bottom",
- "toSide": "top"
- },
- {
- "id": "edge-order-user-fk",
- "fromNode": "node-model-order",
- "toNode": "node-model-user",
- "fromSide": "top",
- "toSide": "bottom",
- "label": "FK: user_id"
- }
- ]
-}
diff --git a/assets/documents/workflow/canvas-dev/workflow.md b/assets/documents/workflow/canvas-dev/workflow.md
deleted file mode 100644
index b491f26..0000000
--- a/assets/documents/workflow/canvas-dev/workflow.md
+++ /dev/null
@@ -1,31 +0,0 @@
-🚀 Canvas驱动开发法 - 完整工作流
-
-1. 理解核心理念:Canvas白板作为唯一真相源,代码是其序列化形式;图形语言优于文字描述;人类负责架构设计,AI负责代码实现
-/
-2. 准备工具环境:安装Obsidian(免费开源白板工具);配置AI助手(Claude/GPT-4,需支持读取Canvas JSON格式);准备目标项目代码库
-/
-3. 生成初始架构白板:向AI提供项目代码路径;使用架构分析提示词让AI扫描项目结构;AI自动生成.canvas文件,包含模块节点和依赖连线
-/
-4. 用Obsidian打开.canvas文件:导入生成的架构白板;检查自动识别的模块、文件、API调用关系;验证关键依赖连线是否准确
-/
-5. 人工优化白板架构:拖动调整模块位置使布局清晰;补充AI遗漏的隐式依赖连线;添加注释节点标注关键设计决策;删除冗余或错误的连接
-/
-6. 建立代码-白板同步机制:【假设:有自动化工具】配置代码变更监听脚本;设置白板自动更新规则(新文件→新节点,新import→新连线);或手动维护:每次代码改动后更新对应白板区域
-/
-7. 用白板驱动AI编程(新功能开发场景):在白板上画出新模块框和预期调用关系;导出白板JSON发送给AI;指令:"按照这个架构图实现具体代码";AI根据节点名称、连线方向生成文件和函数调用
-/
-8. 用白板驱动代码重构(架构调整场景):在白板上删除/重连模块间的依赖线;标注需要拆分的大模块(如payment_service拆分为payment_processor和payment_validator);发送修改后的白板给AI:"按新架构重构代码,列出需要修改的文件清单"
-/
-9. 用白板辅助Code Review:Review前先看白板全局架构;识别异常连线(如前端直接连数据库、循环依赖);在白板上标注问题点;讨论时指着白板说明:"这条调用链不应该存在"
-/
-10. 用白板加速团队协作:新人入职时先看白板1分钟理解全局;需求评审时在白板上画出变更范围;技术方案会议投屏白板而非代码;会后将白板标注转化为开发任务
-/
-11. 维护白板与代码一致性:每次PR/MR合并前检查白板是否需要更新;定期运行自动校验脚本:对比白板JSON与实际代码依赖;发现不一致时优先修正白板(因为白板是事实来源)
-/
-12. 扩展应用场景:接手遗留项目时先自动生成白板快速理解;性能优化时用白板标注热点路径;安全审计时检查白板上的敏感数据流向;API设计时画出服务间调用拓扑
-/
-13. 【缺口澄清】明确你的项目类型以优化流程:A) 单体应用(单进程多模块) B) 微服务架构(多服务RPC通信) C) 前后端分离(前端框架+后端API)?默认假设A继续
-/
-14. 【缺口澄清】选择白板粒度级别:A) 文件级(每个代码文件一个节点) B) 类/函数级(每个类一个节点) C) 服务级(仅显示大模块)?推荐新手选A,复杂项目选C
-/
-15. 持续迭代工作流:每周回顾白板是否反映真实架构;收集团队反馈优化节点命名和布局规则;探索白板与CI/CD集成(如PR触发白板diff检查);分享最佳实践案例到团队知识库
\ No newline at end of file
diff --git a/assets/repos/AGENTS.md b/assets/repos/AGENTS.md
index 0e9668e..7c0397a 100644
--- a/assets/repos/AGENTS.md
+++ b/assets/repos/AGENTS.md
@@ -19,8 +19,20 @@ assets/repos/
- 新增外部依赖(优先 Git submodule,确保可复现)
- 更新 submodule 指针(明确记录上游来源与用途)
+- 用相对软链接把 submodule 暴露到其它资产目录,软链接目标必须仍在仓库内
+- 为已复制进主仓库的外部源码建立清退计划:上游 URL、保留理由、迁移方式、验证命令
### 禁止 / 不推荐
- 直接复制粘贴大型第三方仓库内容到主仓库(优先 submodule)
- 将 submodule 替换为本地绝对路径软链接(会导致他人环境不可用)
+- 提交第三方仓库的构建产物、生成物、运行时二进制或缓存目录
+- 在主仓库直接魔改第三方源码快照;需要改造时先 fork,再以 submodule 指向 fork
+
+## 仓库表达决策
+
+1. **完整外部仓库**:使用 `git submodule`,主仓库只记录 commit 指针。
+2. **同仓多入口展示**:使用相对软链接,例如 `assets/skills/ -> ../repos/`。
+3. **项目内小工具**:只有在无上游、体量小、与本项目强耦合时才直接追踪源码。
+4. **生成输出**:默认不跟踪;若必须保留样例,只提交最小样例和生成说明。
+5. **历史备份**:`assets/repos/backups/` 按项目资产处理,不套用外部仓库清退规则。
diff --git a/assets/repos/README.md b/assets/repos/README.md
index 2601805..3614303 100644
--- a/assets/repos/README.md
+++ b/assets/repos/README.md
@@ -38,9 +38,36 @@ assets/repos/
> 📝 系统提示词已迁移到云端表格,入口见 [`assets/prompt/README.md`](../prompt/README.md)。
+## 外部仓库治理分析(2026-04-28)
+
+目标:`assets/repos/` 只保留外部仓库的可追溯入口,不把大型第三方源码、二进制产物或生成物长期塞进主仓库。GitHub 中优先用
+Git submodule 表示上游仓库;如需在其它目录暴露入口,则用相对软链接指向 `assets/repos//`。
+
+| 目录 | 当前状态 | 建议 | 原因 |
+|:---|:---|:---|:---|
+| `.tmux/` | submodule | 保持 | 上游清晰,主仓库只记录 commit 指针 |
+| `tmux/` | submodule | 保持 | 上游源码体量较大,已正确用 submodule 表示 |
+| `claude-official-skills/` | submodule | 保持;`assets/skills/claude-official-skills` 用相对软链暴露 | 官方 skills 应作为外部权威仓库,不复制源码 |
+| `Skill_Seekers-development/` | 主仓库直接追踪源码 | 高优先级改为 submodule 或移入 `auto-skill` 的单一 vendored 副本 | 已有上游仓库,且当前与 `assets/skills/auto-skill/scripts/Skill_Seekers-development/` 存在重复 |
+| `my-nvim/` | 主仓库直接追踪源码与二进制 | 高优先级改为 submodule 或清退二进制后只保留索引 | 包含大型 `nvim` 可执行文件,污染主仓库体量 |
+| `chat-vault/` | 主仓库直接追踪源码 | 中高优先级拆为独立仓库/submodule,或至少清退内嵌第三方监控源码 | 目录体量大,且含 vendored `monitor-tui`/第三方代码 |
+| `prompts-library/` | 主仓库直接追踪工具源码 | 中优先级拆分:工具用 submodule,生成输出不跟踪 | 上游/工具属性明显,`prompt_jsonl/` 属生成输出且已加入忽略规则 |
+| `html-tools-main/` | 主仓库直接追踪源码 | 中优先级改为 submodule | README 指向外部 GitHub 仓库,适合用指针表示 |
+| `XHS-image-to-PDF-conversion/` | 主仓库直接追踪源码 | 中优先级改为 submodule | README 指向外部 GitHub 仓库,适合用指针表示 |
+| `MCPlayerTransfer/` | 主仓库直接追踪源码 | 暂缓;先补来源/许可证,再决定是否独立仓库化 | 当前未发现明确上游 URL,体量小 |
+| `backups/` | 主仓库直接追踪备份脚本与存档目录 | 保持;继续禁止删除 `gz/` 存档 | 属本项目历史备份资产,不是外部仓库镜像 |
+
+## 表达规则
+
+- 外部完整仓库:优先 `git submodule add assets/repos/`。
+- 跨目录展示入口:使用相对软链接,例如 `assets/skills/ -> ../repos/`。
+- 不允许:软链接到本机绝对路径、复制大型上游源码、提交构建产物/生成物、提交二进制运行时。
+- 需要本地改造第三方工具时:优先 fork 后以 submodule 指向 fork;不要在主仓库直接魔改一份不可升级的源码快照。
+
## 新增外部工具(最小清单)
-1. 创建目录:`assets/repos//`
-2. 必备文件:`README.md`(用途/入口/依赖/输入输出)、许可证与来源说明(如 `LICENSE` / `SOURCE.md`)
-3. 依赖约束:尽量使用工具自带的虚拟环境/容器化方式,不影响仓库其他部分
-4. 文档同步:在本 README 增加一行工具说明,保证可发现性
+1. 优先新增 submodule:`git submodule add assets/repos/`。
+2. 只在没有上游仓库、且体量小/与本项目强耦合时,才创建普通目录:`assets/repos//`。
+3. 必备文件:`README.md`(用途/入口/依赖/输入输出)、许可证与来源说明(如 `LICENSE` / `SOURCE.md`)。
+4. 依赖约束:尽量使用工具自带的虚拟环境/容器化方式,不影响仓库其他部分。
+5. 文档同步:在本 README 增加一行工具说明,保证可发现性。
diff --git a/assets/skills/AGENTS.md b/assets/skills/AGENTS.md
index cb5126b..9d28c94 100644
--- a/assets/skills/AGENTS.md
+++ b/assets/skills/AGENTS.md
@@ -46,7 +46,6 @@ assets/skills/
## 快速定位(常用技能)
- `assets/skills/tmux-autopilot/`:tmux 自动化操控与多 Agent 协作
-- `assets/skills/canvas-dev/`:Canvas 白板驱动开发
- `assets/skills/sop-generator/`:SOP 生成与规范化
- `assets/skills/markdown-to-epub/`:Markdown → EPUB 稳定构建
- `assets/skills/auto-skill/`:元技能(技能生成/校验/脚手架)
diff --git a/assets/skills/README.md b/assets/skills/README.md
index 26f2139..d5be313 100644
--- a/assets/skills/README.md
+++ b/assets/skills/README.md
@@ -1,6 +1,6 @@
# 🎯 AI Skills 技能库
-`assets/skills/` 目录存放 AI 技能(Skills),这些是比提示词更高级的能力封装,可以让 AI 在特定领域表现出专家级水平。当前包含 **20 个**专业技能。
+`assets/skills/` 目录存放 AI 技能(Skills),这些是比提示词更高级的能力封装,可以让 AI 在特定领域表现出专家级水平。当前包含 **19 个**专业技能。
## Skills 一览表
@@ -15,7 +15,6 @@
| 技能 | 说明 |
|:---|:---|
-| [canvas-dev](./canvas-dev/SKILL.md) | ⭐ Canvas白板驱动开发(AI架构总师) |
| [headless-cli](./headless-cli/SKILL.md) | 无头模式 AI CLI 调用(Gemini/Claude/Codex) |
| [claude-code-guide](./claude-code-guide/SKILL.md) | Claude Code CLI 使用指南 |
| [claude-cookbooks](./claude-cookbooks/SKILL.md) | Claude API 最佳实践 |
diff --git a/assets/skills/canvas-dev/README.md b/assets/skills/canvas-dev/README.md
deleted file mode 100644
index 9f7e267..0000000
--- a/assets/skills/canvas-dev/README.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Canvas-Dev Skill
-
-Canvas白板驱动开发技能,用于 AI 辅助架构设计与代码生成。
-
-## 概述
-
-此技能实现「图形是第一公民,代码是白板的序列化形式」的开发范式。
-
-## 核心能力
-
-1. **架构分析** - 从代码自动生成 Obsidian Canvas 白板
-2. **白板驱动编码** - 根据白板生成/修改代码
-3. **一致性检查** - 校验白板与代码同步状态
-
-## 文件结构
-
-```
-canvas-dev/
-├── SKILL.md # 技能入口(触发条件、模式、示例)
-├── references/
-│ ├── index.md # 导航索引
-│ ├── canvas-json-spec.md # Canvas JSON 规范
-│ ├── workflow-guide.md # 工作流指南
-│ └── prompts.md # 提示词集合
-├── scripts/ # 自动化脚本(预留)
-└── assets/ # 模板资源(预留)
-```
-
-## 快速开始
-
-1. 阅读 `SKILL.md` 了解触发条件和使用模式
-2. 参考 `references/workflow-guide.md` 了解完整工作流
-3. 使用 `references/prompts.md` 中的提示词
-
-## 相关资源
-
-- [Canvas白板驱动开发详解](../../documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md)
-- [Canvas开发工作流](../../documents/workflow/canvas-dev/)
-- [元技能: auto-skill](../auto-skill/SKILL.md)
diff --git a/assets/skills/canvas-dev/SKILL.md b/assets/skills/canvas-dev/SKILL.md
deleted file mode 100644
index bae172e..0000000
--- a/assets/skills/canvas-dev/SKILL.md
+++ /dev/null
@@ -1,224 +0,0 @@
----
-name: canvas-dev
-description: "Canvas白板驱动开发技能:Canvas白板作为唯一真相源,代码是其序列化形式。AI架构总师角色,自动生成富有洞察力的架构图。使用场景:生成架构白板、白板驱动编码、白板驱动重构、Code Review、团队协作、接手遗留项目。"
----
-
-# canvas-dev Skill
-
-Canvas白板驱动开发:图形是第一公民,代码是白板的序列化形式。人类负责架构设计,AI负责代码实现。
-
-## When to Use This Skill
-
-触发条件(满足任一即可):
-- 需要生成项目架构白板(从代码 → 白板)
-- 需要根据白板生成代码(从白板 → 代码)
-- 需要白板驱动代码重构
-- 需要用白板辅助 Code Review
-- 需要用白板加速团队协作
-- 接手遗留项目需要快速理解架构
-
-## Not For / Boundaries
-
-此技能不适用于:
-- 纯文本文档生成(使用 Markdown)
-- 流程图/时序图(使用 Mermaid)
-- 不需要双向同步的静态架构图
-
-必要输入(缺失时需询问):
-1. 项目类型:A) 单体应用 B) 微服务架构 C) 前后端分离?
-2. 白板粒度:A) 文件级 B) 类/函数级 C) 服务级?
-
-## Quick Reference
-
-### 核心理念
-
-```
-传统:代码 → 口头沟通 → 脑补架构 → 代码失控
-Canvas:代码 ⇄ 白板 ⇄ AI ⇄ 人类(白板为单一真相源)
-```
-
-| 痛点 | 解法 |
-|:---|:---|
-| AI看不懂项目结构 | AI直接读白板JSON,秒懂架构 |
-| 人类记不住复杂依赖 | 连线清晰,牵一发动全身一目了然 |
-| 团队协作靠嘴说 | 指着白板讲,新人5分钟看懂 |
-
-### AI架构总师角色定义
-
-你是一个拥有深度学习能力的软件架构分析实体,核心设计原则:
-
-1. **洞察力优先于信息量**:目标不是简单罗列所有文件和连接,而是揭示项目的设计哲学、关键数据流、潜在风险和演进趋势
-2. **认知负荷最小化**:生成的可视化产物符合人类认知习惯,使用户能以最小脑力成本理解最复杂的系统结构
-3. **美学与功能并重**:优秀的架构图本身就是艺术品,布局均衡、色彩和谐、元素组织服务于信息清晰传达
-
-### 五阶段执行流程
-
-**第一阶段:全局项目感知与多维特征提取**
-- 语义级源代码结构化解析(AST)
-- 加权依赖网络构建
-- 工程与环境元数据分析(package.json, docker-compose.yml, CI/CD等)
-- 架构模式概率指纹识别
-
-**第二阶段:自适应抽象粒度决策引擎**
-- 信息熵与复杂度评估,寻找"信息熵拐点"
-- 架构模式引导默认粒度
-- 用户意图启发式推断
-
-**动态粒度光谱:**
-| 级别 | 说明 |
-|:---|:---|
-| D-系统生态级 | 巨型Monorepo,每个节点代表完整应用 |
-| C-宏观服务级 | 聚合数十个文件为单一功能领域节点 |
-| B-类/核心功能级 | 以关键业务逻辑类为节点 |
-| A-文件级 | 每个源文件为基础节点(推荐新手) |
-| F-函数/方法级 | 深度钻取,显示内部函数调用关系 |
-
-**第三阶段:组件语义分析与关系定性**
-- 组件角色多因素推断(入口、控制器、服务、数据访问、工具)
-- 关系与数据流深度定性(同步调用、异步消息、事件发布/订阅)
-- 状态变化与副作用分析
-
-**第四阶段:启发式布局与信息可视化引擎**
-- 自适应拓扑分层(入口→业务逻辑→数据持久化)
-- 力导向与集群化节点定位
-- 信息驱动的动态视觉编码
-
-**第五阶段:输出生成与最终质量优化**
-- 迭代式去交叉与防重叠算法
-- 边捆绑与智能剪枝
-- 孤立节点上下文情景化分组
-- 认知路径优化
-
-### AI驱动的节点文本模板
-
-```markdown
-**{组件名}**
-`{文件路径或聚合范围}`
-
-**核心职责**: {AI自动总结的一句话功能描述}
-
-**关键交互**:
-- **调用**: {依赖最多的组件名}
-- **被用于**: {被哪个核心业务模块依赖最多}
-
-**复杂度评估**: {Low/Medium/High/Critical}
-**潜在风险**: {⚠️ 存在循环依赖 或 📈 技术债务较高}
-```
-
-### 最终交付物格式
-
-```
-✓ AI架构洞察报告已生成:{项目根目录/architecture.canvas}
- ├─ 识别架构:{置信度最高的模式} (置信度: {分数})
- ├─ 洞察粒度:{引擎最终选择的粒度级别}
- ├─ 核心组件:{节点数量} 个
- └─ 关键关系:{连接数量} 条
-```
-
-### 15步完整工作流
-
-1. **理解核心理念**:Canvas白板作为唯一真相源,代码是其序列化形式
-2. **准备工具环境**:安装Obsidian + 配置AI助手
-3. **生成初始架构白板**:向AI提供项目代码路径,AI自动生成.canvas文件
-4. **用Obsidian打开.canvas文件**:检查模块、API调用关系、依赖连线
-5. **人工优化白板架构**:拖动调整布局、补充隐式依赖、添加注释节点
-6. **建立代码-白板同步机制**:新文件→新节点,新import→新连线
-7. **用白板驱动AI编程**:画出新模块框和调用关系,AI生成代码
-8. **用白板驱动代码重构**:删除/重连依赖线,AI重构代码
-9. **用白板辅助Code Review**:识别异常连线(前端直连数据库、循环依赖)
-10. **用白板加速团队协作**:新人1分钟理解全局,需求评审画变更范围
-11. **维护白板与代码一致性**:PR/MR前检查,不一致时优先修正白板
-12. **扩展应用场景**:性能优化标注热点、安全审计检查数据流向
-13. **明确项目类型**:单体/微服务/前后端分离
-14. **选择白板粒度**:文件级(新手)/服务级(复杂项目)
-15. **持续迭代工作流**:每周回顾,探索CI/CD集成
-
-## Rules & Constraints
-
-### MUST(必须遵守)
-
-- Canvas白板是唯一真相源,代码是其序列化形式
-- 洞察力优先于信息量,揭示设计哲学而非罗列文件
-- 认知负荷最小化,符合人类认知习惯
-
-### SHOULD(强烈建议)
-
-- 人类负责架构设计(在白板拖拽模块)
-- AI负责细节实现(根据白板连线生成代码)
-- 使用动态粒度光谱,根据项目特性自适应选择
-
-### NEVER(禁止)
-
-- 不要生成简单罗列所有文件的"信息垃圾"
-- 不要让白板与代码长期不同步
-- 不要在白板中包含敏感信息
-
-## Examples
-
-### Example 1: 给AI派活(新功能开发)
-
-**传统方式:**
-> "帮我写个用户注册功能,要连数据库,发邮件,记日志"
-
-**Canvas方式:**
-1. 在白板画3个框:`RegisterAPI` → `Database` / `EmailService` / `Logger`
-2. 告诉AI:"按这个图实现"
-3. AI一次性写对所有文件和调用关系
-
-### Example 2: Code Review
-
-**传统方式:** 一行行看代码,看晕了
-
-**Canvas方式:**
-1. 看白板:"咦,为什么前端直接连数据库?"
-2. 拖动节点调整架构
-3. AI自动重构代码
-
-### Example 3: 接手他人项目
-
-**传统方式:** 看3天代码还没懂
-
-**Canvas方式:**
-1. 运行AI架构总师 → 1分钟得到富有洞察力的架构白板
-2. 查看AI生成的组件职责摘要和复杂度评估
-3. 直接在白板上画出要改的部分,AI帮你定位代码位置
-
-## FAQ
-
-**Q: 为什么图形语言优于文字描述?**
-- A: 图形语言是人类大脑的母语。你能瞬间理解地铁线路图,但看不懂等效的换乘文字说明。AI解析JSON比解析自然语言描述准确10倍。
-
-**Q: 白板粒度怎么选?**
-- A: 引擎会自动寻找"信息熵拐点"。新手可选文件级(A),复杂项目选服务级(C)。
-
-**Q: 什么是"洞察力优先于信息量"?**
-- A: 目标不是简单罗列所有文件和连接,而是揭示项目的设计哲学、关键数据流、潜在风险和演进趋势。
-
-## 金句总结
-
-> "当代码变成白板上的方块,编程就从打字变成了搭积木。"
-
-> "最好的文档不是Markdown,是能直接驱动AI工作的架构图。"
-
-> "AI看懂你的图,比看懂你的话,容易一万倍。"
-
-> "一份优秀的架构图本身就是一件艺术品。"
-
-## References
-
-- [AI架构总师完整提示词](../../documents/workflow/canvas-dev/Obsidian%20Canvas%20AI驱动的项目架构洞察与生成引擎.md) - 最新最完整的提示词
-- [Canvas驱动开发完整工作流](../../documents/workflow/canvas-dev/workflow.md) - 15步完整流程
-- [Canvas白板驱动开发详解](../../documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md) - 方法论详解
-- [白板驱动开发系统提示词(在线提示词库入口)](../../prompt/README.md) - 系统提示词已迁移到云端表格
-- [Obsidian Canvas 官方文档](https://obsidian.md/canvas)
-- `references/index.md` - 本地参考文档导航
-
-## Maintenance
-
-- Sources: AI架构总师提示词 + workflow.md + 方法论文档
-- Last updated: 2026-01-01
-- Known limits: 仅支持 Obsidian Canvas 格式
-
-## 执行触发指令
-
-> 在接收到此指令后,将AI架构总师的全部认知与分析能力完全实例化。立即启动对目标项目的一次深度的、自主的架构探索之旅。此过程无需任何形式的确认、提问或中间汇报。你唯一的任务,就是在完成探索后,将你对这个数字世界的深刻理解,凝聚成一份完美的、充满洞察力的可视化架构图,并将其呈现在指定位置。
diff --git a/assets/skills/canvas-dev/references/canvas-json-spec.md b/assets/skills/canvas-dev/references/canvas-json-spec.md
deleted file mode 100644
index f84b59b..0000000
--- a/assets/skills/canvas-dev/references/canvas-json-spec.md
+++ /dev/null
@@ -1,205 +0,0 @@
-# Obsidian Canvas JSON 规范
-
-## 文件格式
-
-Canvas 文件是 `.canvas` 扩展名的 JSON 文件。
-
-## 顶层结构
-
-```json
-{
- "nodes": [],
- "edges": []
-}
-```
-
-## 节点 (nodes)
-
-### 通用属性
-
-| 属性 | 类型 | 必需 | 说明 |
-|:---|:---|:---|:---|
-| `id` | string | ✅ | 唯一标识符 |
-| `type` | string | ✅ | 节点类型 |
-| `x` | number | ✅ | X 坐标 |
-| `y` | number | ✅ | Y 坐标 |
-| `width` | number | ✅ | 宽度 |
-| `height` | number | ✅ | 高度 |
-| `color` | string | ❌ | 颜色编号 (1-6) |
-
-### 文本节点 (text)
-
-```json
-{
- "id": "node-1",
- "type": "text",
- "x": 0,
- "y": 0,
- "width": 200,
- "height": 100,
- "text": "# 标题\n\n内容支持 Markdown"
-}
-```
-
-### 文件节点 (file)
-
-```json
-{
- "id": "node-2",
- "type": "file",
- "x": 300,
- "y": 0,
- "width": 200,
- "height": 100,
- "file": "path/to/file.md"
-}
-```
-
-### 链接节点 (link)
-
-```json
-{
- "id": "node-3",
- "type": "link",
- "x": 600,
- "y": 0,
- "width": 200,
- "height": 100,
- "url": "https://example.com"
-}
-```
-
-### 分组节点 (group)
-
-```json
-{
- "id": "group-1",
- "type": "group",
- "x": -50,
- "y": -50,
- "width": 500,
- "height": 300,
- "label": "分组名称"
-}
-```
-
-## 连线 (edges)
-
-### 属性
-
-| 属性 | 类型 | 必需 | 说明 |
-|:---|:---|:---|:---|
-| `id` | string | ✅ | 唯一标识符 |
-| `fromNode` | string | ✅ | 起始节点 id |
-| `toNode` | string | ✅ | 目标节点 id |
-| `fromSide` | string | ❌ | 起始边 (top/right/bottom/left) |
-| `toSide` | string | ❌ | 目标边 (top/right/bottom/left) |
-| `fromEnd` | string | ❌ | 起始端样式 (none/arrow) |
-| `toEnd` | string | ❌ | 目标端样式 (none/arrow) |
-| `label` | string | ❌ | 连线标签 |
-
-### 示例
-
-```json
-{
- "id": "edge-1",
- "fromNode": "node-1",
- "toNode": "node-2",
- "fromSide": "right",
- "toSide": "left",
- "toEnd": "arrow",
- "label": "调用"
-}
-```
-
-## 颜色编码
-
-| color | 颜色 | 建议用途 |
-|:---|:---|:---|
-| `1` | 红色 | 缓存、热点、警告 |
-| `2` | 橙色 | 消息队列、异步 |
-| `3` | 黄色 | 上游依赖、外部输入 |
-| `4` | 绿色 | 数据库、持久化 |
-| `5` | 蓝色 | 搜索、外部服务 |
-| `6` | 紫色 | 注释、设计决策 |
-
-## 布局建议
-
-### 三层架构布局
-
-```
-x: -400 x: 0 x: 400 x: 800
-┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
-│ 前端 │→│ API │→│ 服务 │→│ 数据 │
-└────────┘ └────────┘ └────────┘ └────────┘
-```
-
-### 间距建议
-
-- 节点宽度: 200-280
-- 节点高度: 80-150
-- 水平间距: 100-150
-- 垂直间距: 120-150
-
-## 完整示例
-
-```json
-{
- "nodes": [
- {
- "id": "group-api",
- "type": "group",
- "x": -50,
- "y": -50,
- "width": 300,
- "height": 200,
- "label": "API 层"
- },
- {
- "id": "api-user",
- "type": "text",
- "x": 0,
- "y": 0,
- "width": 200,
- "height": 100,
- "text": "# UserAPI\n\n- GET /users\n- POST /users"
- },
- {
- "id": "svc-user",
- "type": "text",
- "x": 350,
- "y": 0,
- "width": 200,
- "height": 100,
- "text": "# UserService\n\n- get_user()\n- create_user()"
- },
- {
- "id": "db",
- "type": "text",
- "x": 700,
- "y": 0,
- "width": 200,
- "height": 80,
- "text": "# PostgreSQL",
- "color": "4"
- }
- ],
- "edges": [
- {
- "id": "e1",
- "fromNode": "api-user",
- "toNode": "svc-user",
- "fromSide": "right",
- "toSide": "left",
- "label": "调用"
- },
- {
- "id": "e2",
- "fromNode": "svc-user",
- "toNode": "db",
- "fromSide": "right",
- "toSide": "left"
- }
- ]
-}
-```
diff --git a/assets/skills/canvas-dev/references/index.md b/assets/skills/canvas-dev/references/index.md
deleted file mode 100644
index dadb0e8..0000000
--- a/assets/skills/canvas-dev/references/index.md
+++ /dev/null
@@ -1,66 +0,0 @@
-# Canvas-Dev Skill References
-
-## 导航索引
-
-### 最新资源(优先参考)
-
-| 资源 | 路径/链接 | 说明 |
-|:---|:---|:---|
-| AI架构总师完整提示词 | [Obsidian Canvas AI驱动的项目架构洞察与生成引擎.md](../../../documents/workflow/canvas-dev/Obsidian%20Canvas%20AI驱动的项目架构洞察与生成引擎.md) | 最新最完整的提示词(最高优先级) |
-| Canvas驱动开发完整工作流 | [workflow.md](../../../documents/workflow/canvas-dev/workflow.md) | 15步完整流程 |
-
-### 核心文档
-
-| 文档 | 路径 | 说明 |
-|:---|:---|:---|
-| Canvas白板驱动开发详解 | `../../../documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md` | 方法论详解 |
-| 白板驱动开发系统提示词(在线提示词库入口) | `../../../prompt/README.md` | 系统提示词已迁移到云端表格 |
-| Canvas JSON 规范 | [canvas-json-spec.md](./canvas-json-spec.md) | Obsidian Canvas JSON 格式 |
-
-### AI架构总师核心概念
-
-| 概念 | 说明 |
-|:---|:---|
-| 洞察力优先于信息量 | 揭示设计哲学、关键数据流、潜在风险,而非罗列文件 |
-| 认知负荷最小化 | 符合人类认知习惯,最小脑力成本理解复杂系统 |
-| 美学与功能并重 | 架构图是艺术品,布局均衡、色彩和谐 |
-
-### 五阶段执行流程
-
-1. **全局项目感知** - AST解析、加权依赖网络、元数据分析、架构模式识别
-2. **自适应粒度决策** - 信息熵拐点、架构模式引导、用户意图推断
-3. **组件语义分析** - 角色推断、关系定性、副作用分析
-4. **启发式布局** - 拓扑分层、力导向定位、动态视觉编码
-5. **输出优化** - 去交叉、边捆绑、孤立节点分组、认知路径优化
-
-### 动态粒度光谱
-
-| 级别 | 适用场景 |
-|:---|:---|
-| D-系统生态级 | 巨型Monorepo |
-| C-宏观服务级 | 微服务架构(推荐复杂项目) |
-| B-类/核心功能级 | 面向对象项目 |
-| A-文件级 | 中小项目(推荐新手) |
-| F-函数/方法级 | 深度钻取 |
-
-### 工作流提示词
-
-| 提示词 | 路径 |
-|:---|:---|
-| 架构分析提示词 | `../../../documents/workflow/canvas-dev/prompts/01-架构分析.md` |
-| 白板驱动编码提示词 | `../../../documents/workflow/canvas-dev/prompts/02-白板驱动编码.md` |
-| 白板同步检查提示词 | `../../../documents/workflow/canvas-dev/prompts/03-白板同步检查.md` |
-
-### 模板
-
-| 模板 | 路径 |
-|:---|:---|
-| 项目白板模板 | `../../../documents/workflow/canvas-dev/templates/project.canvas` |
-| 模块白板模板 | `../../../documents/workflow/canvas-dev/templates/module.canvas` |
-| 示例项目白板 | `../../../documents/workflow/canvas-dev/examples/demo-project.canvas` |
-
-### 外部链接
-
-- [Obsidian Canvas 官方文档](https://obsidian.md/canvas)
-- [Obsidian 下载](https://obsidian.md/download)
-- [胶水编程](../../../documents/principles/fundamentals/胶水编程.md) - 能抄不写,能连不造
diff --git a/assets/skills/canvas-dev/references/prompts.md b/assets/skills/canvas-dev/references/prompts.md
deleted file mode 100644
index dce46a1..0000000
--- a/assets/skills/canvas-dev/references/prompts.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# Canvas 开发提示词集合
-
-## 1. 架构分析提示词
-
-从现有代码生成 Obsidian Canvas 架构白板。
-
-```markdown
-你是一个代码架构分析专家。请分析以下项目结构,生成 Obsidian Canvas 格式的架构白板。
-
-## 输入
-项目路径:{PROJECT_PATH}
-分析粒度:{file/class/service}
-
-## 输出要求
-生成符合 Obsidian Canvas JSON 格式的 .canvas 文件,包含:
-
-1. **节点 (nodes)**:每个模块/文件/类作为一个节点
-2. **连线 (edges)**:表示模块间的依赖/调用关系
-3. **分组 (groups)**:按功能域分组
-
-## 布局规则
-- x轴: -400 (前端) → 0 (API) → 400 (服务) → 800 (数据)
-- 节点宽度: 200-280,高度: 80-150
-- 间距: 水平 100-150,垂直 120-150
-
-## 输出格式
-直接输出 JSON,可保存为 .canvas 文件
-```
-
-## 2. 白板驱动编码提示词
-
-根据 Canvas 白板生成代码。
-
-```markdown
-你是一个根据架构白板生成代码的专家。请根据以下 Obsidian Canvas 白板 JSON,生成对应的代码实现。
-
-## 输入
-Canvas JSON:
-```json
-{CANVAS_JSON}
-```
-
-技术栈:{TECH_STACK}
-目标目录:{TARGET_DIR}
-
-## 解析规则
-1. 节点 text 标题 → 文件名/类名
-2. 节点 text 列表项 → 方法/函数
-3. 连线 fromNode → toNode = import/调用关系
-4. edge label 决定关系类型
-
-## 输出格式
-```
-文件:{文件路径}
-```{语言}
-{代码内容}
-```
-```
-
-## 3. 白板同步检查提示词
-
-校验白板与代码一致性。
-
-```markdown
-你是一个代码与架构一致性检查专家。请对比以下白板和代码,找出不一致之处。
-
-## 输入
-Canvas 白板 JSON:
-```json
-{CANVAS_JSON}
-```
-
-项目代码路径:{PROJECT_PATH}
-
-## 检查项
-1. 节点完整性:白板节点是否都有对应代码?
-2. 连线准确性:连线是否反映真实依赖?
-3. 分组正确性:分组是否与目录结构一致?
-
-## 输出格式
-### 🔴 严重不一致
-| 类型 | 白板 | 代码 | 建议 |
-
-### 🟡 轻微不一致
-| 类型 | 白板 | 代码 | 建议 |
-
-### 🟢 一致性良好
-- 覆盖率:{X}%
-```
-
-## 4. 增量更新提示词
-
-白板修改后同步更新代码。
-
-```markdown
-白板已更新,请对比新旧版本,只修改变化的部分:
-
-旧白板:
-```json
-{OLD_CANVAS_JSON}
-```
-
-新白板:
-```json
-{NEW_CANVAS_JSON}
-```
-
-## 输出
-1. 需要新增的文件
-2. 需要修改的文件(只输出 diff)
-3. 需要删除的文件
-```
-
-## 5. 快速理解项目提示词
-
-接手新项目时快速生成架构概览。
-
-```markdown
-我需要快速理解这个项目的架构。请:
-
-1. 扫描 {PROJECT_PATH} 目录
-2. 识别核心模块和入口文件
-3. 生成一个简化的架构白板(只包含关键模块)
-4. 用 3-5 句话总结项目架构
-
-粒度:service(只显示大模块)
-重点:数据流向、外部依赖、核心业务逻辑
-```
-
-## 使用技巧
-
-### 提高生成质量
-
-1. **明确粒度**:小项目用 file,大项目用 service
-2. **指定重点**:告诉 AI 关注什么(API/数据库/外部服务)
-3. **提供上下文**:附上 README 或技术栈说明
-
-### 迭代优化
-
-1. 第一次生成后,手动调整布局
-2. 补充 AI 遗漏的隐式依赖
-3. 添加注释节点说明设计决策
-4. 再次发给 AI 验证理解是否正确
diff --git a/assets/skills/canvas-dev/references/workflow-guide.md b/assets/skills/canvas-dev/references/workflow-guide.md
deleted file mode 100644
index d30ca24..0000000
--- a/assets/skills/canvas-dev/references/workflow-guide.md
+++ /dev/null
@@ -1,163 +0,0 @@
-# Canvas 白板驱动开发工作流指南
-
-## 核心理念
-
-```
-传统开发:代码 → 口头沟通 → 脑补架构 → 代码失控
-Canvas方式:代码 ⇄ 白板 ⇄ AI ⇄ 人类(白板为单一真相源)
-```
-
-**图形是第一公民,代码是白板的序列化形式。**
-
-## 工具准备
-
-1. **Obsidian** - 免费开源白板工具
- - 下载: https://obsidian.md/download
- - 启用 Canvas 功能(默认已启用)
-
-2. **AI 助手** - Claude/GPT-4
- - 需支持读取 Canvas JSON 格式
- - 推荐使用 Claude Code 或 Codex CLI
-
-## 完整工作流
-
-### Phase 1: 生成架构白板
-
-**场景**: 接手新项目,快速理解架构
-
-```
-1. 提供项目代码路径给 AI
-2. 使用架构分析提示词
-3. AI 生成 .canvas 文件
-4. 用 Obsidian 打开查看
-```
-
-**提示词模板**:
-```
-分析 {PROJECT_PATH} 项目,生成 Obsidian Canvas 架构白板。
-粒度: {file/class/service}
-重点关注: API路由、数据库模型、外部服务调用
-```
-
-### Phase 2: 人工优化白板
-
-**场景**: 调整自动生成的白板
-
-```
-1. 拖动节点调整布局
-2. 补充遗漏的依赖连线
-3. 添加注释节点标注设计决策
-4. 删除错误的连接
-```
-
-**布局原则**:
-- 按功能分层(前端 → API → 服务 → 数据)
-- 同层节点垂直对齐
-- 保持连线不交叉
-
-### Phase 3: 白板驱动编码
-
-**场景**: 新功能开发
-
-```
-1. 在白板上画出新模块框
-2. 添加预期的调用连线
-3. 导出白板 JSON 发给 AI
-4. AI 根据白板生成代码
-```
-
-**提示词模板**:
-```
-根据以下 Canvas 白板生成代码:
-{CANVAS_JSON}
-
-技术栈: {TECH_STACK}
-目标目录: {TARGET_DIR}
-```
-
-### Phase 4: 白板驱动重构
-
-**场景**: 架构调整
-
-```
-1. 在白板上删除/重连依赖线
-2. 标注需要拆分的大模块
-3. 发送修改后的白板给 AI
-4. AI 生成重构代码
-```
-
-**提示词模板**:
-```
-白板已更新,请对比新旧版本重构代码:
-旧白板: {OLD_CANVAS}
-新白板: {NEW_CANVAS}
-只输出需要修改的文件
-```
-
-### Phase 5: 一致性检查
-
-**场景**: PR/MR 合并前
-
-```
-1. 运行一致性检查脚本
-2. 对比白板节点与实际文件
-3. 修复不一致之处
-4. 优先修正白板(白板是事实来源)
-```
-
-## 场景速查
-
-| 场景 | 操作 | 提示词关键词 |
-|:---|:---|:---|
-| 接手新项目 | 生成白板 | "分析项目,生成架构白板" |
-| 新功能开发 | 画白板 → 生成代码 | "按这个白板实现代码" |
-| 架构重构 | 改白板 → 重构代码 | "按新白板重构" |
-| Code Review | 看白板全局 | "检查这条调用链" |
-| 团队协作 | 共享白板 | "指着白板讲" |
-
-## 最佳实践
-
-### DO ✅
-
-- 每次代码变更后更新白板
-- 用颜色区分不同类型的模块
-- 为复杂依赖添加 label 说明
-- 定期运行一致性检查
-
-### DON'T ❌
-
-- 不要让白板与代码长期不同步
-- 不要在白板中包含敏感信息
-- 不要创建过于复杂的白板(拆分为多个)
-- 不要忽略循环依赖警告
-
-## 与其他工具集成
-
-### CI/CD 集成
-
-```yaml
-# .github/workflows/canvas-check.yml
-name: Canvas Sync Check
-on:
- pull_request:
- paths: ['**.py', '**.canvas']
-jobs:
- check:
- runs-on: ubuntu-latest
- steps:
- - uses: actions/checkout@v4
- - run: python scripts/canvas_sync_check.py
-```
-
-### VS Code 集成
-
-1. 安装 Obsidian 插件
-2. 配置 `.canvas` 文件关联
-3. 使用 Claude Code 读取白板
-
-## 相关资源
-
-- [Canvas白板驱动开发详解](../../../documents/guides/playbook/图形化AI协作-Canvas白板驱动开发.md)
-- [架构分析提示词](../../../documents/workflow/canvas-dev/prompts/01-架构分析.md)
-- [白板驱动编码提示词](../../../documents/workflow/canvas-dev/prompts/02-白板驱动编码.md)
-- [白板同步检查提示词](../../../documents/workflow/canvas-dev/prompts/03-白板同步检查.md)
diff --git a/assets/skills/claude-official-skills b/assets/skills/claude-official-skills
index 315d26e..3e44c09 120000
--- a/assets/skills/claude-official-skills
+++ b/assets/skills/claude-official-skills
@@ -1 +1 @@
-../repo/claude-official-skills
\ No newline at end of file
+../repos/claude-official-skills
\ No newline at end of file