sdd-full 3.2.0 → 4.2.0

package/skills/rules/project_rules.md

@@ -1,167 +0,0 @@
-# 项目规则 - SDD全流程开发技能体系（团队共享）
-
-## 一、项目概述
-
-本项目是一个完整的SDD（Software Design Document）全流程开发技能包，包含从需求分析到发布运维的全流程技能，支持Trae和Claude Code双调用机制。
-
-## 二、核心流程规范
-
-### 2.1 新项目开发流程
-```
-需求收集 → 头脑风暴 → 市场调研 → PRD编写 → SDD拆分 → UI设计 → 代码设计 → 测试设计 → 开发 → 测试 → 质量检查 → 发布 → 复盘
-```
-
-### 2.2 Bug修复流程
-```
-问题定位 → Test-SDD补充回归用例 → 代码修复 → 验证 → 质量检查 → 经验沉淀
-```
-
-### 2.3 小型功能迭代流程
-```
-需求澄清 → SDD快速拆分 → 开发 → 验证 → 质量检查 → 发布
-```
-
-## 三、技能使用规范
-
-### 3.1 技能分类与职责
-| 分类 | 技能 | 职责描述 |
-|------|------|---------|
-| 需求分析 | brainstorming, market-research, competitive-brief, prd-write, requirement-completion-officer, sdd, sdd-full | 需求收集、分析、拆分 |
-| 设计规划 | ui-sdd, sdd-code, sdd-test, sdd-deploy, sdd-ops, writing-plans | 设计方案制定 |
-| 开发执行 | sdd-add, test-driven-development, systematic-debugging, verification-before-completion | 代码实现 |
-| 质量保障 | quality-gate, security-audit | 质量把关 |
-| 发布运维 | finishing-a-development-branch, release-flow | 发布管理 |
-| 知识沉淀 | claudeception, mempalace-auto-saver | 经验积累 |
-
-### 3.2 强制使用技能
-- ✅ **所有发布前必须通过 quality-gate**
-- ✅ **所有需求必须经过 sdd/sdd-full 拆分**
-- ✅ **所有Bug修复必须经过 systematic-debugging**
-- ✅ **发布后必须进行 claudeception 经验沉淀**
-
-## 四、文档规范
-
-### 4.1 SDD模板规范
-项目使用9种标准化SDD模板：
-1. **Base-SDD** - 全局通用基线规范
-2. **Brain-SDD** - 头脑风暴文档
-3. **Competitor-SDD** - 竞品分析文档
-4. **PRD-SDD** - 产品需求文档
-5. **UI-SDD** - UI设计文档
-6. **Code-SDD** - 代码实现文档
-7. **API-SDD** - 接口设计文档
-8. **Env-SDD** - 环境配置文档
-9. **Test-SDD** - 测试设计文档
-
-### 4.2 文档命名规范
-```
-{项目名称}-{模板名称}-{版本}.md
-示例：个人备忘录APP-Base-SDD-v1.0.md
-```
-
-### 4.3 文档归档规范
-```
-docs/
-├── specs/                    # SDD规范文档
-│   ├── ui/                   # UI-SDD
-│   ├── function-implementation-sdd/ # Code-SDD
-│   └── test/                 # Test-SDD
-├── stories/                  # 用户故事
-├── architecture/             # 架构文档
-├── database/                 # 数据库设计
-├── api/                      # API契约
-└── deploy/                   # 部署文档
-```
-
-## 五、质量标准
-
-### 5.1 代码质量标准
-- 单元测试覆盖率 ≥ 80%
-- 代码审查必须通过
-- 无 P0/P1 级别 Bug
-
-### 5.2 文档质量标准
-- 所有SDD模板必须完整填写
-- 文档版本管理规范
-- 文档与代码同步更新
-
-### 5.3 发布标准
-- 所有测试用例通过
-- quality-gate 检查通过
-- security-audit 无高危漏洞
-
-## 六、协作规范
-
-### 6.1 分支管理
-- `main` - 主分支，稳定版本
-- `develop` - 开发分支
-- `feature/*` - 功能分支
-- `bugfix/*` - Bug修复分支
-- `release/*` - 发布分支
-
-### 6.2 代码审查流程
-1. 功能开发完成后提交 PR
-2. 触发 requesting-code-review
-3. 审查通过后触发 receiving-code-review
-4. 合并到 develop 分支
-
-### 6.3 沟通规范
-- 使用明确的技能触发关键词
-- 及时更新状态
-- 遇到问题及时反馈
-
-## 七、调用机制规范
-
-### 7.1 Trae调用格式
-```
-trae调用 模板名称 项目名称=XXX 阶段=XXX 流程场景=XXX
-```
-
-### 7.2 Claude Code调用格式
-```
-调用 技能名称 参数
-```
-
-### 7.3 流程场景参数
-| 参数值 | 说明 |
-|--------|------|
-| 完整3阶段SDD流程 | 大型项目完整流程 |
-| 从零开始新项目 | 新项目立项 |
-| 小型功能迭代 | 快速迭代 |
-| Bug处理 | Bug修复 |
-| 代码发布 | 版本发布 |
-
-## 八、工具与环境
-
-### 8.1 推荐工具
-- **Figma** - UI设计
-- **GitHub** - 代码托管
-- **Trae** - 技能调用
-- **Claude Code** - AI协作
-
-### 8.2 环境要求
-- Node.js ≥ 18.x
-- npm ≥ 9.x
-- sdd-full ≥ 2.2.0
-
-## 九、版本管理
-
-### 9.1 版本命名规范
-```
-v{主版本}.{次版本}.{修订版本}
-示例：v2.2.0
-```
-
-### 9.2 版本发布流程
-1. 完成功能开发与测试
-2. 更新版本号
-3. 通过 quality-gate
-4. 执行 release-flow
-5. 发布到 npm
-
----
-
-**版本**: v1.0  
-**更新时间**: 2026-05-06  
-**适用项目**: sdd-full-npm  
-**团队**: SDD开发团队

