@kunlv/atdc 1.0.0

package/prompts/X-add-to-hc.md

@@ -0,0 +1,178 @@
+# prompts/X-add-to-hc · 添加接口到 .hc HTTP Client
+
+横向命令，触发词：add-to-hc、add to hc、/atdc:add-to-hc、加接口、添加 hc
+
+---
+
+## 目标
+
+将新的 API 接口添加到 ticket_center_server 的 `.hc/external_routes.http`，生成可用的 HTTP Client 测试条目。
+
+---
+
+## Phase 0：定位目标文件
+
+优先读取 `~/.atdc/config/hc-target.txt` 获取用户配置的 .hc 目录路径。
+若不存在该文件，使用默认路径：
+
+```
+/Users/lvkun/Documents/Codes/ticket_center_server.TASK-235057_QYinInternalMsg/.hc
+```
+
+然后读取以下文件以了解现有结构：
+
+```bash
+cat <hc-dir>/external_routes.http
+cat <hc-dir>/http-client.env.json
+```
+
+---
+
+## Phase 1：解析用户输入
+
+用户可能提供以下形式之一：
+
+| 输入类型 | 示例 |
+|---------|------|
+| 结构化 | `POST /v1/order/refund_apply 申请退款 {"order_no":"xxx"}` |
+| 仅路径 | `/v1/ticket/recommend_list` |
+| 自然语言 | "加一个获取演出推荐的接口" |
+| 仅路径+描述 | `/v1/user/follow_list 获取关注列表` |
+
+解析出以下字段（缺失的按模板推断或反问）：
+- **method**: GET/POST（路径含 `list/detail/info/count` → GET，`create/submit/cancel/do/register` → POST）
+- **path**: 完整路径（如 `/v1/order/refund_apply`）
+- **description**: 中文描述（如未提供，按规则生成）
+- **body**: POST 时的 JSON body（可选，缺失则反问）
+
+---
+
+## Phase 2：模板匹配
+
+### 2a. 鉴权模板（根据路径前缀自动匹配）
+
+| 路径前缀 | 鉴权方式 | 预请求脚本 | 公参模板 |
+|---------|---------|-----------|---------|
+| `/v1/ticket/` | 标准签名 | `< sign.js` | `appid={{appid}}&clientver={{clientver}}&clienttime={{$timestamp}}&mid={{mid}}&uuid={{uuid}}&dfid={{dfid}}&userid={{userid}}&token={{token}}&signature={{signature}}` |
+| `/v1/banner/` | 标准签名 | `< sign.js` | 同上 |
+| `/v1/search/` | 标准签名 | `< sign.js` | 同上 |
+| `/v1/config/` | 标准签名 | `< sign.js` | 同上 |
+| `/v1/wish/` | 标准签名 | `< sign.js` | 同上 |
+| `/v1/celebrity/` | 标准签名 | `< sign.js` | 同上 |
+| `/v1/user/collect*` | UserToken | `< sign.js` | 标准公参 + `&app_third_code={{app_third_code}}` |
+| `/v1/user/subscribe*` | UserToken | `< sign.js` | 同上 |
+| `/v1/user/wish/` | UserToken | `< sign.js` | 同上 |
+| `/v1/user/celebrity/` | UserToken | `< sign.js` | 同上 |
+| `/v1/user/missing*` | UserToken | `< sign.js` | 同上 |
+| `/v1/order/` | UserToken | `< sign.js` | 同上 |
+| `/v1/refund/` | UserToken | `< sign.js` | 同上 |
+| `/v1/ticket_folder/` | 无签名 | 无 | `userid={{userid}}&token={{token}}` |
+| `/inner/v1/` | 无签名 | 无 | 按已有条目推断 |
+| `/qqmusic/v1/` | Q音 | 按已有条目推断 | 按已有条目推断 |
+
+### 2b. 中文描述模板（未提供时自动生成）
+
+| method + 路径后缀 | 生成描述 |
+|------------------|---------|
+| GET */list | 获取...列表 |
+| GET */detail | 获取...详情 |
+| GET */info | 获取...信息 |
+| GET */count | 获取...数量 |
+| GET */status | 查询...状态 |
+| GET */hot_list | 获取...热门列表 |
+| GET */popular_list | 获取...精选列表 |
+| POST */create | 创建... |
+| POST */submit | 提交... |
+| POST */cancel | 取消... |
+| POST */do | 执行...操作 |
+| POST */register | ...登记 |
+| POST */check | 核验... |
+
+路径中间的英文名自动翻译为中文关键词：
+- ticket → 演出/票品
+- order → 订单
+- refund → 退款
+- subscribe → 预约
+- celebrity → 歌手
+- wish → 许愿
+- search → 搜索
+- banner → Banner
+- config → 配置
+- user → 用户
+
+### 2c. 分类 Section 匹配
+
+| 路径前缀 | 插入位置 |
+|---------|---------|
+| `/v1/ticket/` | 一、演出（ticket）末尾 |
+| `/v1/banner/` | 二、Banner 末尾 |
+| `/v1/user/collect*` `/v1/user/subscribe*` `/v1/user/performance_show*` | 三、想看 / 预约 末尾 |
+| `/v1/user/missing*` | 四、缺票登记 末尾 |
+| `/v1/order/` | 五、订单 末尾 |
+| `/v1/search/` | 六、搜索 末尾 |
+| `/v1/ticket_folder/` | 七、票夹 末尾 |
+| `/v1/refund/` | 八、退款 末尾 |
+| `/v1/config/` | 九、配置 末尾 |
+| `/v1/user/wish/` | 十、许愿加场 末尾 |
+| `/v1/celebrity/` `/v1/user/celebrity/` | 十一、歌手页 末尾 |
+| `/qqmusic/v1/` | 十二、Q音专属路由 末尾 |
+| `/inner/v1/` | 文件末尾（新建 section 或插入已有 section） |
+
+---
+
+## Phase 3：生成条目
+
+### GET 请求格式
+
+```
+### <描述>
+[< sign.js 或 < sign_server.js 或 无]
+GET {{BASE_URL}}{{PREFIX}}<path>?<公参>[&业务参数]
+```
+
+### POST 请求格式
+
+```
+### <描述>
+[< sign.js 或 < sign_server.js 或 无]
+POST {{BASE_URL}}{{PREFIX}}<path>?<公参>
+Content-Type: application/json
+
+[<JSON body>]
+```
+
+### 规则
+
+1. 公参按 Phase 2a 的鉴权模板填写
+2. 业务参数追加在公参后面（GET 的 query 参数在 URL 中，POST 的在 body 中）
+3. POST 无 body 时省略 body 部分
+4. 无鉴权时 `< script` 行省略，Content-Type 也省略（除非 POST 有 body）
+5. 描述用 `###` 注释分隔，空行与已有条目保持一致
+
+---
+
+## Phase 4：插入文件
+
+1. 在 `external_routes.http` 中找到对应 section 的 `###` 起始注释行
+2. 在该 section 最后一个请求条目之后、下一个 section（`# ───` 或 `###` 开头的新 section）之前插入
+3. 前后各保留一个空行，与已有格式一致
+4. 用 **Edit 工具** 精确插入，不要重写整个文件
+
+---
+
+## Phase 5：输出确认
+
+插入后输出一行确认：
+
+```
+✓ 已添加 [method] [path] → .hc/external_routes.http（[section名]，第[N]行）
+```
+
+---
+
+## 特殊情况处理
+
+- **路径前缀不在已知模板中**：反问用户鉴权方式（1=标准签名 2=UserToken 3=服务间 4=无签名）
+- **POST 无 body 描述**：反问 "这个 POST 接口是否有 request body？"
+- **路径冲突（已存在）**：提示已存在，询问是否覆盖
+- **无法推断分类**：插入到文件末尾，并在注释中标注 "Chore: 未分类"

