メニュー
代码侦察技能。给定一个需求描述或 spec，扫描 src/ 目录，输出与本次需求相关的现有模块、可复用资产、潜在冲突、推荐参考代码模式的结构化清单。被 spec-drafting 和 implementation-planning 调用，确保 spec 与 plan 都建立在「已理解现有代码」的基础上。也可由用户独立触发用于代码现状梳理。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/chongyang211/YCBookBlog --skill codebase-surveyコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
MR Spec 评审技能。当用户给出一个Git 平台（GitHub / GitLab / 工蜂） MR 地址（含 intake/design/spec/plan/tasks 任意组合的文档），要求评审他人提交的这些文档（必要时结合实施代码），并把问题作为评论回写到 MR 时使用。评审阶段**按端分流**：先识别 MR 涉及哪些端（前端/后台/识别算法/设备端/移动端SDK/跨端契约），再加载对应端的专业评审依据文档（`review-guides/`，每端含可人工追加的专业注意点专区），用各端准确视角评审、按端分组产出问题。既支持完整 spec/plan/tasks MR，也支持**只含 intake + design 的早期技术方案 MR**（结合当前代码逻辑评审 design 技术方案是否合理、给出整体评估与更优建议）。适用于跨成员 spec 评审、技术方案（design）评审、Code Review 前置的 spec 复核、迭代评审等场景。既可**本地手动执行**（人工确认后投递），也可放进**通用 AI agent / CI 流水线自主执行**（分支 push 触发、自动投递评论、多轮 loop 到无问题）。此外还提供**记忆经验提交功能**：当用户说"提交 spec review 的 memory / 推送评审经验 / 把 memory 改动提交上去"等，触发本 skill 定位工作区内的 CoSpec 仓、检测 `memory/` 是否有待提交改动，有则提交并推送到记忆分支、发起（或更新）合并到 master 的 MR（见 Step 9）。**不适用于**对自己刚完成的实施做规则回顾（那是 `/spec-review` 命令的范畴）。
MR 评审意见处理技能。当作者收到 MR 评审评论后，给出 MR 地址，要求"和 AI 一起评估这些评审意见、决定哪些需要修正"时使用。skill 拉取未解决评论 → 按风险+主题分组 → 与用户逐条评估 → 用户决策处置 → （可选）AI 自动修复 → （可选）回写评论并标 resolved。适用于代码 MR 和 spec MR，spec MR 时自动关联本地 spec 文档辅助评估。
Skill 质量与安全评审工具（融合公司白皮书规范 + 量化评分体系）。 对 Skill 进行标准化评审，输出安全红线检查 + 治理合规检查 + 五维度量化评分 + 反模式检测， 最终给出 🔴/🟡/🟢 三级准入结论和逐条改进建议。 何时使用：当团队成员编写完 Skill 需要评审、自检、质量检查、准入评估时触发。 触发场景：给 skill 评分、审核 skill、skill 质量评估、skill 打分、skill review、 检查 skill 问题、skill 准入、评审 skill、skill 合入、skill 体检、提交前自检。 不适用：不修改任何文件、不执行脚本、不判断业务逻辑正确性、不做运行时验证。
| name | codebase-survey |
| description | 代码侦察技能。给定一个需求描述或 spec，扫描 src/ 目录，输出与本次需求相关的现有模块、可复用资产、潜在冲突、推荐参考代码模式的结构化清单。被 spec-drafting 和 implementation-planning 调用，确保 spec 与 plan 都建立在「已理解现有代码」的基础上。也可由用户独立触发用于代码现状梳理。 |
理解现有代码实现，识别新需求与现有代码的关联，输出结构化报告。
AI 没看代码就起草 spec/plan，本质上是另一种"vibe coding"。代码侦察是显式化这个步骤，让产出可验证、可复用、可沉淀。
支持两种深度，由调用方指定：
| 模式 | 调用方 | 关注粒度 | 阅读深度 | 输出位置 |
|---|---|---|---|---|
| light | spec-drafting（阶段零） | 模块级 | 接口 / 入口 / 注释 | spec 的「实施备注」+「关键代码参考」 |
| deep | implementation-planning（阶段二） | 文件 / 函数级 | 实现细节 / 调用链 / 设计模式 | plan 的「改动范围」+「关键代码参考」+「实施步骤」参考字段 |
用户也可以独立触发（如"帮我看下 wecardexample-app 现状"），此时默认 light 模式。
src/example-gateway/、src/wecardexample-app/）interface.go / 主入口 / service.go按以下维度归类：
按调用模式选择对应输出格式（见下文）。
docs/research/NNNN-codebase-survey.md（可选）### 代码侦察报告（light）：[需求标题]
**相关模块**：
| 模块路径 | 作用 | 与本需求关系 |
|---------|------|-------------|
| `src/example-gateway/` | API 网关 | 需新增示例业务 HTTP 接口 |
| `src/wecardexample-app/` | 业务应用层 | 需新增示例业务 controller |
**可复用资产**：
- `utils.GenerateUint64FromUUID()` — `src/common/utils/uuid.go` — 用于生成 biz_id
- `middleware.GetUserIdFromContext()` — `src/.../middleware/path_based.go` — 用于获取 user_id
**冲突 / 重叠**：
- 与现有 specs/<其他 STORYID> 的 X 功能可能重叠 — 建议[合并/独立/明确边界]
- 不与现有 spec 冲突
**推荐参考的代码模式**：
| 要做什么 | 参考文件 |
|---------|---------|
| Controller 9 步流程 | `controller/example-module/enroll-flow/login.go` |
| 示例通道 调用 | `common/example-vendor/providers/wechat/register.go` |
**初步影响估计**：
- 预计需要新增：N 个文件（粗估）
- 预计需要修改：M 个文件（粗估）
- 跨模块：是 / 否
- 跨仓库：是 / 否（如涉及 proto 仓）
**不确定项 / 需要人确认**：
- [ ] 现有 X 模式是否还推荐使用？
- [ ] 是否有内部约定我没扫到的？
### 代码侦察报告（deep）：Spec NNNN
**改动文件清单**（精确到文件 + 关联 FR）：
| 操作 | 文件 | 关联 FR | 说明 |
|------|------|---------|------|
| 新增 | `src/.../online_register.go` | FR-3 | gateway 服务方法 |
| 修改 | `src/.../service.go` | FR-3 | 新增 GetExampleAppClient |
| 修改 | `src/.../config.yaml` | FR-3 | 新增 wecardexample-app 服务地址 |
**调用链分析**：
HTTP POST /api/v1/example/online-register → PathBasedMiddleware → HTTPTokenMiddleware（取 user_id） → example-gateway.OnlineRegister（透传） → wecardexample-app.OnlineRegister（业务逻辑） → example-vendor.wechat.OnlineRegister（远端调用） → <业务主仓库>.PrivateRecognition.OnlineRegister
**接口影响**：
- 新增公共接口：[列表]
- 修改公共接口：[列表 + 是否兼容]
- 影响的调用方：[列表]
**已有设计模式**（必须遵循）：
| 模式 | 参考实现 | 关键约束 |
|------|---------|---------|
| Controller 9 步流程 | `enroll-flow/login.go` | 配额预扣 → 失败回退；状态更新失败不回退配额 |
| 示例通道 | `wechat/register.go` | 30s 超时；TraceID 优先做 session_id |
| 日志脱敏 | `sensitive.MaskSensitiveValue` | 禁用 `%+v` 打印请求结构体 |
**影响范围风险**：
| 风险 | 概率 | 应对 |
|------|------|------|
| Proto 改动需先合并 <协议仓库> | 高 | 本地用 replace 联调，提交前去掉 |
| 鉴权路径误命中其他中间件 | 低 | 已验证不命中 |
**不确定项 / 需要人确认**：
- [ ] 错误码 100034-100037 是否有冲突？
- [ ] FRegisterType 用 Mobile 还是新增 Online？
interface.go / 入口文件，按需向下深入spec-drafting (阶段零)
└─ 调用 → codebase-survey (light)
└─ 输出合并到 spec 的「实施备注」+「关键代码参考」
implementation-planning (阶段二)
└─ 调用 → codebase-survey (deep)
└─ 输出合并到 plan 的「改动范围」+「关键代码参考」
feature-implementation (阶段三)
└─ 不调用 codebase-survey（按 plan 执行；改文件前的局部读取由 rules/20-coding-rules.md 规定）
skills/spec-drafting/SKILL.md、skills/implementation-planning/SKILL.mdrules/10-spec-workflow.md 阶段零、阶段二docs/research/NNNN-codebase-survey.md（仅在大型跨模块需求时使用）