package/skills/sdd-framework/SKILL.md

@@ -1,90 +0,0 @@
-【claude code调用标识：sdd-framework】【trae调用标识：sdd-framework+SDD融合框架】【流程场景：1.完整3阶段SDD流程、2.从零开始新项目】
-
----
-name: sdd-framework
-description: SDD融合框架 - 标准化SDD模板管理，覆盖从全局基线到测试的全流程
----
-
-# SDD融合框架
-
-## 概述
-
-本框架提供标准化SDD模板管理，将头脑风暴、竞品分析、PRD、UI设计、代码实现、API设计、环境配置、测试设计等环节纳入文档化管理，形成纯文档闭环。
-
-## SDD模板清单
-
-模板统一存放在 `skills/templates/` 目录：
-
-| 模板名称 | 核心内容 | 适用技能 |
-|---------|---------|---------|
-| **Base-SDD** | 全局通用基线规范 | sdd, sdd-full |
-| **Brain-SDD** | 头脑风暴文档 | brainstorming |
-| **Competitor-SDD** | 竞品分析文档 | competitive-brief, market-research |
-| **PRD-SDD** | 产品需求文档 | prd-write, requirement-completion-officer |
-| **UI-SDD** | UI设计文档 | ui-sdd |
-| **Code-SDD** | 代码实现文档 | sdd-code, test-driven-development |
-| **API-SDD** | 接口设计文档 | sdd（接口拆分） |
-| **Env-SDD** | 环境配置文档 | sdd-deploy, sdd-ops |
-| **Test-SDD** | 测试设计文档 | sdd-test, test-driven-development |
-
-## 专项SDD模板
-
-| 模板名称 | 核心内容 | 适用场景 |
-|---------|---------|---------|
-| **UI-SDD专用模板** | UI设计稿结构化、交付标准 | UI设计阶段 |
-| **功能SDD专用模板** | 业务功能专属模板 | 功能开发 |
-| **BDD风格验收标准SDD** | BDD验收句式、准入/准出标准 | 测试验收 |
-| **环境预检标准化SDD** | 本机配置、依赖版本、网络预检 | 项目启动 |
-| **Flutter地图导航业务SDD** | 高德SDK集成、Marker处理 | 地图开发 |
-| **Flutter音视频全栈SDD** | 离线ASR、TTS、OCR接入 | 音视频功能 |
-| **Flutter全类型测试策略SDD** | Golden测试、E2E、TDD、冒烟测试 | 测试策略 |
-| **Flutter常见异常专项SDD** | SocketException、渲染异常排查 | Bug修复 |
-| **企业级全栈工程规范SDD** | 项目目录、版本管理、交付标准 | 工程规范 |
-| **Andrej Karpathy AI编码规则SDD** | 编码约束、禁止自由发挥 | 编码规范 |
-| **高保真设计转代码SDD** | Rive动画、Figma转Flutter | 设计转代码 |
-
-## 强制顺序流水线
-
-```
-Base-SDD → Brain-SDD → Competitor-SDD → PRD-SDD → Figma设计 → UI-SDD → Code-SDD → API-SDD → Env-SDD → Test-SDD → TDD开发 → 分层测试 → Bug闭环 → quality-gate → sdd-deploy → release-flow → claudeception
-```
-
-## 使用指南
-
-### 新项目完整流程
-1. 首先创建Base-SDD定义全局基线
-2. Brain-SDD进行头脑风暴
-3. Competitor-SDD进行竞品分析
-4. PRD-SDD编写产品需求
-5. Figma设计UI
-6. 依次创建UI-SDD、Code-SDD、API-SDD、Env-SDD、Test-SDD
-7. TDD开发、测试、发布
-
-### Bug修复流程
-1. systematic-debugging分析问题
-2. 更新Test-SDD添加回归用例
-3. sdd-add修复代码
-4. verification-before-completion验证
-5. quality-gate检查
-6. claudeception沉淀经验
-
-### 精简流程（小功能）
-满足任意2条可使用精简流程：
-- 开发周期≤1天，代码量≤500行
-- 不涉及新接口、新UI组件
-- 无复杂交互，不影响全局流程
-
-## AI协作规范
-
-| 阶段 | AI职责 | 人工校验要求 |
-|------|--------|-------------|
-| Brain-SDD | 发散想法、评估风险 | 确认想法合理性 |
-| Competitor-SDD | 收集竞品信息、对比差异 | 确认分析准确性 |
-| PRD-SDD | 补全需求、梳理用户旅程 | 必须人工二次确认 |
-| Code-SDD | 编写测试用例、排查Bug | 确认代码规范 |
-| 所有阶段 | 协助整理归档 | 校验完整性 |
-
----
-
-**模板版本**: v5.0  
-**适用场景**: 个人+AI开发模式的完整文档化流程