package/prompts/X-analysis-cls-log.md

@@ -0,0 +1,68 @@
+# prompts/X-analysis-cls-log · CLS 日志分析
+
+从此文件读取后直接开始执行，无需用户再次确认。
+
+---
+
+## 输入
+
+日志文件路径：`$ARGUMENTS`
+
+若未指定路径 → 提示"请提供日志文件路径，如 /atdc:analysis-cls-log ~/.cls/logs/tcs_xxx.jsonl"，停止。
+
+---
+
+## Step 1：读取日志文件
+
+```bash
+cat $ARGUMENTS | head -500
+```
+
+若文件不存在或为空 → 停止。
+
+---
+
+## Step 2：执行分析
+
+读取 cls-log-investigation 的排查流程并按需执行：
+
+```
+Read /Users/lvkun/Documents/Codes/agent-skills/cls-log-investigation/SKILL.md
+Read /Users/lvkun/Documents/Codes/agent-skills/cls-log-investigation/references/decision-rules.md
+Read /Users/lvkun/Documents/Codes/agent-skills/cls-log-investigation/references/topics.yaml
+```
+
+1. **日志分类**：统计 ERROR / WARN / INFO 数量和占比
+2. **异常识别**：提取错误码、异常堆栈、重复模式
+3. **噪声过滤**：排除已知噪声（如 Apollo 空值 WARN、cfgcenter 504 等）
+4. **根因推断**：基于日志锚点 + 错误码给出可能根因
+5. **分级结论**：查证级 / 模块级 / 行级
+
+---
+
+## Step 3：输出报告
+
+按报告模板格式生成报告：
+
+```
+Read /Users/lvkun/Documents/Codes/agent-skills/cls-log-investigation/references/report-template.md
+```
+
+```
+.cls-reports/{文件名}-analysis.md
+```
+
+报告必须包含：
+- 一句话结论
+- 要不要改代码（改 / 先别动 / 待验证）
+- 行动清单
+- 什么情况下推翻结论
+- 代码语义（日志锚点 → 源码含义）
+- 已确认日志事实
+- 根因推断
+- 不确定项
+
+```bash
+mkdir -p .cls-reports
+# 写入报告文件
+```

