openmatrix 0.2.8 → 0.2.10

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openmatrix",
-  "version": "0.2.8",
+  "version": "0.2.10",
   "description": "AI Agent task orchestration system with Claude Code Skills integration",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/skills/debug.md

@@ -114,12 +114,67 @@ Agent({
 - 问题描述: ${description}
 ${relatedTaskId ? `- 关联任务: ${relatedTaskId}` : ''}
 
-## 任务
-1. 仔细阅读所有错误信息（不要跳过任何警告或错误）
-2. 收集相关文件和日志
-3. 检查近期代码变更（git diff、最近提交）
-4. 如果有多个组件，追踪数据流，找到断裂点
-5. 定位问题根源
+## 调查步骤（必须按顺序执行）
+
+### 1. 仔细阅读错误信息
+- 不要跳过任何警告或错误
+- 错误信息往往包含解决方案
+- 完整阅读堆栈跟踪
+- 记录行号、文件路径、错误代码
+
+### 2. 稳定复现
+- 能否可靠触发？
+- 精确步骤是什么？
+- 每次都会发生吗？
+- 不能复现 → 收集更多数据，不要猜测
+
+### 3. 检查近期变更
+- git diff、最近提交
+- 新依赖、配置变更
+- 环境差异
+
+### 4. 多组件系统诊断（如有多个组件）
+**当系统有多个组件（CI → build → signing, API → service → database）：**
+
+**在提出修复之前，添加诊断日志：**
+\`\`\`
+对每个组件边界：
+  - 记录什么数据进入组件
+  - 记录什么数据退出组件
+  - 验证环境/配置传递
+  - 检查每层状态
+
+运行一次收集证据，显示哪里断裂
+然后分析证据识别失败组件
+然后深入调查该组件
+\`\`\`
+
+**示例（多层系统）：**
+\`\`\`bash
+# Layer 1: Workflow
+echo "=== Secrets in workflow: ==="
+echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
+
+# Layer 2: Build script
+echo "=== Env vars in build: ==="
+env | grep IDENTITY || echo "IDENTITY not in env"
+
+# Layer 3: Signing script
+echo "=== Keychain state: ==="
+security list-keychains
+
+# Layer 4: Actual signing
+codesign --sign "$IDENTITY" --verbose=4 "$APP"
+\`\`\`
+
+这揭示：哪层失败（secrets → workflow ✓, workflow → build ✗）
+
+### 5. 追踪数据流
+**当错误在调用栈深处：**
+- 错误值从哪里产生？
+- 谁传入的这个错误值？
+- 继续向上追踪直到源头
+- 在源头修复，不是症状处
 
 ## 输出格式
 请按以下格式输出：
@@ -136,6 +191,10 @@ ${relatedTaskId ? `- 关联任务: ${relatedTaskId}` : ''}
 - 提交1: 描述
 - 提交2: 描述
 
+### 多组件诊断结果（如适用）
+- Layer N 状态: ...
+- 断裂点: ...
+
 ### 根因分析
 [详细描述问题根源]
 
@@ -448,4 +507,69 @@ Step 10: 写入 Debug Report
 - 不修改未关联的文件
 - 单一修复原则
 - 修复前必须有验证方法
+
+## 红旗警告 - 停止并回归流程
+
+**如果发现自己在想：**
+- "先快速修复，之后再调查"
+- "试试改 X 看看能不能工作"
+- "一次改多处，跑测试"
+- "跳过测试，手动验证就行"
+- "大概是 X 问题，直接修吧"
+- "不太懂但这可能有用"
+- "模式说 X 但我要改动一下"
+- "这里列出主要问题：[未经调查直接列修复]"
+- 提出解决方案前没有追踪数据流
+- **"再试一次修复"（已经试过 2+ 次）**
+- 每次修复揭示新地方的问题
+
+**所有这些意味着：停止。回到 Step 3。**
+
+## 常见借口 vs 真实情况
+
+| 借口 | 真实情况 |
+|------|---------|
+| "问题简单，不需要流程" | 简单问题也有根因。流程处理简单 bug 很快。 |
+| "紧急情况，没时间走流程" | 系统化调试比瞎猜乱试更快。 |
+| "先试试这个，再调查" | 第一次修复定基调。从一开始就做对。 |
+| "确认修复有效后再写测试" | 没测试的修复不牢靠。先写测试证明它。 |
+| "一次改多处节省时间" | 无法隔离哪个有效。还会引入新 bug。 |
+| "参考文档太长，我按模式改改" | 一知半解必然有 bug。完整阅读。 |
+| "我看到问题了，直接修吧" | 看到症状 ≠ 理解根因。 |
+| "再试一次修复"（失败 2+ 次后） | 3+ 次失败 = 架构问题。质疑模式，不要继续修。 |
+
+## 3+ 次修复失败：质疑架构
+
+**指示架构问题的模式：**
+- 每次修复揭示新共享状态/耦合/其他地方的问题
+- 修复需要"大规模重构"才能实现
+- 每次修复在其他地方产生新症状
+
+**停止并质疑根本问题：**
+- 这个模式根本上是否合理？
+- 我们是否"靠惯性硬撑"？
+- 应该重构架构还是继续修补症状？
+
+**在尝试更多修复之前与用户讨论。**
+
+这不是假设失败 — 这是架构错误。
+
+## 无根因的情况
+
+如果系统化调查揭示问题确实是环境、时序依赖或外部因素：
+
+1. 你已完成流程
+2. 记录调查了什么
+3. 实现适当处理（重试、超时、错误消息）
+4. 添加监控/日志以便未来调查
+
+**但：** 95% 的"无根因"情况是调查不完整。
+
+## 实际影响
+
+来自调试实践：
+- 系统化方法：15-30 分钟修复
+- 随机修复方法：2-3 小时折腾
+- 首次修复率：95% vs 40%
+- 引入新 bug：接近零 vs 常见
 </notes>

package/skills/feature.md

@@ -21,7 +21,7 @@ priority: high
 
 ```
 Step 1:  接收任务输入（参数、文件、或询问用户）
-Step 2:  任务边界确认（单一功能点检查）
+Step 2:  AI 自动判断任务边界（不符合条件才询问切换）
 Step 3:  AI 拆分为 2-5 个小任务块
 Step 4:  用 TodoWrite 管理任务状态
 Step 5:  问答确认（质量等级、E2E测试、执行计划）
@@ -65,22 +65,35 @@ AskUserQuestion: `header: "任务描述"`, `multiSelect: false`
 | 从文件读取 | 指定任务文件路径 |
 | 取消 | 退出 |
 
-## Step 2: 任务边界确认
+## Step 2: AI 判断任务边界
 
-**⛔ 关键检查：确认任务边界**
+**AI 自动判断任务是否适合本 skill：**
 
-AskUserQuestion: `header: "任务边界确认"`, `multiSelect: false`
-**question:** 这是单一功能点的小需求吗？
+检查以下条件（全部满足才继续，否则建议切换）：
+
+| 条件 | 检查方式 |
+|------|---------|
+| 描述长度 ≤ 100 字 | 字数统计 |
+| 单一功能点 | 无"和"、"同时"、"另外"等连接词 |
+| 无架构设计 | 无"架构"、"设计"、"从零"、"重构"关键词 |
+| 无多子系统 | 无多个独立模块描述 |
+
+**判断结果处理：**
+
+| 结果 | 处理 |
+|------|------|
+| ✅ 全部满足 | 继续执行 Step 3 |
+| ❌ 不满足 | 输出建议并询问是否切换到 `/om:start` |
+
+**如果需要切换，询问：**
+
+AskUserQuestion: `header: "任务复杂度"`, `multiSelect: false`
+**question:** 任务可能需要完整追踪，建议使用 `/om:start`。是否切换？
 
 | label | description |
 |-------|-------------|
-| 是小需求 | 单一功能，继续执行 |
-| 不确定/复杂 | 建议使用 /om:start |
-
-**如果用户选择"不确定/复杂"：**
-- 展示建议：任务可能需要完整追踪，建议使用 `/om:start`
-- 询问是否切换
-- 如果坚持使用本 skill，继续但记录风险
+| 切换到 /om:start | 使用完整流程 |
+| 继续用 /om:feature | 强制使用轻量流程（可能无法完整追踪） |
 
 ## Step 3: AI 拆分为 2-5 个小任务块
 
@@ -364,6 +377,29 @@ $ARGUMENTS
 - 不得跳过任务边界确认
 - 不得在 Agent 内部执行 git commit
 
+## 红旗警告 - 停止并回归流程
+
+**如果发现自己在想：**
+- "验证麻烦，先提交再说"
+- "任务块小，一次改两个吧"
+- "顺便重构下这个代码"
+- "跳过质量确认，直接开始"
+- "测试失败没关系，手动验证就行"
+- "这个小改动不会影响其他"
+
+**所有这些意味着：停止。回到流程执行。**
+
+## 常见借口 vs 真实情况
+
+| 借口 | 真实情况 |
+|------|---------|
+| "验证太慢，先提交" | 未验证的提交会污染仓库，回头排查更慢。 |
+| "一次改两个任务块效率高" | 无法隔离哪个改动有问题。引入新 bug。 |
+| "顺便重构没问题" | "顺便"是 bug 的温床。任务聚焦。 |
+| "质量确认麻烦" | 3 秒的选择防止后续数小时排查。 |
+| "手动验证就行" | 手动验证不可重复。自动化测试才可靠。 |
+| "小改动不会出错" | 小改动也有根因。系统性验证。 |
+
 ## 与其他指令的区别
 
 | 指令 | 适用场景 | 任务文件 | 问答 | 验证 |
@@ -394,6 +430,24 @@ $ARGUMENTS
 | Agent 超时 | 询问重试或跳过 |
 | Git 失败 | 提示手动处理 |
 
+## 3+ 次验证失败：质疑任务拆分
+
+**如果同一任务块验证失败 3 次以上：**
+
+**指示拆分问题的模式：**
+- 每次修复产生新的测试失败
+- 任务块范围模糊，边界不清
+- 修改影响多个不相关文件
+
+**停止并质疑拆分方案：**
+- 任务块是否过于复杂？
+- 是否需要重新拆分？
+- 是否应该切换到 `/om:start` 使用完整流程？
+
+**在继续执行之前与用户讨论拆分方案。**
+
+这不是执行失败 — 这是拆分策略问题。
+
 ## Git 提交格式
 
 ```