| name | team-command-dev |
| description | Execute the dev workflow from this AI development team preset. Use when the user writes /dev, asks for dev, or wants the corresponding team process in Codex. |
team-command-dev
This skill ports the Claude Code /dev command workflow to Codex.
In Codex, invoke this as $team-command-dev. Do not rely on /dev unless Codex itself defines that slash command with the same meaning.
/dev - 开发流程
一句话需求进，可运行代码出。你只管确认，AI 管流程。
Project Preset Lifecycle
开始前运行 node create-claude-team/cli.js project-preset context --json。当结果为 pass 时，按 PRESET.md -> rules -> specs -> base/技术栈 preset 顺序读取；只读取与当前实现相关的 .agents/rules/specs。结果为 needs_revision 时，不得静默把 project-preset 当作项目事实，先说明 project-preset validate 的修复项。不存在 project-preset 时，继续使用 base 和已安装技术栈 preset，不阻塞既有项目，并按需建议 /project-preset。
若项目根目录有 roadmap.md（由 /plan 生成）且你指定了某模块（如"做模块 M3"或"做向量检索模块"）：
先读 roadmap.md，复用该模块的描述、依赖、复杂度，跳过产品级提问（仍可问实现细节）。
依赖模块未完成时先提醒；模块开始时更新为 in_progress；模块完成后把 roadmap.md 中的模块状态更新为 done、刷新最近更新日期，并在进度区打勾。
roadmap.md 模块状态联动
当用户说 /dev 做模块 M3、/dev 做向量检索模块 或类似表达时，AI 必须把 roadmap.md 作为产品模块状态源：
- 读取
roadmap.md 的功能模块表，定位模块 ID、状态、描述、复杂度、依赖、验收标准、风险、最近更新。
- 检查依赖模块是否为
done 或 shipped；依赖未满足时先提醒用户，不直接开工。
- 存在 Controlled Delivery Contract 时，先运行
delivery preflight；只有 pass 后才能把目标模块状态更新为 in_progress，刷新最近更新日期为当天。
- 开发中复用 roadmap 的模块描述、复杂度和验收标准，不重新询问产品级问题。
- 模块完成后把状态更新为
done，刷新最近更新日期，并在 ## 进度 区把对应模块打勾。
- 如果模块被发布流程确认上线，可由
/ship 或后续维护把状态从 done 更新为 shipped。
- 如果遇到阻塞，把状态更新为
blocked，在风险或未决区记录阻塞原因，并在 Summary 的 next action 中说明需要谁确认什么。
roadmap.md 的模块状态使用：planned / in_progress / blocked / done / shipped。
Architecture Context
对 L/XL 模块，存在根目录 architecture.md 时，必须在 Product Brief、Product Model 和 roadmap 后读取它，再生成 spec/tasks 或开始实现：
- 从 roadmap 取得 Architecture Component ID，并确认本次变更支撑的 Capability ID、Journey ID 和用户结果。
- 检查依赖方向、跨组件接口、安全边界、迁移和兼容影响；不得通过 status、Workbench 或 legacy 视图绕过上游事实。
- 如果变更会改变组件职责、跨组件接口、安全边界、兼容策略或迁移路径，必须在架构预分析后按固定格式输出 Owner Decision Brief，并给出推荐；不得只用普通建议或“需要 Owner 决策”一句话代替。普通局部实现无需阻塞。
- feature spec 必须记录 Architecture Component ID、受影响组件、依赖方向和验证方式；N4 再统一引用格式和自动校验。
没有 architecture.md 的旧项目可以按现有流程继续；不要为了补文档而阻塞低风险修复。
Planning Artifact Context
对存在 .claude/workspace/planning/artifact-contract.md 的项目，M/L/XL 开工前必须在 Architecture 后读取它：
- roadmap 是模块状态源，feature
tasks.md 是当前执行状态源，events/review/release 是证据；不得用其中一个覆盖另一个。
- feature spec 必须使用合同的最小头部：Module、Capability、Journey、Architecture Component、Affected Components、Dependency Direction、Security Impact 和 Operational Impact。
- 创建或变更 roadmap/spec/tasks 后运行
node create-claude-team/cli.js planning validate；失败时修复具体 artifact 引用，不以跳过校验或写入备用状态文件绕过。
create-claude-team status 与 Workbench 只投影该读取链；legacy docs 仅在 vNext artifact 缺失时回退读取。
Controlled Delivery Contract
存在 .claude/workspace/planning/delivery-contract.md 时，M/L/XL 开工前必须运行：
node create-claude-team/cli.js delivery preflight <module> --task <task-id>
- 只有
pass 才能将 task 写为 in_progress；使用 delivery transition <module> <task-id> in_progress 确认迁移合法。
needs_revision 时先修复命令列出的 spec/tasks/安全缺口；blocked 时先完成依赖或解除上游阻塞。两种结果都不得开始实现。- 该 CLI 只读 planning artifacts；roadmap 和 tasks 的写入责任不变，events/review/release/status/Workbench 不得作为替代依据。
- S 级热修可跳过；安全敏感变更必须有
Security Risk Level：high 和 Threat Model，但完整上线安全与运行保障仍由 N7//ship 负责。
Change Impact Contract
存在 .claude/workspace/planning/change-impact-contract.md 时，来自体验反馈、已有功能调整、跨模块行为变化或架构/安全/运行影响的开发请求，必须先运行 change analyze <module> --kind <kind>，并创建和验证 Change Impact Brief：
node create-claude-team/cli.js change validate .claude/workspace/changes/<brief>.md
node create-claude-team/cli.js delivery preflight <module> --task <task-id> --change .claude/workspace/changes/<brief>.md
- AI 先说明主归属、影响范围、同步项和验证方式；Brief 的引用与同步项必须通过 validate，才可修改代码或规划 artifact。
- S 级局部修复可跳过；不要为普通新功能虚构 Brief。架构、安全、兼容、迁移和产品范围变化仍按 ADR/Owner Decision Brief/N7 升级。
- 实现后更新 Brief 的同步项和验证证据；
/review-all 检查它与实际 diff 是否一致。
Owner Decision Brief 契约
/dev 默认由团队推进实现，不把每个技术细节都交给 Owner。L/XL 级任务必须检查是否需要 Owner Decision Brief；S/M 级只有命中高影响触发条件时才使用。
必须触发 Owner Decision Brief 的情况：
- 产品方向、MVP 范围或验收标准会被当前实现改变。
- 成本、隐私、安全、合规、发布风险会影响方案选择或上线判断。
- 架构选择会造成长期约束、迁移成本或明显锁定。
- 任务计划看起来能做完，但做完后可能不是 Owner 想要的结果。
不要为普通实现细节、局部代码风格、低风险库内重构打断 Owner。Product Lead 和 Architect-Planner 应先给推荐方案，再让 Owner 决策。
固定输出格式：
## Owner Decision Brief
- Decision: [what needs a choice]
- Context: [why this matters now]
- Recommendation: [default option and reason]
- Options:
- A: [option] - [trade-off]
- B: [option] - [trade-off]
- C: [optional] - [trade-off]
- If no reply: [safe default or pause]
Owner Decision Gate
存在 .claude/workspace/planning/owner-decision-contract.md 时，AI 先判断当前 feature 是否在产品范围、长期架构、安全隐私、不可逆操作或正式发布风险上需要 Owner 选择：
- 需要时，在 spec 写
Owner Decision Required：yes 和对应 Owner Decision Types，先给推荐与 Brief；Owner 明确回复前，Status 必须保持 draft 或 awaiting_owner。
- AI 可以创建 Brief 草稿，但不得把自己的推荐、工具权限、自动批准模式或“继续执行”写成
confirmed。只有 Owner 明确确认选项后才可填写 Owner Confirmation。
- 开工前必须运行：
node create-claude-team/cli.js decision validate <brief>
node create-claude-team/cli.js delivery preflight <module> --task <task-id> --decision <brief>
node create-claude-team/cli.js delivery transition <module> <task-id> in_progress --decision <brief>
- 缺 Brief、未确认、被拒绝、已替代、模块不匹配或类型不匹配时必须停止；
Owner Decision Required：no 的普通低风险任务不需要 Brief。
- 工具权限与 Owner 确认是两件事：本 gate 不读取权限，也不能被完全访问权限绕过。
Spec/Task Quality Gate
M/L/XL 开工前必须先过 Spec/Task Quality Gate。这个 gate 不是让 Owner 审技术细节，而是防止 Builder 认真执行一份没价值、看不懂或已经偏离 Owner 意图的 tasks。
开工前必须先用人话说明：
这轮我建议先做 [功能/模块]。它有用是因为 [产品价值/风险/roadmap 原因]。本轮只做到 [范围]，暂时不碰 [明确不做]。做完后，你应该能看到 [可感知结果]；我会用 [验收方式] 验证。当前不需要你拍板 / 需要你在 [决策点] 上拍板。
Gate 分工：
- Product Lead 判断 product value、Owner fit、MVP/roadmap 对齐。
- Architect-Planner 判断技术方案、依赖顺序、任务粒度和验收命令。
- Delivery Steward 判断 spec/tasks 是否可读、状态化、无重复、不制造文档漂移。
Gate 结果只能是：pass / needs_revision / blocked。
pass：Builder 可以开工。needs_revision：回到 Product Lead + Architect-Planner 修订，Builder 不得开工。blocked：说明阻塞原因和下一步确认人，Builder 不得开工。
S 级热修跳过该 gate；M 级使用轻量版本，但仍要让 Owner 能看懂做什么、为什么、怎么验收。
tasks.md 执行状态源
M/L/XL 级任务必须维护 tasks.md，它是执行计划和 gate 状态源。每个任务条目至少包含：
- 任务 ID：如
T1.3、M3.2；M 级可使用 M-1、M-2 这类轻量编号。
- 状态：见下方状态机。
- 描述：该任务要完成什么。
- 验收标准：用户可判断完成的结果。
- 验收命令：如
npm run validate、npm test、/check、/review-all、/ship --dry-run。
- 阻塞原因：无阻塞时写
无；阻塞时写清谁需要确认什么。
- Gate 结果：记录 local/review/release gate 的最新结果。
- 产物：关键文件、报告或模块路径。
- 最近更新：YYYY-MM-DD。
tasks.md 状态机
状态只能使用：
ready：信息足够，可以进入计划。needs_clarification：需求或约束不足，等待用户补充。planned：已拆解并排期，尚未开工。in_progress：正在实现。local_gate：实现完成，等待或正在执行本地验证与 /check。review_gate：本地验证通过，等待或正在执行 /review-all。release_gate：审查通过，等待或正在执行 /ship。blocked：被需求、依赖、测试、审查或发布问题阻塞。shipped：已发布或发布检查确认上线。done：无需发布的任务已完成并提交。
推荐流转：
ready → planned → in_progress → local_gate → review_gate → release_gate → shipped
↘ done（无需发布）
任意状态 → needs_clarification / blocked
blocked → planned / in_progress（阻塞解除后）
/dev 对 tasks.md 的更新责任
- 创建或更新任务计划时，将可执行任务标为
planned；信息不足标为 needs_clarification。
- 开始实现任务时，将状态改为
in_progress。
- 实现完成并准备本地验证时，将状态改为
local_gate，写入验收命令。
- 本地验证和
/check 通过后，将 local gate 结果记为 pass；需要审查的任务进入 review_gate，无需审查/发布的 S/M 小任务可进入 done。
- 任一检查失败且 2 轮自动修复仍失败时，将状态改为
blocked，写清阻塞原因和下一步确认人。
- 每次状态变化都刷新最近更新日期。
/dev 写入边界
/dev 只负责当前迭代的最小事实写入，避免同时承担所有状态、metrics、git 和 report 维护：
- 只更新当前 task/module 的执行状态、Gate 结果、阻塞原因、产物和最近更新日期。
- 只在收尾时追加 1 条最终
events.jsonl 事件，不回写旧事件，不生成额外派生状态。
- 不得默认执行
git commit；只有用户明确要求提交、或当前项目的显式 ship/commit 流程要求提交时，才执行 git stage/commit。
- metrics 由 events 聚合工具或
/standup 从 events.jsonl 生成，/dev 不再手写 .claude/workspace/metrics.md 摘要。
- review report、release report、cleanup report 分别由
/review-all、/ship 和 Delivery Steward 负责，/dev 只引用这些产物路径。
产品验收视角
产品功能完成时，/dev 必须说明用户主流程是否真的可用，而不只说明代码是否通过测试：
- L/XL 任务的 spec/tasks 必须包含 acceptance 场景，写清目标用户、入口、主流程、成功结果和可观察证据。
- M 级用户可见功能至少在 Summary 中说明用户能看到或完成什么；纯内部任务可说明“不涉及用户主流程”。
- Reviewer 检查 acceptance 风险，尤其是“代码做了但用户流程不连贯、不可验证或不好用”的问题。
- UI 任务由 Designer 检查体验、视觉和交互；Reviewer 只审代码质量、无障碍和 acceptance 风险，不重复审视觉。
流程
Phase 0: 需求确认（所有级别）
在写任何代码之前，AI 必须先理解你要什么。
AI 问你 3 个问题（可以一次性回答，也可以分开答）：
- 这个功能解决什么问题？ — 理解业务目的，不只是技术实现
- 有没有技术限制？ — 第三方服务、现有接口、性能要求、兼容性
- 做到什么程度算完成？ — 验收标准，越具体越好
确认方式：
- AI 输出一句话摘要："你要做的是：[摘要]，验收标准是：[标准]，技术约束是：[约束]"
- 你说"确认" → 进入 Phase 1
- 你说"不对" → AI 重新理解，最多 3 轮
- 3 轮还不清楚 → AI 说"我需要更多信息才能开始"，暂停等你补充
S 级例外：1-10 行的修复（typo、配置值、样式微调），跳过提问，直接做。
Phase 1: 复杂度判断 + 规划
判断标准：
| 级别 | 定义 | 规划动作 |
|---|
| S | 1-10 行修复，单文件 | 不规划，直接跳 Phase 2 |
| M | 单模块，1-2 文件 | 创建或更新轻量 tasks.md checklist（1-3 个任务），你确认后开始 |
| L | 跨模块，3-10 文件 | 输出 spec.md + tasks.md，你确认后开始 |
| XL | 新系统，10+ 文件 | 先 Spike 调研可行性 → 输出 spec.md + tasks.md + architecture.md，你确认后开始 |
Spike 退出标准（仅 XL 级）：
- 技术方案可行 → 输出调研结论，进入规划
- 存在重大障碍（第三方 API 不支持、性能无法达标等） → 告诉你"这个做不了，原因是 X，建议替代方案 Y"
- 信息不足 → 列出需要你确认的点，等你回复
用户不确认时：
- 如果你说"方案不对" → AI 根据你的反馈调整，重新输出方案
- 如果你说"先不做" → 流程结束，不消耗资源
- 最多调整 3 轮，3 轮后仍不确认 → AI 说"我们对需求的理解还有分歧，建议先讨论清楚"
Phase 2: 迭代开发
S 级流程（最简单）
1. Builder 直接修复
2. /check 快检（逻辑 + 类型 + 边界）
3. 有问题 → 自动修 → 重新检查
4. 没问题 → 追加最终 event → 完成
M 级流程
1. 生成或更新轻量 tasks.md checklist
→ 每项包含任务 ID、状态、描述、验收标准、验收命令、Gate 结果、阻塞原因、最近更新
2. 你确认 checklist
3. Builder 按 tasks.md 实现（TDD）
→ 开始时把任务状态更新为 in_progress
4. /check 快检
→ 开始本地验证时把任务状态更新为 local_gate
5. 有问题 → 自动修 → 重新检查（最多 2 轮）
6. 2 轮后仍有问题 → 标记 blocked，记录阻塞原因，等你决定
7. 全部通过 → 记录 local gate pass，状态更新为 done，追加最终 event → 完成
L/XL 级流程（完整迭代）
for 每个任务 in tasks.md:
1. Builder 实现（TDD：先写测试 → 写代码 → 重构）
→ 先执行 `delivery preflight` 和 `delivery transition ... in_progress`，再把任务状态更新为 in_progress
2. /check 快检（每个任务完成后立即执行）
→ 开始本地验证时把任务状态更新为 local_gate
→ 有问题：自动修 → 重新检查（最多 2 轮）
→ 2 轮不过：标记 blocked，记录阻塞原因，等你决定
→ 没问题：记录 local gate pass，进入 review_gate 或继续
3. 如用户明确要求提交，或当前项目显式 commit/ship 流程要求提交，再执行 git stage/commit
所有任务完成后:
4. /review-all 跨文件审查（单文件质量由 code-review skill 逐文件覆盖）
→ 通过：进入 Phase 3
→ 不通过：按 review report 委托 `/fix` 或 `/dev` 修复后重新审查
→ 仍不过或阻塞：列出所有问题和下一步确认项等你决定
Phase 3: 验收
1. 运行所有测试 → 全部通过？
2. 类型检查 tsc --noEmit → 无错误？
3. Lint 检查 → 无错误？
4. Git 状态检查 → 清楚列出本轮改动和已有无关改动？
5. 产品验收检查 → 用户主流程或“不涉及用户主流程”的说明是否成立？
全部通过 → 输出"开发完成"
有失败 → 自动修 → 重新验收（最多 2 轮）
2 轮后仍有失败 → 列出失败项等你决定
Phase 4: 记录事件与指标字段（自动）
1. 收集本次任务的结构化指标字段：
- spec 否决轮数（Phase 1 中用户否决了几次方案）
- /check 首次问题数（第一次快检发现多少问题）
- /check 修复轮数（快检修了几轮才通过）
- 测试失败次数（Phase 3 中测试不通过的次数）
- /review-all 打回次数（审查不通过的次数）
- 预估偏差（实际耗时 vs 预估）
2. 只把这些字段写入最终 `events.jsonl` 事件。
3. metrics 由 events 聚合工具或 `/standup` 从 `events.jsonl` 生成；`metrics.md` 是人类可读摘要，不由 `/dev` 手写维护。
4. 如果指标触发警告值，自动提醒：
- spec 否决 3 轮 → "需求理解有偏差，建议改进 Phase 0"
- /check 首次问题 5+ → "代码质量不够，建议加强 TDD"
- /review-all 打回 1+ 次 → "自检不足，建议每个任务后强制 /check"
5. 输出执行摘要：
✅ 开发完成
📊 指标：spec 0 轮 | check 2 个问题，1 轮修复 | 审查通过 | 测试通过
⏱️ 耗时：预估 4h / 实际 3.5h（-12%）
## Summary
- status: completed
- affected files/modules: [本次新增、修改或重点影响的文件/模块]
- checks: test pass / typecheck pass / lint pass / review pass
- next action: [下一步任务、阻塞决策或发布建议]
Phase 4.5: 输出标准结果摘要（自动）
/dev 完成后必须输出固定的 Summary 块，供用户阅读，并作为 events.jsonl 的字段来源。
## Summary
- status: completed / failed / blocked / skipped
- affected files/modules: [本次新增、修改或重点影响的文件/模块]
- checks: [测试、类型检查、lint、/check、/review-all 的最终结果]
- next action: [下一步任务、阻塞决策或发布建议]
映射规则：
events.jsonl.summary 使用 status + 一句话结果，例如 completed: 完成 T0.2 标准结果摘要契约。events.jsonl.artifacts 使用 affected files/modules 中的文件路径；模块名只保留在 summary。events.jsonl.checks 使用 checks 的结构化结果。events.jsonl.next 使用 next action。
Next Best Action 契约
/dev 完成或阻塞时必须输出固定的 Next Best Action，告诉用户下一步应该做什么、为什么、是否需要人工确认。
## Next Best Action
- action: [建议执行的命令或人工动作，如 /check、/review-all、/ship、继续 T3.2、等待用户确认]
- reason: [为什么现在应该做这一步，引用任务状态、gate 结果、风险或 metrics]
- requires human confirmation: yes / no
- source: [依据来源，如 tasks.md、roadmap.md、events.jsonl、review report、release report、git diff]
写入规则：
Summary.next action 必须与 Next Best Action.action 保持一致或可直接追溯。- 如果
requires human confirmation: yes，必须说明谁需要确认什么。
- 如果任务
blocked，Next Best Action 必须指向解除阻塞所需的最小动作。
Phase 5: 追加事件（自动）
开发流程结束时，必须向 .claude/workspace/events.jsonl 追加 1 行 JSONL 事件，作为 /standup 和后续 metrics 的机器可读事实来源。
events.jsonl 契约
每行是一个独立 JSON 对象，不允许跨行，不回写旧事件。
| 字段 | 必填 | 说明 |
|---|
time | 是 | UTC ISO 8601 时间，如 2026-07-09T10:00:00Z |
command | 是 | 固定为 /dev |
task | 否 | 任务或模块 ID，如 T0.1、M1；没有则为 null |
status | 是 | completed / failed / blocked / skipped |
summary | 是 | 一句话结果摘要，供人类和 /standup 直接引用 |
checks | 否 | 本次执行的检查结果对象，如 {"test":"pass","review":"pass"} |
artifacts | 否 | 本次创建或更新的关键文件路径数组 |
next | 否 | 下一步建议、下一个任务 ID，或 null |
Metrics 扩展字段
events.jsonl 同时是结构化 metrics 的机器事实来源。/dev 收尾事件应尽量写入这些可选字段；未知时用 null，计数无发生时用 0：
| 字段 | 说明 |
|---|
taskId | 标准任务或模块 ID；优先等于 task，如 T2.1、M3 |
level | 任务级别：S / M / L / XL |
specRejectCount | Phase 1 中用户否决方案或 spec 的次数 |
checkIssueCount | 首次 /check 或本地快检发现的问题数 |
checkFixRounds | /check 或本地快检自动修复轮数 |
reviewRejectCount | /review-all 打回次数 |
testFailureCount | 测试失败次数 |
estimateHours | 预估工时；没有估算则为 null |
actualHours | 实际耗时；没有记录则为 null |
失败恢复记录契约
当 /dev 遇到测试失败、CI 失败、pack 失败、hook 误拦或发布失败，并且本次流程进行了自动修复、重试、回滚或最终阻塞时，收尾事件必须写入可选对象 failureRecovery。无失败发生时省略该对象。
failureRecovery 固定字段：
| 字段 | 说明 |
|---|
failureType | test_failure / ci_failure / pack_failure / hook_false_positive / release_failure |
stage | 发生阶段，如 local_gate、review_gate、release_gate、hook、ci |
symptom | 用户可读的失败现象，避免粘贴长日志 |
rootCause | 已确认根因；未知时为 unknown |
recoveryAction | 已执行的恢复动作，如 fix、retry、rollback、mark_flaky、accept_risk |
attempts | 修复或重试次数 |
finalStatus | recovered / blocked / accepted_risk / needs_followup |
evidence | 相关命令、报告或日志路径数组，必须使用仓库相对路径 |
followUp | 后续任务、补测试、修 CI 或人工确认事项；没有则为 null |
写入规则：
- 只在命令收尾时追加 1 条最终事件，不记录中间步骤。
- 如果
.claude/workspace/ 或 events.jsonl 不存在，创建它们。
- 路径使用仓库相对路径，不记录绝对路径、密钥、token 或敏感数据。
- 写入失败时在最终输出中说明，但不因为事件写入失败而改变代码任务结论。
示例：
{"time":"2026-07-09T10:00:00Z","command":"/dev","task":"T0.2","taskId":"T0.2","level":"M","status":"completed","summary":"completed: 完成标准结果摘要契约","checks":{"validate":"pass","test":"pass","review":"pass"},"specRejectCount":0,"checkIssueCount":0,"checkFixRounds":0,"reviewRejectCount":0,"testFailureCount":0,"estimateHours":null,"actualHours":null,"artifacts":[".agents/commands/dev.md",".agents/commands/check.md"],"next":"T0.3"}
异常路径速查
| 场景 | 处理方式 |
|---|
| 测试一直失败 | 自动修 2 轮 → 仍失败 → 列出失败原因等你决定 |
| 类型检查不通过 | 自动修 → 重新检查 |
| 审查打回 | 按 review report 委托修复 → 重新审查 |
| 你否决了方案 | 根据反馈调整 → 重新输出方案（最多 3 轮） |
| 你否决了 3 次 | 暂停，建议先讨论清楚需求 |
| Spike 发现不可行 | 告诉你原因 + 替代方案 |
| 需求中途变了 | 停止当前迭代，重新评估影响范围，调整 tasks.md |
| 发现方向错了 | 停止，告诉你当前状态 + 建议的回退点，你决定是否回退 |
Git 操作规范
- 分支：
feature/[功能名] 或 fix/[问题描述]
- 提交频率：每完成一个逻辑单元就提交，不要攒到最后
- Commit message：遵循
.agents/rules/git.md 的格式
- 合并前：确保 /review-all 通过
粒度速查
| 你的情况 | 用什么 |
|---|
| 想做新功能 | /dev 做一个用户登录功能 |
| 写完一个文件想快检 | /check |
| 发现一个具体问题想修 | /fix src/auth/login.ts 里的密码验证逻辑不对 |
| 写完了想全面检查 | /review-all src/features/auth/ |
| 想修但不知道问题在哪 | /check 快检找问题，或 /review-all 全面审查 |
| 想看进度 | /standup |
使用示例
# 完整功能开发
/dev 做一个用户注册登录功能
# 小修复
/dev 修复登录页面输入空密码时没有提示的问题
# 中等功能
/dev 给用户列表加一个搜索框，支持按姓名和邮箱搜索
# 大功能
/dev 重构认证模块，支持 JWT + OAuth2 两种方式
# 需求不清楚时，AI 会先问你
/dev 做一个管理后台
# AI: "这个管理后台包含哪些页面？需要什么角色权限？"