package/prompts/X-bugfix.md

@@ -0,0 +1,10 @@
+# prompts/X-bugfix · Bugfix 5-Phase 流程
+
+横向命令，任意时刻可触发：`/atdc:bugfix <args>`
+
+## 执行步骤
+
+### 1. 确定输入
+
+### 2. 执行
+

package/prompts/X-code-simplifier.md

@@ -0,0 +1,38 @@
+# prompts/X-code-simplifier · 代码简化
+
+横向命令，基于 `code-simplifier` skill 对代码进行简化、精炼和清理。
+
+---
+
+## Step 0：确保 skill 已安装
+
+```bash
+if [ ! -f ~/.agents/skills/code-simplifier/SKILL.md ]; then
+  npx skills add aktsmm/agent-skills@code-simplifier -g -y
+fi
+```
+
+## 执行
+
+1. 用 Skill 工具加载 `code-simplifier` skill
+2. 按 skill 中的规则对目标代码进行简化：
+   - 保留功能不变
+   - 遵循项目编码规范
+   - 增强可读性（减少嵌套、消除冗余、清晰命名）
+   - 仅处理最近修改或用户指定的代码范围
+3. 简化完成后运行测试确保无回归
+
+## 参数
+
+| 参数 | 模式 |
+|------|------|
+| 文件路径 | 简化指定文件 |
+| `PR` / `diff` | 简化当前分支变更 |
+| 无参数 | 简化最近修改的文件 |
+
+## 完成标准
+
+- [ ] 所有测试通过
+- [ ] 功能无变化
+- [ ] 代码符合项目规范
+- [ ] 无新增过度抽象

package/prompts/X-commit.md