package/skills/special-tools/receiving-code-review/SKILL.md

@@ -1,215 +0,0 @@
-【claude code调用标识：receiving-code-review】【trae调用标识：receiving-code-review+代码审查接收】【流程场景：1.完整3阶段SDD流程、3.小型功能迭代、5.代码发布】
-
----
-name: receiving-code-review
-description: 在收到代码审查反馈时使用，在实施建议之前，特别是如果反馈似乎不清楚或技术上有问题 - 需要技术严谨性和验证，而不是表演性同意或盲目实施
----
-
-# 代码审查接收
-
-## 概述
-
-代码审查需要技术评估，而不是情感表演。
-
-**核心原则：** 实施前验证。假设前询问。技术正确性优先于社交舒适度。
-
-## 响应模式
-
-```
-收到代码审查反馈时：
-
-1. 阅读：完整阅读反馈，不做出反应
-2. 理解：用自己的话重述要求（或询问）
-3. 验证：对照代码库现实进行检查
-4. 评估：对这个代码库技术上是否合理？
-5. 响应：技术确认或有理由的反驳
-6. 实施：一次一个项目，测试每个项目
-```
-
-## 禁止的响应
-
-**永远不要：**
-- "你绝对正确！"（明确违反 CLAUDE.md）
-- "好观点！" / "优秀的反馈！"（表演性的）
-- "让我现在实施那个"（验证前）
-
-**相反：**
-- 重述技术要求
-- 提出澄清问题
-- 如果错误，用技术推理反驳
-- 直接开始工作（行动 > 言语）
-
-## 处理不清楚的反馈
-
-```
-如果任何项目不清楚：
-  停止 - 暂时不要实施任何内容
-  要求澄清不清楚的项目
-
-原因：项目可能相关。部分理解 = 错误实施。
-```
-
-**示例：**
-```
-你的人类伙伴："修复 1-6"
-你理解 1,2,3,6。对 4,5 不清楚。
-
-❌ 错误：现在实施 1,2,3,6，稍后询问 4,5
-✅ 正确："我理解项目 1,2,3,6。在继续之前需要澄清 4 和 5。"
-```
-
-## 特定来源处理
-
-### 来自你的人类伙伴
-- **可信** - 理解后实施
-- **如果范围不清楚，仍要询问**
-- **无表演性同意**
-- **直接行动**或技术确认
-
-### 来自外部审查者
-```
-实施前：
-  1. 检查：对这个代码库技术上是否正确？
-  2. 检查：是否破坏现有功能？
-  3. 检查：当前实现的原因？
-  4. 检查：是否在所有平台/版本上工作？
-  5. 检查：审查者是否理解完整上下文？
-
-如果建议似乎错误：
-  用技术推理反驳
-
-如果无法轻松验证：
-  说明："没有 [X] 我无法验证这一点。我应该 [调查/询问/继续]？"
-
-如果与你的人类伙伴之前的决定冲突：
-  先停止并与你的人类伙伴讨论
-```
-
-**你的人类伙伴的规则：** "外部反馈 - 保持怀疑，但仔细检查"
-
-## "专业"功能的 YAGNI 检查
-
-```
-如果审查者建议"正确实施"：
-  在代码库中搜索实际使用
-
-  如果未使用："这个端点没有被调用。移除它（YAGNI）？"
-  如果使用：则正确实施
-```
-
-**你的人类伙伴的规则：** "你和审查者都向我报告。如果我们不需要这个功能，就不要添加它。"
-
-## 实施顺序
-
-```
-对于多项反馈：
-  1. 首先澄清任何不清楚的内容
-  2. 然后按以下顺序实施：
-     - 阻塞问题（中断，安全）
-     - 简单修复（拼写错误，导入）
-     - 复杂修复（重构，逻辑）
-  3. 单独测试每个修复
-  4. 验证无回归
-```
-
-## 何时反驳
-
-当以下情况时反驳：
-- 建议破坏现有功能
-- 审查者缺乏完整上下文
-- 违反 YAGNI（未使用的功能）
-- 对这个技术栈技术上不正确
-- 存在遗留/兼容性原因
-- 与你的人类伙伴的架构决策冲突
-
-**如何反驳：**
-- 使用技术推理，而非防御性
-- 提出具体问题
-- 引用工作测试/代码
-- 如果是架构问题，让你的人类伙伴参与
-
-**如果不愿意大声反驳的信号：** "Circle K 有奇怪的事情发生"
-
-## 确认正确的反馈
-
-当反馈正确时：
-```
-✅ "已修复。[对更改的简要描述]"
-✅ "好发现 - [具体问题]。在 [位置] 已修复。"
-✅ [直接修复并在代码中显示]
-
-❌ "你绝对正确！"
-❌ "好观点！"
-❌ "感谢发现那个！"
-❌ "感谢 [任何内容]"
-❌ 任何感谢表达
-```
-
-**为什么不感谢：** 行动说话。直接修复。代码本身表明你听到了反馈。
-
-**如果你发现自己要写"谢谢"：** 删除它。改为说明修复。
-
-## 优雅地纠正你的反驳
-
-如果你反驳了但错了：
-```
-✅ "你是对的 - 我检查了 [X]，它确实 [Y]。现在实施。"
-✅ "验证了这一点，你是正确的。我最初的理解是错误的，因为 [原因]。正在修复。"
-
-❌ 冗长的道歉
-❌ 为你反驳的原因辩护
-❌ 过度解释
-```
-
-事实陈述纠正并继续。
-
-## 常见错误
-
-| 错误 | 修复 |
-|------|------|
-| 表演性同意 | 说明要求或直接行动 |
-| 盲目实施 | 首先对照代码库验证 |
-| 批量实施而不测试 | 一次一个，测试每个 |
-| 假设审查者是对的 | 检查是否破坏事物 |
-| 避免反驳 | 技术正确性 > 舒适度 |
-| 部分实施 | 首先澄清所有项目 |
-| 无法验证，仍继续 | 说明限制，请求方向 |
-
-## 真实示例
-
-**表演性同意（错误）：**
-```
-审查者："移除遗留代码"
-❌ "你绝对正确！让我移除那个..."
-```
-
-**技术验证（正确）：**
-```
-审查者："移除遗留代码"
-✅ "检查中... 构建目标是 10.15+，此 API 需要 13+。需要遗留代码以保持向后兼容。当前实现的 bundle ID 错误 - 修复它还是放弃 13 之前的支持？"
-```
-
-**YAGNI（正确）：**
-```
-审查者："实施带有数据库、日期过滤器、CSV 导出的适当指标跟踪"
-✅ "搜索代码库 - 没有调用此端点。移除它（YAGNI）？还是我遗漏了使用情况？"
-```
-
-**不清楚的项目（正确）：**
-```
-你的人类伙伴："修复项目 1-6"
-你理解 1,2,3,6。对 4,5 不清楚。
-✅ "理解 1,2,3,6。在实施之前需要澄清 4 和 5。"
-```
-
-## GitHub 线程回复
-
-在 GitHub 上回复内联审查评论时，在评论线程中回复（`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`），而不是作为顶级 PR 评论。
-
-## 底线
-
-**外部反馈 = 要评估的建议，不是要遵循的命令。**
-
-验证。提问。然后实施。
-
-无表演性同意。始终保持技术严谨。

