dijk-skills 1.0.1 → 1.0.3

package/README.md

@@ -27,7 +27,7 @@ npx dijk-skills install [options]
 | Module | Skills |
 |--------|--------|
 | `common` | grilling, humanizer-zh, i-have-adhd |
-| `writing` | grill-my-proposal, vibe-insight |
+| `writing` | grill-my-proposal, vibe-opinion-insight |
 | `tools` | darwin-skill, skill-creator |
 | `coding` | *(empty, reserved for future skills)* |
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dijk-skills",
-  "version": "1.0.1",
+  "version": "1.0.3",
   "description": "CLI installer for Dijk skills collection",
   "type": "module",
   "bin": {
@@ -14,6 +14,10 @@
     "tools/",
     "writing/"
   ],
-  "keywords": ["skills", "cli", "installer"],
+  "keywords": [
+    "skills",
+    "cli",
+    "installer"
+  ],
   "license": "MIT"
 }

package/writing/skills/vibe-code-insight/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: vibe-code-insight
+description: >
+  对软件项目进行深度系统分析，产出 design.md（系统设计）和 trend.md（生态与趋势洞察）。
+  当用户想系统性地理解一个代码仓库或开源项目时使用——不只是看代码，还要看它的生态、
+  竞品、社区和技术演进方向。即使用户没有明确说"深度分析"，只要意图是"帮我搞清楚这个
+  项目是什么、怎么运作、在行业里什么位置"，就应该触发此 skill。
+  关键词：深度分析、系统设计文档、趋势洞察、生态分析、4+1视图、analyze this repo、
+  project deep dive、code insight、帮我分析这个项目、这个项目怎么样、了解下这个仓库。
+---
+
+# Vibe Code Insight
+
+## Vibe 阶段
+
+目标：最少交互，最大推断。
+
+1. **先读 prompt 推断** — 用户提到竞品就是竞品视角，说了"安全"就是安全维度
+2. **快速侦察项目** — README、目录结构、规模决定分析深度（500 行工具库不需要 4+1）
+3. **只补缺失维度** — 读者画像 / 核心关注 / 侧重维度 / 视图偏好，能推断的不问，最多问 2 个
+4. **展示推断，邀请纠正** — "判断你是 X 视角，重点 Y"，不要弹预设选项
+
+结论写入 `insight/{slug}/brief.md`，后续触发先读 brief 恢复意图。
+
+## 交付物
+
+### design.md — 系统设计文档
+
+让读者像内部架构师一样理解这个系统——它是什么、做什么、怎么做、为什么这样设计。
+
+模板：`references/design-template.md`
+
+### trend.md — 生态与趋势洞察
+
+让读者像行业分析师一样判断这个系统——它在行业中处于什么位置、周边生态如何、往哪里走、值不值得押注。
+
+模板：`references/trend-template.md`
+
+## 踩过的坑
+
+以下经验来自实际分析过程中 AI 犯过的错，不是通用常识：
+
+1. **生态映射必须区分依赖方向** — 不区分"项目依赖 X"和"X 依赖项目"，读者分不清哪些是上游脆弱性、哪些是下游采用信号
+2. **不要编造术语和计数** — 术语表曾出现仓库里不存在的词；"N 个组件"的计数未经源码验证就写进去了
+3. **不要把多个不相关事实合并成叙事** — 每个趋势判断追溯到单个项目的事实；跨项目综合是观点，不是分析
+4. **每个推断需要真正的反方观点** — 不是"但也有风险"，而是思考推断在什么条件下不成立
+5. **厂商互相提及不是交叉验证** — A 说"集成 B"，B 说"基于 A"，是同一叙事的两个回声；厂商自述须标注来源类型
+
+## 静态代码分析方法
+
+AI 不能编译运行代码，只能采样和推理。以下策略从不同入口切入，覆盖不同维度：
+
+| 策略 | 入口 | 捕获什么 |
+|------|------|---------|
+| 入口优先 | main.go、cmd/ | 系统边界、进程启动逻辑 |
+| 接口优先 | .proto、OpenAPI、schema | 组件间协议、API 表面 |
+| 数据优先 | 数据库迁移、模型类 | 系统在存什么 → 推断在做什么 |
+| 变更优先 | git log、最近 commit | 演进方向、设计压力、痛点 |
+| 测试优先 | *_test.go | 开发者认为重要的行为 |
+| 异常优先 | 错误处理代码 | 系统最脆弱的地方 |
+
+单次读取容易自圆其说。交叉验证降低盲区：
+- **文档 vs 代码** — 设计意图 vs 实际实现，不一致的地方最有价值
+- **接口 vs 实现** — proto 声明的能力，实现是否完整
+- **当前 vs 历史** — 一次设计还是多次重构的结果，重构痕迹透露设计压力
+- **指标注册表倒推** — 先读 metrics 定义，从"系统在观测什么"倒推"系统在做什么"
+
+需要深入代码细节时，调用 `codemap` skill 生成代码地图，帮助理解模块依赖和调用关系。
+
+## 版本与刷新
+
+每次触发时检查 `insight/{slug}/` 是否存在：
+- **不存在** → 首次分析：Vibe 阶段 → 全量
+- **存在且 `@ commit` = HEAD** → 最新，直接回答问题
+- **存在且 `@ commit` < HEAD** → diff 变更范围，小变更增量刷新受影响的章节，大变更全量重做
+
+文档头部用版本记录表跟踪：版本、日期、源码基线 commit、变更说明。