@@ -0,0 +1,116 @@
+# prompts/X-commit · Git Commit Message 规范化生成
+
+横向命令，任意时刻可触发：`/atdc:commit`。基于 `git diff` 生成符合 Conventional Commits 规范的提交信息。
+
+---
+
+## 规范
+
+### 格式
+
+```
+<type>(<scope>): <subject>
+
+<body>
+```
+
+### Type 类型
+
+- `feat`: 新功能
+- `fix`: Bug 修复
+- `docs`: 文档更新
+- `style`: 代码格式调整（不影响逻辑）
+- `refactor`: 重构（既不是新功能也不是修复）
+- `perf`: 性能优化
+- `test`: 测试相关
+- `chore`: 构建过程或辅助工具变动
+
+### 规则
+
+1. subject 使用中文，不超过 50 字
+2. subject 不要以句号结尾
+3. scope 用英文小写，表示影响范围（如 auth、api、ui）
+4. body 部分可选，用于解释 why 而不是 what
+5. 如果有 Breaking Change，必须在 body 中用 `BREAKING CHANGE:` 说明
+6. 使用祈使语气（"添加"、"修复"、"删除"，而非"添加了"、"已修复"）
+
+### 禁止出现
+
+- "This commit"、"I"、"we"、"目前"、"现在" — diff 本身说明了 what
+- Emoji（除非项目规范要求）
+- 在 scope 已明确时重复文件名
+- 任何 AI 归属标注（"Generated with..."）
+
+### 何时必须写 body
+
+- Breaking changes
+- 安全修复
+- 数据迁移
+- 回滚之前的 commit
+- 非显而易见的意图
+
+### 示例
+
+```
+feat(auth): 添加微信扫码登录功能
+
+fix(api): 修复用户列表分页参数错误
+
+refactor(utils): 重构日期格式化工具函数
+
+提取公共逻辑，支持更多日期格式
+```
+
+---
+
+## 执行步骤
+
+### Step 1：获取变更内容
+
+```bash
+git diff --staged
+```
+
+如果 staged 区为空，检查 `git diff`（未暂存的变更）。如果仍为空，提示用户先 `git add`。
+
+### Step 2：分析变更
+
+阅读 diff 内容，判断：
+- 变更类型（feat / fix / refactor / ...）
+- 影响范围（scope）
+- 变更意图（why）
+
+### Step 3：生成 commit message
+
+按上述规范生成，以代码块形式输出。如果变更有非显而易见的意图，补充 body。
+
+### Step 4：请用户确认
+
+以代码块输出 message，询问用户：
+- **确认执行** → 立即 `git commit -m "<message>"`
+- **需要修改** → 按用户要求调整后重新确认
+- **仅查看** → 不执行
+
+**规则**：`git commit` 必须在用户明确确认后才能执行，禁止跳过确认自动提交。
+
+---
+
+## 参数
+
+| 参数 | 行为 |
+|------|------|
+| 无参数 | 读取 `git diff --staged` |
+| `--unstaged` | 读取 `git diff`（未暂存变更） |
+| `--range <ref>` | 读取指定范围的 diff，如 `--range HEAD~3` |
+| `--amend` | 读取上次 commit 的变更，用于修正 commit message |
+
+---
+
+## 完成标准
+
+- [ ] 生成的 message 符合 Conventional Commits 格式
+- [ ] subject 为中文，不超过 50 字，无句号
+- [ ] scope 为英文小写
+- [ ] body 解释了 why（如需要）
+- [ ] Breaking Change 已用 `BREAKING CHANGE:` 标注（如适用）
+- [ ] `git commit` 仅在用户明确确认后执行

package/prompts/X-compound.md