package/skills/special-tools/requesting-code-review/SKILL.md

@@ -1,107 +0,0 @@
-【claude code调用标识：requesting-code-review】【trae调用标识：requesting-code-review+请求代码审查】【流程场景：1.完整3阶段SDD流程、3.小型功能迭代、5.代码发布】
-
----
-name: requesting-code-review
-description: 在完成任务、实现主要功能或合并前使用，以验证工作是否满足要求
----
-
-# 请求代码审查
-
-调度 superpowers:code-reviewer 子代理，在问题扩散前捕获它们。审查者获得精确设计的评估上下文 - 绝不是你的会话历史。这使审查者专注于工作产品，而不是你的思考过程，并保留你自己的上下文以继续工作。
-
-**核心原则：** 尽早审查，经常审查。
-
-## 何时请求审查
-
-**必须：**
-- 子代理驱动开发中的每个任务后
-- 完成主要功能后
-- 合并到 main 之前
-
-**可选但有价值：**
-- 卡住时（新鲜视角）
-- 重构前（基线检查）
-- 修复复杂错误后
-
-## 如何请求
-
-**1. 获取 git SHAs：**
-```bash
-BASE_SHA=$(git rev-parse HEAD~1)  # 或 origin/main
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-**2. 调度代码审查子代理：**
-
-使用 Task 工具与 superpowers:code-reviewer 类型，填写 `code-reviewer.md` 中的模板
-
-**占位符：**
-- `{WHAT_WAS_IMPLEMENTED}` - 你刚刚构建的内容
-- `{PLAN_OR_REQUIREMENTS}` - 它应该做什么
-- `{BASE_SHA}` - 起始提交
-- `{HEAD_SHA}` - 结束提交
-- `{DESCRIPTION}` - 简短摘要
-
-**3. 根据反馈行动：**
-- 立即修复关键问题
-- 在继续之前修复重要问题
-- 记录次要问题以便以后处理
-- 如果审查者错误，反驳（带有理由）
-
-## 示例
-
-```
-[刚刚完成任务 2：添加验证函数]
-
-你：让我在继续之前请求代码审查。
-
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
-HEAD_SHA=$(git rev-parse HEAD)
-
-[调度 superpowers:code-reviewer 子代理]
-  WHAT_WAS_IMPLEMENTED: 对话索引的验证和修复函数
-  PLAN_OR_REQUIREMENTS: docs/superpowers/plans/deployment-plan.md 中的任务 2
-  BASE_SHA: a7981ec
-  HEAD_SHA: 3df7661
-  DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，具有 4 种问题类型
-
-[子代理返回]:
-  优势：干净的架构，真实测试
-  问题：
-    重要：缺少进度指示器
-    次要：报告间隔的魔法数字 (100)
-  评估：可以继续
-
-你：[修复进度指示器]
-[继续到任务 3]
-```
-
-## 与工作流集成
-
-**子代理驱动开发：**
-- 每个任务后审查
-- 在问题复合前捕获它们
-- 在移至下一个任务前修复
-
-**执行计划：**
-- 每批（3 个任务）后审查
-- 获取反馈，应用，继续
-
-**临时开发：**
-- 合并前审查
-- 卡住时审查
-
-## 红旗
-
-**永远不要：**
-- 因为"简单"而跳过审查
-- 忽略关键问题
-- 带着未修复的重要问题继续
-- 与有效的技术反馈争论
-
-**如果审查者错误：**
-- 用技术推理反驳
-- 展示证明它有效的代码/测试
-- 请求澄清
-
-请参阅模板：requesting-code-review/code-reviewer.md

package/skills/special-tools/using-superpowers/SKILL.md

@@ -1,117 +0,0 @@
-【claude code调用标识：using-superpowers】【trae调用标识：using-superpowers+技能调用管理】【流程场景：1.完整3阶段SDD流程、2.从零开始新项目、3.小型功能迭代、4.Bug处理、5.代码发布】
-
----
-name: using-superpowers
-description: 当开始任何对话时使用 - 建立如何查找和使用技能的方法，要求在包括澄清问题在内的任何响应之前调用Skill工具
----
-
-<SUBAGENT-STOP>
-如果您被派作为子代理执行特定任务，请跳过此技能。
-</SUBAGENT-STOP>
-
-<EXTREMELY-IMPORTANT>
-如果您认为技能可能适用于您正在做的事情的可能性甚至为1%，您绝对必须调用该技能。
-
-如果技能适用于您的任务，您没有选择。您必须使用它。
-
-这是不可协商的。这不是可选的。您不能通过理性思考来逃避这一点。
-</EXTREMELY-IMPORTANT>
-
-## 指令优先级
-
-Superpowers技能会覆盖默认的系统提示行为，但**用户指令始终优先**：
-
-1. **用户的明确指令**（CLAUDE.md、GEMINI.md、AGENTS.md、直接请求）— 最高优先级
-2. **Superpowers技能** — 在冲突时覆盖默认系统行为
-3. **默认系统提示** — 最低优先级
-
-如果CLAUDE.md、GEMINI.md或AGENTS.md说"不要使用TDD"，而技能说"始终使用TDD"，请遵循用户的指令。用户是控制者。
-
-## 如何访问技能
-
-**在Claude Code中：** 使用`Skill`工具。当您调用技能时，其内容会加载并呈现给您——直接遵循它。永远不要在技能文件上使用Read工具。
-
-**在Gemini CLI中：** 技能通过`activate_skill`工具激活。Gemini在会话开始时加载技能元数据，并根据需要激活完整内容。
-
-**在其他环境中：** 查看您平台的文档，了解如何加载技能。
-
-## 平台适应
-
-技能使用Claude Code工具名称。非CC平台：请参阅`references/codex-tools.md`（Codex）了解工具等效项。Gemini CLI用户通过GEMINI.md自动加载工具映射。
-
-# 使用技能
-
-## 规则
-
-**在任何响应或操作之前调用相关或请求的技能。** 即使技能可能适用的可能性为1%，也意味着您应该调用技能进行检查。如果调用的技能结果证明不适合该情况，您不需要使用它。
-
-```dot
-digraph skill_flow {
-    "收到用户消息" [shape=doublecircle];
-    "即将进入计划模式？" [shape=doublecircle];
-    "已经进行头脑风暴？" [shape=diamond];
-    "调用头脑风暴技能" [shape=box];
-    "可能适用任何技能？" [shape=diamond];
-    "调用Skill工具" [shape=box];
-    "宣布：'使用[技能]进行[目的]'" [shape=box];
-    "有清单？" [shape=diamond];
-    "为每个项目创建TodoWrite待办事项" [shape=box];
-    "严格遵循技能" [shape=box];
-    "响应（包括澄清）" [shape=doublecircle];
-
-    "即将进入计划模式？" -> "已经进行头脑风暴？";
-    "已经进行头脑风暴？" -> "调用头脑风暴技能" [label="否"];
-    "已经进行头脑风暴？" -> "可能适用任何技能？" [label="是"];
-    "调用头脑风暴技能" -> "可能适用任何技能？";
-
-    "收到用户消息" -> "可能适用任何技能？";
-    "可能适用任何技能？" -> "调用Skill工具" [label="是，即使1%"];
-    "可能适用任何技能？" -> "响应（包括澄清）" [label="绝对不"];
-    "调用Skill工具" -> "宣布：'使用[技能]进行[目的]'";
-    "宣布：'使用[技能]进行[目的]'" -> "有清单？";
-    "有清单？" -> "为每个项目创建TodoWrite待办事项" [label="是"];
-    "有清单？" -> "严格遵循技能" [label="否"];
-    "为每个项目创建TodoWrite待办事项" -> "严格遵循技能";
-}
-```
-
-## 红旗
-
-这些想法意味着停止——您在合理化：
-
-| 想法 | 现实 |
-|------|------|
-| "这只是一个简单的问题" | 问题是任务。检查技能。 |
-| "我需要先了解更多上下文" | 技能检查在澄清问题之前进行。 |
-| "让我先探索代码库" | 技能告诉您如何探索。先检查。 |
-| "我可以快速检查git/文件" | 文件缺乏对话上下文。检查技能。 |
-| "让我先收集信息" | 技能告诉您如何收集信息。 |
-| "这不需要正式技能" | 如果技能存在，使用它。 |
-| "我记得这个技能" | 技能会演变。阅读当前版本。 |
-| "这不算任务" | 行动=任务。检查技能。 |
-| "技能过度了" | 简单的事情会变得复杂。使用它。 |
-| "我先做这件事" | 在做任何事情之前检查。 |
-| "这感觉很有成效" | 无纪律的行动浪费时间。技能可以防止这种情况。 |
-| "我知道那是什么意思" | 知道概念≠使用技能。调用它。 |
-
-## 技能优先级
-
-当多个技能可能适用时，使用此顺序：
-
-1. **首先是流程技能**（头脑风暴、调试）- 这些决定如何处理任务
-2. **其次是实现技能**（前端设计、mcp-builder）- 这些指导执行
-
-"让我们构建X" → 先头脑风暴，然后是实现技能。
-"修复这个错误" → 先调试，然后是领域特定技能。
-
-## 技能类型
-
-**严格**（TDD、调试）：严格遵循。不要放弃纪律。
-
-**灵活**（模式）：根据上下文调整原则。
-
-技能本身会告诉您是哪一种。
-
-## 用户指令
-
-指令说明做什么，而不是怎么做。"添加X"或"修复Y"并不意味着跳过工作流程。