package/writing/skills/vibe-code-insight/references/design-template.md

@@ -0,0 +1,149 @@
+# {项目名称} 系统设计文档
+
+> **项目定位**：{一句话定位}
+>
+> **分析基线**：{仓库地址, commit hash, 分支, 日期}
+
+---
+
+## 版本记录
+
+| 版本 | 日期 | 变更说明 |
+|------|------|----------|
+| v1.0 | {日期} | 初始版本 |
+
+---
+
+## 1. 使用场景
+
+> 用第一人称叙事，4-5 个场景，每个场景让读者代入一个具体角色，理解系统的价值和使用方式。
+
+### 场景 1：{角色} —— {一句话概括}
+
+{叙事段落}
+
+### 场景 2：{角色} —— {一句话概括}
+
+{叙事段落}
+
+...
+
+---
+
+## 2. 系统特性
+
+> 黑盒视角，按类别组织，附具体指标和来源标签。
+
+### 2.1 {类别}
+
+| 特性 | 说明 | 指标/证据 | 出处 |
+|------|------|-----------|------|
+| ... | ... | ... | [来源] |
+
+### 2.2 {类别}
+
+| 特性 | 说明 | 出处 |
+|------|------|------|
+| ... | ... | [来源] |
+
+...
+
+---
+
+## 3. 系统上下文
+
+> ASCII 系统上下文图 + 上下文说明。
+
+### 3.1 系统上下文图
+
+```
+{ASCII 图}
+```
+
+### 3.2 上下文说明
+
+{上游系统、外部依赖、相关项目的说明}
+
+---
+
+## 4. 系统功能清单
+
+> 按模块划分，列出具体 RPC/API/能力。
+
+### 4.1 {模块名}
+
+| 功能类别 | 具体能力 | 说明 |
+|----------|---------|------|
+| ... | ... | ... |
+
+...
+
+---
+
+## 5. 系统约束/原则
+
+### 5.1 架构约束
+
+{编号列表}
+
+### 5.2 设计原则
+
+{编号列表}
+
+### 5.3 已知限制
+
+| 限制 | 影响 | 现状 |
+|------|------|------|
+| ... | ... | ... |
+
+---
+
+## 6. 架构视图
+
+> 从多个视角呈现系统结构。根据项目特点选择合适的视图组合和抽象层次——可以是 4+1 视图（逻辑/开发/进程/部署/场景）、C4 模型（Context/Container/Component/Code）、或其他适合该系统的组织方式。关键是从不同角度回答不同问题，而不是套用固定模板。
+
+### 6.1 {视图 1 名称}
+
+{从某个角度呈现系统——如组件关系、代码结构、运行时交互、部署拓扑}
+
+### 6.2 {视图 2 名称}
+
+{从另一个角度呈现系统}
+
+### 6.3 {视图 3 名称}
+
+{从另一个角度呈现系统}
+
+...
+
+---
+
+## 7. 关键技术/关键设计
+
+> 每个关键技术：问题 → 设计 → 权衡
+
+### 7.1 {技术/设计名称}
+
+**问题**：{为什么需要这个}
+
+**设计**：{怎么做的}
+
+**权衡**：{取舍了什么}
+
+...
+
+---
+
+## 附录
+
+### A. 术语表
+
+| 术语 | 含义 |
+|------|------|
+| ... | ... |
+
+### B. 证据索引
+
+| 证据 | 类型 | 位置 |
+|------|------|------|
+| ... | [来源] | {路径或引用} |