@@ -0,0 +1,188 @@
+# prompts/X-compound · 知识沉淀
+
+横向命令，将已解决的问题结构化沉淀到个人知识库 `~/Documents/Obsidian/Docs/`，按类别归档。
+
+---
+
+## 目标
+
+捕获问题解决方案，让知识复利。第一次解决某个问题需要调研，记录后下次只需几分钟。
+所有知识统一存储于个人 Obsidian 知识库，跨项目复用。
+
+---
+
+## Phase 0：判断模式
+
+检查参数：
+
+- **无参数** → Phase 1（交互式，选择沉淀目标）
+- **`<change-name>`** → Phase 2（从指定 change 提取知识）
+- **`session`** → Phase 3（从当前 session 提取）
+- **`concepts`** → Phase 5（仅更新 CONCEPTS.md）
+- **`skills`** → Phase 6（扫描未晋升的 harvested skill，提示晋升候选）
+
+---
+
+## Phase 0.5：确定归类目录
+
+根据解决方案类型，选择 Docs 下的子目录：
+
+| 目录 | 适用场景 |
+|------|---------|
+| `claude-code/` | Claude Code / opencode 配置、调试、工具链 |
+| `ai-tools/` | AI 辅助开发工具、MCP Server、Skill |
+| `development/` | 通用开发技巧、语言特性、框架用法 |
+| `gsd/` | GSD 相关（目标-场景-决策框架）|
+| `atdc/` | atdc 工作流使用经验 |
+| `cursor/` | Cursor IDE 配置和技巧 |
+| `kugou/` | Kugou 业务相关 |
+
+不确定归类时，提示用户选择。
+
+---
+
+## Phase 1：选择沉淀目标
+
+输出选项让用户选择：
+
+```
+📚 知识沉淀 — 选择来源：
+
+1. 从已归档的 change 提取（列出最近 5 个）
+2. 从当前 session 提取（本次对话中解决的问题）
+3. 手动描述一个已解决的问题
+
+选择：
+```
+
+选择后进入对应 Phase。
+
+---
+
+## Phase 2：从归档 change 提取
+
+```bash
+# 列出最近归档的 changes
+ls -t openspec/changes/archive/ 2>/dev/null | head -5
+```
+
+1. 读取选中 change 的 `proposal.md` 和 `design.md`
+2. 提取：解决了什么问题、用了什么方案、排除了什么
+3. 进入 Phase 4
+
+---
+
+## Phase 3：从当前 session 提取
+
+回顾当前 session 的对话历史，识别：
+
+1. **解决过的问题**：bug 修复、架构决策、技术选型
+2. **排除过的方案**：尝试过但不 work 的路径
+3. **有价值的教训**：超过 2 次尝试才解决的问题
+
+提取后进入 Phase 4。
+
+---
+
+## Phase 4：生成知识文档 + 可选更新 CONCEPTS
+
+### 4a. 生成 solution 文档
+
+参考 `@atdc/templates/solution.md`，生成 `~/Documents/Obsidian/Docs/<category>/<topic>.md`：
+
+- **YAML frontmatter 必填**：title, date, tags, difficulty, module
+- **可检索关键词**：3-5 个，用于未来模糊匹配
+- **控制篇幅**：每个文档 20-40 行，不展开代码细节（指向源文件）
+
+```bash
+mkdir -p ~/Documents/Obsidian/Docs/<category>
+# 写入 ~/Documents/Obsidian/Docs/<category>/<topic>.md
+```
+
+### 4b. 检测是否需要更新 CONCEPTS
+
+检查本次沉淀是否引入了新的领域概念：
+
+1. 读取项目根目录 `CONCEPTS.md`
+2. 比对 solution 中出现的术语
+3. 有新概念 → 提示用户是否更新 CONCEPTS.md
+
+```
+检测到新的领域概念：
+- <概念 A>：在本次 solution 中出现，未记录在 CONCEPTS.md
+- <概念 B>：同上
+
+是否更新 CONCEPTS.md？（y/n）
+```
+
+用户确认后，将新概念追加到 CONCEPTS.md 对应表格中。
+
+### 4c. 可发现性检查
+
+知识已存入 Obsidian Docs 个人知识库，具备 Obsidian 原生搜索 + 反向链接能力，无需额外发现性配置。跳过。
+
+---
+
+## Phase 5：仅更新 CONCEPTS.md
+
+用户指定 `concepts` 参数时：
+
+1. 扫描项目源码，识别领域实体和命名流程
+2. 读取现有 `CONCEPTS.md`
+3. 补充缺失的概念，更新过时的描述
+4. 如果 CONCEPTS.md 不存在，参考 `@atdc/templates/concepts.md` 创建
+
+---
+
+## Phase 6：完成
+
+输出：
+
+```
+✅ 知识沉淀完成
+
+新增文档：~/Documents/Obsidian/Docs/<category>/<topic>.md
+CONCEPTS.md：<已更新 / 无需更新 / 未创建>
+
+沉淀的知识已存入 Obsidian Docs，可通过 Obsidian 搜索和反向链接发现。
+可随时运行 /atd compound 沉淀更多知识。
+```
+
+---
+
+## Phase 6：扫描未晋升的 harvested skill
+
+用户指定 `skills` 参数，或 Phase 1 交互中选择此项时：
+
+### 6a. 扫描 .memory.md 中的 🧠 条目
+
+```bash
+_PROJ=$(basename "$(git worktree list 2>/dev/null | head -1 | awk '{print $1}')" 2>/dev/null || basename "$PWD")
+grep "^## 🧠" "$HOME/.atdc/memory/$_PROJ/.memory.md" 2>/dev/null || echo "[无 learned-skill 条目]"
+```
+
+### 6b. 检查是否满足 promotion rule
+
+对每条 🧠 条目：
+1. 读取完整内容（Read 工具）
+2. 检查是否有 `failure:` 字段（命名失败模式）
+3. 检查是否有 `dead-end:` 字段（排除的死路）
+4. 检查是否有 passing check（从 change 关联推断）
+
+### 6c. 输出晋升候选
+
+```
+🔍 Learned-skill 晋升扫描
+
+已记录的 🧠 learned-skill 条目：
+1. learn-db-connect — 缺 passing check（未记录验证方式）
+2. learn-deploy-staging — ✅ 满足 promotion rule 3 条 → 可晋升为 /atdc:learn-deploy-staging
+
+选择：输入编号 + "promote" 晋升为 atd 命令，或 "skip"。
+```
+
+### 6d. 晋升
+
+对选中的条目，调用 `add-command.py --from-learn` 生成 atd 命令（同 X-learn.md Phase 3）。
+
+```

package/prompts/X-context-scan.md

@@ -0,0 +1,101 @@
+# prompts/X-context-scan · 老项目首次入场扫描
+
+横向命令，老项目第一次使用 atdc 时触发。
+
+---
+
+## 目标
+
+生成 `CONTEXT.md`，让后续所有 change 不需要重新扫描项目基础信息。
+
+---
+
+## 扫描内容
+
+### 1. 技术栈识别
+
+```bash
+# 语言/框架
+ls go.mod package.json pom.xml requirements.txt 2>/dev/null
+# 主要依赖
+head -30 go.mod 2>/dev/null || head -30 package.json 2>/dev/null
+```
+
+### 2. 目录结构
+
+```bash
+find . -type d -not -path "*/\.*" -not -path "*/vendor/*" -not -path "*/node_modules/*" | head -40
+```
+
+### 3. 命名风格
+
+```bash
+# 优先用 CodeGraph（已索引则无需 grep）
+# codegraph_files 查看文件列表 + codegraph_search 抽样几个函数名即可
+
+# 无 CodeGraph 时才用（限制输出行数）
+grep -rn "^func " --include="*.go" . | grep -v vendor | head -15
+```
+
+### 4. 既有抽象识别
+
+重点扫描以下能力有无现成实现：
+- HTTP 客户端封装
+- 缓存读写（Redis/本地）
+- 日志工具
+- 错误处理模式
+- 数据库操作封装
+- 配置加载
+
+### 5. 禁动清单
+
+读取 AGENTS.md / CLAUDE.md，提取明确的约束和禁止操作。
+
+### 6. 策略与领域词汇（可选）
+
+```bash
+cat STRATEGY.md 2>/dev/null && echo "---EXISTS---" || echo "[无 STRATEGY.md]"
+cat CONCEPTS.md 2>/dev/null && echo "---EXISTS---" || echo "[无 CONCEPTS.md]"
+```
+
+- **STRATEGY.md 不存在** → 提示用户可运行 `/atd strategy` 创建产品策略锚点
+- **CONCEPTS.md 不存在** → 提示用户可运行 `/atd compound concepts` 生成领域词汇表
+
+---
+
+## 输出
+
+写入 `CONTEXT.md`（项目根目录）：
+
+```markdown
+# CONTEXT — <项目名>
+
+扫描时间：<日期>
+
+## 技术栈
+- 语言：
+- 主框架：
+- 数据库：
+- 消息队列：
+
+## 目录结构摘要
+<关键目录说明>
+
+## 命名风格
+- 函数：驼峰 / 下划线
+- 文件：
+- 包名：
+
+## 既有抽象（写新代码前必须先 grep 这些）
+| 能力 | 位置 | 用法示例 |
+|------|------|---------|
+| HTTP 客户端 | pkg/httpclient/ | httpclient.Get(...) |
+
+## 禁动清单
+- <从 AGENTS.md 提取>
+
+## 引入新依赖审批
+需要在 change propose 阶段说明理由并获得人工确认。
+```
+
+写完输出：`✓ CONTEXT.md 已生成，后续 change 将自动读取。`