god: Skill for Claude Code

需求转化为施工图 (Demand Distillation)

目标

将模糊的需求描述转化为下游 AI（Cursor、Trae 等）可 100% 成功执行的 SKILL.md。

核心逻辑

1. [需求关键词提取]：在做任何分析之前，先从需求文件中逐字扫描，提取所有明确提到的：

   • 技术概念（如：某个框架、某个协议、某个服务……）
   • 功能模块（如：登录、告警、缓存、重试……）
   • 约束条件（如：支持并发、离线环境……）

   将提取结果列为一张清单，后续每个步骤必须能在清单中找到对应项。 Blueprint 生成后，必须对照此清单逐项核查覆盖情况，有遗漏则补充，不得跳过任何一项。

0.5. [前置条件推断]：根据关键词清单，推断每项技术正常运行所需的必要外部条件（如：连接信息、账号凭证、服务地址、版本要求、运行时依赖等）。

逐项检查需求文件中是否已提供：

• 已提供：记录，继续
• 未提供：必须在继续分析前向用户追问，格式如下：

  "我注意到需求中使用了 {技术X}，但以下信息未提供，请补充后我再出施工图：

  1. {缺失信息1}（用途：xxx）
  2. {缺失信息2}（用途：yyy）"

此步骤禁止假设或硬编码任何默认值，必须由用户明确提供。

1. [上下文检索]：向上查找 ARCH.md。根据结果分三种情况处理：

   • 找到 ARCH.md：直接使用，进入第 2 步
   • 未找到，但需求文件中有源码路径： 告知用户：

     "用户指定的源码目录尚未建立技术档案，我将使用 project-analysis 技能分析源码，自动生成 ARCH.md，再继续出施工图。" 执行 project-analysis 技能分析源码路径，生成 ARCH.md，然后继续

   • 未找到，且源码目录为空或无源码路径： 告知用户：

     "用户指定的源码是空项目，且没有 ARCH.md，我将根据需求文件中指定的技术信息生成初始 ARCH.md，请确认后继续。" 按需求文件中提取的技术信息生成 ARCH.md 模板（参考「ARCH.md 规范 - 模式二」），提醒用户确认后继续

2. [冲突检查]：检查新需求是否违反了 ARCH.md 里的规范及「用户补充说明」模块。

3. [完整覆盖]：一个需求只产出一份 SKILL.md，不拆分。所有涉及的模块和改动都在同一份施工图中完整描述。

4. [防御性提醒]：针对当前项目技术栈，列出 3 个最容易出错的坑，写入 [Blueprint] 模块。

输出格式

产出的 SKILL.md 必须以标准 YAML frontmatter 开头：

---
name: {需求名，小写加连字符}
description: {一句话说明该技能的用途和触发场景}
---

正文必须包含以下三个模块：

## [Context]
当前需求背景、涉及的项目模块和文件范围。

## [Blueprint]
方案设计：做什么、为什么这样做、需注意的 3 个易错点。
**必须在 Blueprint 末尾附上关键词覆盖清单，逐项确认（关键词来自步骤 0 的提取结果）：**
- ✅ {关键词1}：通过 xxx 方式实现
- ✅ {关键词2}：通过 yyy 方式实现
- ✅ {关键词3}：通过 zzz 实现

## [Implementation Steps]
按时序排列的实施步骤。

每个涉及新增或修改的函数，必须提供完整伪代码，格式如下：

~/xxx/xxx.go
func 函数名(参数 类型) 返回值 {
    // step1. 用中文描述这一步做什么
    // step2. 通过 xxx 函数获取 xxx
    // step3. 用 yyy 算法计算 xxx，注意 zzz 边界条件
}

要求：
- 函数名、参数名、返回值类型必须与目标工程的实际命名规范一致
- 步骤描述用中文，简洁说明意图，不写具体代码
- 每个 step 对应一个操作单元，粒度不超过 5 行逻辑
- 若函数内调用了其他新增函数，被调用函数也必须单独列出伪代码

路径写法规范

[Implementation Steps] 中所有文件路径必须使用 ~/ 表示目标工程根目录：

• ✅ ~/package.json、~/src/index.ts、~/internal/handler/user.go
• ❌ 任何绝对路径（/Users/...）
• ❌ god 工作台自身的路径（projects/xxx/...）