package/writing/skills/vibe-code-insight/references/trend-template.md

@@ -0,0 +1,207 @@
+# {项目名称} 生态与趋势洞察
+
+> {一句话说明本文档的定位和分析基线}
+
+---
+
+## 版本记录
+
+| 版本 | 日期 | 变更说明 |
+|------|------|----------|
+| v1.0 | {日期} | 初始版本 |
+
+---
+
+## 1. 数据来源与置信度说明
+
+| 置信度 | 数据来源 | 代表来源 |
+|--------|----------|----------|
+| ★★★★★ 最高 | 源码 | {具体目录/文件} |
+| ★★★★☆ 高 | 提交记录 | {commit 数量} |
+| ★★★☆☆ 中高 | 官方文档/博客 | {具体来源} |
+| ★★☆☆☆ 中 | 社区/竞品自述 | {具体来源} |
+| ★☆☆☆☆ 低 | 媒体报道 | {具体来源} |
+
+{例外说明，如厂商自述、论文单一来源等}
+
+---
+
+## 2. 生态图
+
+> 以本项目为中心，用脑图展示全局，再按依赖距离和方向分层展开细节。
+
+### 2.1 全景图
+
+用**图**（graph）展示生态全貌——节点是项目，边是关系（含方向和类型）。不是树，因为项目之间可以有跨层连接。
+
+两种呈现方式，根据生态复杂度选择：
+
+**方式 A：Mermaid flowchart**（适合 ≤15 个节点）
+
+```mermaid
+flowchart TB
+    S((本项目)):::center
+    DA[下游A]:::downstream
+    UA[上游A]:::upstream
+    CA[竞品A]:::competitor
+    
+    S --> DA
+    UA --> S
+    S -.同赛道.- CA
+    UA --> CA
+    
+    classDef center fill:#2563eb,stroke:#fff,color:#fff
+    classDef downstream fill:#10b981,stroke:#fff,color:#fff
+    classDef upstream fill:#f59e0b,stroke:#fff,color:#fff
+    classDef competitor fill:#6b7280,stroke:#fff,color:#fff
+```
+
+**方式 B：边列表表格**（适合节点多、关系复杂的情况，无渲染依赖）
+
+| 源 | → 关系 | 目标 | 证据 |
+|----|--------|------|------|
+| 本项目 | go.mod 依赖 | 上游A | [代码] |
+| 下游A | CRD 引用 | 本项目 | [下游A/docs] |
+| 竞品A | 也依赖 | 上游A | [竞品A/README] |
+
+> 图是总览，下面的分层小节是细节。
+
+### 2.2 Layer 0: {项目名称} 自身
+
+{基本事实：stars, forks, 创建时间, 提交数, 版本状态, 官方定位}
+
+### Layer 1↓ 下游（依赖本项目的项目）
+
+#### {项目名} — {URL}
+
+{事实列表，每条带来源标签}
+
+...
+
+### Layer 1↑ 上游（本项目依赖的项目）
+
+#### {项目名} — {URL}
+
+{事实列表，每条带来源标签}
+
+...
+
+### Layer 1↔ 双向/声明性关系
+
+#### {项目名} — {URL}
+
+{事实列表，每条带来源标签}
+
+...
+
+### Layer 2: 竞品或相邻项目
+
+#### {项目名} — {URL}
+
+{事实列表，每条带来源标签}
+
+...
+
+### Layer 3: 更广泛的技术上下文
+
+#### {项目/标准/学术工作}
+
+{事实列表，每条带来源标签}
+
+...
+
+---
+
+## 3. 基于生态事实的趋势判断
+
+> 每条判断追溯到单个项目（或紧密相关项目）的具体事实。格式：[事实] → [判断]。
+
+### 3.1 {判断标题}
+
+**[事实]** {具体事实} [{来源}]
+
+**[判断]** {基于此事实的推断}
+
+...
+
+---
+
+## 4. 深度趋势分析
+
+> 跨事实的模式识别与推断。每个趋势三段式：事实基础 / [推断] / 反方观点。
+
+### 趋势1：{趋势标题}
+
+**事实基础：**
+
+{引用第 2 节的具体事实，附来源标签}
+
+**[推断]：**
+
+{分析性洞察，可含历史类比、模式识别}
+
+**反方观点：**
+
+{此推断在什么条件下不成立}
+
+...
+
+---
+
+## 5. 关键技术决策回顾
+
+| 决策 | 选择 | 替代方案 | 评价 |
+|------|------|----------|------|
+| ... | ... | ... | ... |
+
+{决策模式分析}
+
+{尚未验证的开放决策}
+
+---
+
+## 6. 成熟度评估
+
+| 维度 | 评级 | 证据 |
+|------|------|------|
+| ... | ★...☆ | ... |
+
+{与 Layer 1/Layer 2 同行的对比定位}
+
+{综合判断与阶段预期}
+
+---
+
+## 7. 值得关注的信号
+
+### 积极信号
+
+{编号列表，引用具体生态事实}
+
+### 风险信号
+
+{编号列表，引用具体生态事实}
+
+### 持续跟踪问题
+
+{编号列表}
+
+---
+
+## 8. 选型建议
+
+### 适合采用的场景
+
+{列表}
+
+### 不适合采用的场景
+
+{列表}
+
+### 替代方案
+
+| 需求 | 建议 | 生态事实参考 |
+|------|------|-------------|
+| ... | ... | {引用} |
+
+{核心判断框架}

package/writing/skills/{vibe-insight → vibe-opinion-insight}/README.md

@@ -1,6 +1,6 @@
-# vibe-insight：Human-Agent 协作哲学
+# vibe-opinion-insight：Human-Agent 协作哲学
 
-> 本文档是 vibe-insight skill 的理论基础。日常执行只需阅读 SKILL.md；迭代修改 SKILL 或 onboard 新贡献者时参考本文件。
+> 本文档是 vibe-opinion-insight skill 的理论基础。日常执行只需阅读 SKILL.md；迭代修改 SKILL 或 onboard 新贡献者时参考本文件。
 
 本技能描述的是 Human 与 Agent 协作撰写技术洞察报告的工作模式。SKILL.md 中的所有操作规则都基于本文档中对两者优劣势的根因分析。
 

package/writing/skills/{vibe-insight → vibe-opinion-insight}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: vibe-insight
+name: vibe-opinion-insight
 description: Human 驱动的 AI Agent 技术洞察框架。Agent 是启发工具，Human 是意义赋予者和责任承担者。
 ---
 ## 设计原则（不变量）