用途
任务启动（Task Start）用于在写代码之前先确保「做对的事」（需求对焦），再「把事做对」（方案设计）。当收到新功能、复杂任务或大型需求时触发，触发词包括：新功能、实现 xxx、大型任务、需求不明确。它在整个工作流中处于最前段，位置为：task-start → task-execute → task-finish。
第一步：决策树——这个任务需要走多深
收到需求后按决策树判断路径：
- 任务明确且改动 ≤2 个文件：直接动手，跳过本 skill，按 CLAUDE.md 基本流程执行。
- 任务有模糊点但规模不大（≤3 文件）：仅对焦，执行第二步后直接开发。
- 从头开发完整前后端系统／包含多个页面的项目：全流程强制，对焦 + UI 原型 + 方案 + task-execute + task-finish，每个环节不可跳过。
- 涉及 3+ 文件／新模块／技术选型／架构决策：对焦 + 方案，执行第二步 + 第三步（条件触发）+ 第四步。
- 不确定：先花 2 个工具调用了解任务范围，再回到决策树判断。
快速判断信号：用户说「改一下 xxx」「加个 xxx」大概率直接动手；说「实现 xxx 功能」「帮我做 xxx」大概率需要对焦；说「设计 xxx 系统」「重构 xxx」几乎肯定需要对焦 + 方案；说「做一个 xxx 系统」「从头搭建」强制全流程；描述中有「大概」「类似」「差不多」必须对焦。
第二步：需求对焦（Align Before Act）
对焦检查清单（进入 Plan 模式或写代码前确认）：
- 核心目标：这个需求解决什么问题？给谁用？
- 验收标准：做到什么程度算完成？
- 输入/输出：数据从哪来？产出是什么形式？
- 边界与异常：空值、并发、出错了怎么办？
- 不做什么：哪些看起来相关但这次不做？
- 依赖与约束：必须兼容的现有逻辑或技术约束？
历史经验检索（对焦前必做）：来源 1 为 docs/decisions/（项目级经验，git 管理），可用 grep -r "相关模块名/功能名" docs/decisions/ 搜索；来源 2 为 memory（跨项目经验），读取 MEMORY.md 索引，检查 feedback/project 类型记忆，引用前先验证是否过期。找到相关经验时主动提醒用户并标注来源；没有则继续正常对焦。
如何对焦：不要一次问 6 个问题，挑最不确定的 2-3 个用 AskUserQuestion 确认；给出自己的理解而非空泛提问；信息够了就停，80% 确定即可开始。对焦结论输出格式为「## 需求对焦结论」，包含目标、验收标准、不做、待定。对焦完成、确认启动开发后，更新 docs/backlog/ 中对应需求文件 frontmatter 为 status: in-progress，并将 docs/backlog/INDEX.md 中该需求的 [ ] 改为 [~]；无对应 backlog 文件则跳过。
第三步：UI 原型确认（涉及前端页面时）
强制触发：从头开发包含前端的完整系统；搭建新项目且包含多个页面。条件触发：新建页面或视图；对现有页面做布局/结构性改动；涉及新的交互流程；用户明确提到 UI 期望。不触发：纯后端、纯逻辑、样式微调、已有明确设计稿的任务。
执行流程：生成 HTML 可预览原型 → 用 preview 工具启动本地预览 → 用户确认或提修改意见 → 迭代调整 → 写入技术方案「UI 设计」部分。
HTML 原型规范：单个 HTML 文件，内联 CSS，不依赖外部资源；存放位置 docs/prototypes/<模块名>-prototype.html，确认后可删除；使用真实的或接近真实的示例数据；标注可交互元素行为说明；多个页面/状态用不同 section 或页面切换展示；简洁的灰白配色即可。
与用户对齐要点：信息结构、布局方式、交互流程、状态覆盖。原型确认结论格式为「## UI 确认结论」，包含页面结构、关键交互、用户反馈、原型文件路径。
第四步：方案设计（Plan → Review → Do）
方案产出流程：需要选型时调用 tech-evaluation skill；需要调研时调用 deep-research skill。信息就绪后写技术方案（spec），调用 writing skill（技术文档模式 → spec 模板），输入对焦结论 + 选型结论 + UI 确认结论，产出 docs/specs/YYYY-MM-DD-<模块名>-<主题>.md；再写开发计划（plan），调用 writing skill（技术文档模式 → plan 模板），输入 spec 文档，产出 docs/plans/YYYY-MM-DD-<模块名>-plan.md。
方案必备章节：背景与动机、现状分析、调研与备选方案、决策与取舍、技术方案、风险与边界。
Review 检查点：目标清晰、验收标准可衡量；改动范围合理、无 scope creep；技术选型有依据；实施步骤可执行有先后顺序；风险已识别有应对方案；没有过度设计。
方案变更管理：小调整（实现细节微调）直接调整，下次沟通同步；中调整（步骤顺序变化、增删改动文件）暂停开发，更新方案后继续；大调整（方向性变化、核心设计推翻）停止开发，重新 Review。
与其他 skill 的衔接
task-start（本 skill）→ task-execute（持续编码 + 跨会话进度管理）→ task-finish（CR 自检）→ task-manager 标 done（复盘 + 经验沉淀 → docs/decisions/）。对焦前检索 docs/decisions/ 历史经验；对焦结论输入方案背景部分；UI 原型可调 rapid-prototype skill 或存入 docs/prototypes/；涉及选型调 tech-evaluation skill；需要调研调 deep-research skill；写方案/计划调 writing skill；判定为重构任务引导走 refactoring skill。跨多个会话的大型任务同时使用 task-execute skill 追踪进度。
全系统项目强制规则
从头开发完整前后端系统时，以下环节全部强制执行不可跳过：需求对焦（task-start 第二步，检查清单全部过一遍并输出结论）、UI 原型确认（task-start 第三步，生成 HTML 原型 → preview 预览 → 用户确认）、方案设计（task-start 第四步，完整方案文档存入 docs/specs/）、持续执行（task-execute，启用进度追踪框架管理跨会话上下文）、CR 自检（task-finish，深度自检模式逐项检查）、复盘沉淀（task-finish，四维回顾 + 经验存入 memory）。