Menú
任何编码开始前激活。苏格拉底式需求澄清 → 项目类型检测 → L4勘探 → 大纲先行 → 保存6节roadmap。柔性技能。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Activated before any coding begins. Socratic requirements clarification → project type detection → L4 exploration → outline-first design → save to 6-section roadmap. Flexible skill.
Activate after all tasks are complete. Confirm implementation integrity → roadmap recording → cross-project experience extraction → branch cleanup → local git commit. Rigid skill.
Activated when user explicitly invokes skill:hotfix. Emergency fix streamlined channel: mini brainstorming -> fix -> test -> closing-the-loop(mini). Flexible skill.
Activated after writing-plans completes. Execute TDD (RED→GREEN→REFACTOR) per sub-function → subagent 8-Dimension Review → Sub-function Full Testing → Full-Scenario Integration Testing after all pass. Bug fixes follow the same flow. Rigid skill.
Activate after design is approved. Break work into function-level TDD Triplet tasks → reference roadmap §4 Anti-Duplication → annotate L2/L3 reuse. Reference implementing and closing-the-loop at end of plan. Flexible skill.
所有任务完成后激活。确认实现完整性 → roadmap 记录 → 跨项目经验提炼 → 分支收尾 → 本地 git commit。刚性技能。
| name | brainstorming |
| description | 任何编码开始前激活。苏格拉底式需求澄清 → 项目类型检测 → L4勘探 → 大纲先行 → 保存6节roadmap。柔性技能。 |
四个步骤一个都不能少。将原则适配到具体上下文。
用户需求 → 第一步：需求澄清（苏格拉底式提问 + 测试场景设计）
→ 第二步：项目类型检测 + L4 勘探（项目版图 + 可复用组件）
→ 第三步：大纲先行（设计文档 → 保存 6 节 roadmap 到插件 knowledge-base）
→ 进入 writing-plans
不要假设你理解了用户的意图。 用提问来提炼模糊的想法。
| 维度 | 要搞清楚的问题 |
|---|---|
| 目标 | 要解决什么问题？谁会用它？ |
| 范围 | MVP 包含什么？什么明确不做？ |
| 约束 | 技术栈限制？性能要求？兼容性？ |
| 替代方案 | 有没有更简单的实现方式？现有工具/库能否直接解决？ |
| 验收标准 | 怎么判断做完了？怎么算"正确"？ |
| 测试场景 | 多用户隔离？权限边界？空值/null/极值？并发冲突？ |
实现会限制你的想象力。代码写完了再想测试，你只会测实现能通过的场景。
| 层级 | 覆盖范围 | 时机 |
|---|---|---|
| 子功能全量测试 | 该功能的边界/null/异常/并发，每类 ≥2 条 | implementing 阶段每个子功能完成后 |
| 全场景集成测试 | 跨功能的组合场景、完整业务流程 | 所有子功能通过后 |
| 类别 | 示例 |
|---|---|
| 多用户/隔离 | 用户 A 的数据 ≠ 用户 B 的数据；不同角色的权限边界 |
| 边界条件 | null、空列表、极大值、极短/超长输入 |
| 并发/竞态 | 同时操作冲突？重复提交？ |
| 异常路径 | 依赖服务挂了？超时？非法参数？ |
每类每层至少 2 条测试场景，写入设计大纲的"测试场景设计"栏。
knowledge-base/{项目名}/{项目名}-roadmap.md在勘探之前，先判断项目类型。 不同类型走不同的勘探清单和实现策略。
自动检测规则：
检测项：
├─ .claude-plugin/ 或 plugin.json 存在？ → 插件项目
├─ pom.xml 或 build.gradle 存在？
│ ├─ 同时有 package.json（vue/react/angular）？ → 全栈项目
│ ├─ 仅 Java 构建文件？ → 纯后端项目
│ └─ 仅 package.json？ → 纯前端项目
└─ 无构建文件？ → 通用项目（文档/脚本）
| 项目类型 | 勘探重点 | Roadmap §3 记录内容 |
|---|---|---|
| 后端 | 模块/端口/包结构、已有 DTO/Entity/Service | API 接口清单 |
| 前端 | 组件树/路由/状态管理/API 调用模式 | 组件+路由清单 |
| 全栈 | 前后端均勘探 | API + 组件清单 |
| 插件 | 技能列表/Hook/配置 | 技能+Hook 清单 |
检测结果展示给用户确认后，写入 roadmap §1（项目概览）。
在不知道项目有什么之前，你不知道什么能做。L4 是唯一真相源。
| # | 目标 | 操作 |
|---|---|---|
| 1 | 项目结构 | 列出所有模块/服务、端口、包结构、职责 |
| 2 | 已有 DTO/实体 | Glob **/dto/**, **/entity/**, **/vo/**（后端/全栈） |
| 3 | 已有工具类 | Grep **/utils/**, **/common/** |
| 4 | 已有接口 | Grep interface.*Service, interface.*Mapper（后端/全栈） |
| 5 | 代码模式 | 找 3-5 个类似功能，看分页/异常处理/返回格式 |
| 6 | 配置规则 | 配置文件在哪？Nacos？bootstrap？环境变量？ |
| 7 | 依赖清单 | pom.xml / build.gradle 中已有的关键依赖 |
输出"项目版图速查"：模块表 + 可复用关键类表 + 代码模式列表 + 本次需求相关组件。
关键：已有项目必须将现有封装方法、接口、实现形式记录到 roadmap §4（现有封装方法索引），后续实现时先查此节防重复造轮子。
项目有 >5 个模块或代码量很大时，将 7 项勘探清单拆分为 3-4 个并行 Scout 子代理：
并行派发 3-4 个 Scout 子代理（Agent 工具，只读）：
Scout A — 项目结构:
SCOPE: 项目根目录构建文件 + 所有模块目录
GOAL: 列出所有模块/服务名、端口、包结构、职责
RETURN: 模块表
Scout B — DTO/Entity + 工具类:
SCOPE: **\/dto/**, **\/entity/**, **\/vo/**, **\/utils/**, **\/common/**
GOAL: 找到已有 DTO/Entity/VO + 工具类
RETURN: 可复用类表
Scout C — 接口 + 代码模式:
SCOPE: **\/service/**, **\/controller/**
GOAL: 找到已有 Service/Controller 接口签名 + 3-5 个代码模式
RETURN: 接口列表 + 代码模式列表
Scout D — 配置 + 依赖:
SCOPE: **\/resources/*.yml|*.yaml|*.properties, pom.xml|build.gradle
GOAL: 列出配置项位置、关键依赖
RETURN: 配置摘要 + 依赖清单
小项目（≤3 模块）：主代理串行勘探即可。
在写代码之前，必须先有设计大纲。没有蓝图的施工必然返工。
| 要素 | 说明 |
|---|---|
| 要做什么 | 一句话 + 为什么 |
| 模块划分 | 新建/修改哪些文件，各自职责 |
| 数据流 | 数据从哪来 → 经过什么处理 → 到哪去 |
| 关键决策 | 为什么选这个方案（含放弃的替代方案） |
| 涉及文件 | 预估要改/新建的文件清单 |
| 影响范围 | 改了会不会影响其他功能？ |
| 验证方式 | 怎么确认改对了？ |
| 测试场景设计 | 两层 × 4 类场景，每类 ≥2 条（来自第一步） |
| 步骤 Checklist | 可勾选的施工步骤 |
所有项目统一使用 6 节 roadmap 结构（{项目名}-roadmap.md）：
# {项目名} 项目路线
## 1. 项目概览
技术栈、架构决策、项目类型
## 2. 阶段规划
每阶段目标 + Feature 清单 + 状态
## 3. 接口清单
后端 API / 前端组件路由 / 插件技能+Hook（按类型自适应）
## 4. 现有封装方法索引
已有项目的 Service/工具类/DTO/中间件等（防重复造轮子）
## 5. 实现记录
每功能的审查结果、测试覆盖、边界情况（按时间倒序）
## 6. 经验提炼
本项目踩坑 + 可跨项目复用的模式
新项目：创建 knowledge-base/{项目名}/ 文件夹，按此结构写入 roadmap。
已有项目新增功能：展示设计大纲获确认后，追加到已有 roadmap 的对应节。
experience.md 处理：已有项目如存在 experience.md，将其内容迁移到 roadmap §4（封装方法）+ §6（经验提炼），迁移后删除。不再创建新的 experience.md。
| 你的想法 | 真相 |
|---|---|
| "需求已经很清楚了" | 真清楚走一遍只需 2 分钟。花更久说明并不清楚。 |
| "项目我很熟了，不用勘探" | 项目在变。至少验证前 3 个关键类的签名。 |
| "就改一行，不写大纲" | 一行改错花 2 小时排查。花 30 秒写 mini 大纲。 |
| "测试场景跑一遍代码就知道了" | 代码写完了再想测试已经晚了——实现限制思维。 |
| "这个项目类型不用检测" | 类型决定勘探策略和 roadmap §3 内容。2 分钟检测省后续混乱。 |
进入 writing-plans 前必须确认：
knowledge-base/{项目名}/{项目名}-roadmap.md）