メニュー
任务启动流程：需求对焦 + UI 原型确认 + 方案设计。收到新功能、复杂任务、大型需求时触发。 包含决策树判断走哪条路径、对焦检查清单、UI 原型预览环节、方案模板和示例。 触发词：新功能、实现xxx、大型任务、需求不明确。 工作流位置：task-start → task-execute → task-finish
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | task-start |
| version | 1.1.0 |
| last_updated | "2026-03-28T00:00:00.000Z" |
| repository | https://github.com/312362115/claude |
| changelog | skills/task-start/CHANGELOG.md |
| description | 任务启动流程：需求对焦 + UI 原型确认 + 方案设计。收到新功能、复杂任务、大型需求时触发。 包含决策树判断走哪条路径、对焦检查清单、UI 原型预览环节、方案模板和示例。 触发词：新功能、实现xxx、大型任务、需求不明确。 工作流位置：task-start → task-execute → task-finish |
动手写代码之前，先确保"做对的事"（需求对焦）再"把事做对"（方案设计）。
收到用户需求后，按以下决策树判断：
收到需求
│
├─ 任务明确且改动 ≤2 个文件？
│ └─ YES → 【直接动手】跳过本 skill，按 CLAUDE.md 基本流程执行
│
├─ 任务有模糊点但规模不大（≤3 文件）？
│ └─ YES → 【仅对焦】执行第二步的需求对焦，然后直接开发
│
├─ 从头开发完整前后端系统 / 包含多个页面的项目？
│ └─ YES → 【全流程强制】对焦 + UI 原型 + 方案 + task-execute + task-finish，每个环节不可跳过
│
├─ 任务涉及 3+ 文件 / 新模块 / 技术选型 / 架构决策？
│ └─ YES → 【对焦 + 方案】执行第二步 + 第三步（条件触发）+ 第四步
│
└─ 不确定？
└─ 先花 2 个工具调用了解任务范围，再回到决策树判断
快速判断信号：
| 信号 | 路径 |
|---|---|
| 用户说"改一下xxx"、"加个xxx" | 大概率直接动手 |
| 用户说"实现xxx功能"、"帮我做xxx" | 大概率需要对焦 |
| 用户说"设计xxx系统"、"重构xxx" | 几乎肯定需要对焦 + 方案 |
| 用户说"做一个xxx系统"、"从头搭建" | 强制全流程：task-start(对焦+UI原型+方案) → task-execute → task-finish |
| 用户描述中有"大概"、"类似"、"差不多" | 必须对焦 |
写代码之前先对清需求。主动问出来比猜错了返工成本低 100 倍。
在进入 Plan 模式或动手写代码之前，确认以下问题有答案：
| # | 问题 | 目的 |
|---|---|---|
| 1 | 核心目标：这个需求解决什么问题？给谁用？ | 避免做出"技术上正确但用户不要"的东西 |
| 2 | 验收标准：做到什么程度算"完成"？ | 防止过度实现或遗漏关键场景 |
| 3 | 输入/输出：数据从哪来？产出是什么形式？ | 明确接口边界 |
| 4 | 边界与异常：空值、并发、出错了怎么办？ | 提前识别隐藏复杂度 |
| 5 | 不做什么：哪些看起来相关但这次不做？ | 划清 scope，防止膨胀 |
| 6 | 依赖与约束：必须兼容的现有逻辑或技术约束？ | 避免做完发现不兼容 |
在开始对焦之前，从两个来源检索历史经验：
来源 1：docs/decisions/（项目级经验，git 管理）
# 搜索相关关键词
grep -r "相关模块名/功能名" docs/decisions/
来源 2：memory（跨项目经验，跨会话索引）
如果找到相关经验：
如果没有找到：继续正常对焦。
AskUserQuestion 确认差的对焦（空泛、被动）：
用户：帮我加一个用户导出功能
Agent：请问你想导出什么？格式是什么？有什么要求？
→ 问题太散，用户不知道从哪答起
好的对焦（具体、主动给判断）：
用户：帮我加一个用户导出功能
Agent：我理解你要的是：
1. 在用户管理页面加一个"导出"按钮
2. 导出当前筛选条件下的用户列表，CSV 格式
3. 包含基本字段：姓名、邮箱、注册时间、状态
有两个点想确认：
- 导出数据量大吗？超过 1 万条的话需要考虑异步导出 + 下载通知
- 手机号等敏感字段需要脱敏吗？
→ 先给出自己的理解，再针对性问关键点
对焦完成后，把结论整理为一段话，格式：
## 需求对焦结论
- 目标：[一句话]
- 验收标准：[具体条件]
- 不做：[明确排除的内容]
- 待定：[开发中再确认的点]
这段结论直接输入到方案的"背景与目标"部分，或作为 Plan 模式的输入。
对焦完成、确认启动开发后，立即更新关联 backlog 的状态：
docs/backlog/ 中对应的需求文件，更新 frontmatter：status: in-progressdocs/backlog/INDEX.md：将该需求的 [ ] 改为 [~]如果当前需求没有对应的 backlog 文件（比如临时小需求），跳过此步。
涉及 UI 的任务，写代码前先出可预览原型。改原型比改实现代码成本低 100 倍。
强制触发（不可跳过）：
条件触发（涉及以下场景时执行）：
不触发：纯后端、纯逻辑、样式微调（改颜色/间距）、已有明确设计稿的任务。
需求对焦结论
│
├─ 涉及 UI？ → NO → 跳到第四步（方案设计）
│
└─ YES ↓
1. 生成 HTML 可预览原型（静态页面，重点是布局和信息结构）
2. 用 preview 工具启动本地预览，让用户在浏览器中查看
3. 用户确认或提出修改意见
4. 迭代调整，直到用户确认 UI 方向正确
5. 将确认后的 UI 方案写入技术方案文档的「UI 设计」部分
docs/prototypes/<模块名>-prototype.html，确认后可删除确认原型时，主动引导用户关注：
## UI 确认结论
- 页面结构：[确认的布局方案]
- 关键交互：[确认的交互行为]
- 用户反馈：[用户提出的调整及处理]
- 原型文件：[文件路径，供开发参考]
大型 feature 和复杂任务，写代码之前先写方案。改文档比改代码成本低 10 倍。 方案的具体写作由 writing skill（技术文档模式）负责，本步骤只负责流程调度。
对焦结论就绪
│
├─ 需要选型？→ 调用 tech-evaluation skill，获得选型结论
├─ 需要调研？→ 调用 deep-research skill，获得调研结论
│
↓ 信息就绪
│
├─ 写技术方案（spec）
│ → 调用 writing skill（技术文档模式 → spec 模板）
│ → 输入：对焦结论 + 选型结论（如有）+ UI 确认结论（如有）
│ → 产出：docs/specs/YYYY-MM-DD-<模块名>-<主题>.md
│ → 模板详见 writing skill 的 references/templates/spec.md
│
└─ 写开发计划（plan）
→ 调用 writing skill（技术文档模式 → plan 模板）
→ 输入：spec 文档
→ 产出：docs/plans/YYYY-MM-DD-<模块名>-plan.md
→ 模板详见 writing skill 的 references/templates/plan.md
方案必须完整交代背景→调研→验证→决策全链路（详见 CLAUDE.md 方案设计规范）：
| 必备章节 | 必须回答的问题 |
|---|---|
| 背景与动机 | 为什么要做？解决什么问题？ |
| 现状分析 | 当前怎么做的？痛点在哪？ |
| 调研与备选方案 | 调研了哪些方案？各自验证结果？ |
| 决策与取舍 | 选了哪个？为什么？放弃了什么？ |
| 技术方案 | 具体怎么实现？ |
| 风险与边界 | 已知风险？不做什么？ |
方案 Review 时重点关注：
开发过程中如果发现方案需要调整：
task-start（本 skill）— 启动：对焦需求 + [UI 原型确认] + 设计方案
│
├─ 对焦前 → 检索 docs/decisions/ 历史经验（避免重复踩坑）
├─ 对焦结论 → 输入到方案的背景部分
├─ UI 原型 → 调 rapid-prototype skill 或存入 docs/prototypes/
├─ 涉及选型 → 调 tech-evaluation skill
├─ 需要调研 → 调 deep-research skill
├─ 写方案 → 调 writing skill（技术文档模式 → spec 模板）
├─ 写计划 → 调 writing skill（技术文档模式 → plan 模板）
├─ 判定为重构任务 → 引导走 refactoring skill
│
↓
task-execute — 执行：持续编码 + 跨会话进度管理
│
↓
task-finish — 收尾：CR 自检
↓ （需求彻底完成后）
task-manager 标 done — 复盘 + 经验沉淀 → docs/decisions/
如果是跨多个会话的大型任务，同时使用 task-execute skill 追踪跨会话进度。
从头开发完整前后端系统时，以下环节全部强制执行，不可跳过任何一个：
| 环节 | skill | 必须完成的动作 |
|---|---|---|
| 需求对焦 | task-start 第二步 | 对焦检查清单全部过一遍，输出对焦结论 |
| UI 原型确认 | task-start 第三步 | 生成 HTML 原型 → preview 预览 → 用户确认 |
| 方案设计 | task-start 第四步 | 完整方案文档，存入 docs/specs/ |
| 持续执行 | task-execute | 启用进度追踪框架，管理跨会话上下文 |
| CR 自检 | task-finish | 深度自检模式，逐项检查 |
| 复盘沉淀 | task-finish | 四维回顾 + 经验存入 memory |
通用写作技能：以"内容→组件→组合"的方式产出技术文档、产品文档、汇报材料。 覆盖 spec / plan / PRD / 用户手册 / 项目汇报 / 方案路演 / 调研报告 等所有结构化文档场景。 核心理念：组件驱动，不预设模板。先看内容形态，再挑能装这种形态的组件， 组合自然成文——不强制章节结构、不预设"必备模块"。 组件库（HTML / Markdown / 图示）见 references/components.md， 常见组合范式（spec / plan / PRD 等）见 references/templates/——但模板是参考不是规定。 触发词：写文档、写方案、写计划、写 PRD、写汇报、项目总结、写指南、帮我写、文档、方案设计。 即使用户没有明确说"写"，只要意图是"产出一份结构化的文档/报告/材料"，都应触发此技能。 本 skill 只负责"写"，不负责"调研"（调研由 deep-research 承担）和"调度"（流程由 task-start 承担）。
深度调研技能：对任意命题进行系统性调研并输出专业研究报告。 覆盖技术选型、行业分析、学术研究、竞品分析、概念探索等所有调研场景。 核心方法论：快速扫描→假设驱动研究、内外数据结合（先摸清内部现状再对标外部水位）、 反面证据强制搜索、数据来源三级分类、结论置信度分级、多层次报告输出。 采用 Orchestrator-Subagent 架构（Lead+Sub-agent 并行深挖、压缩回传、Scaling Rules 预算控制）， 对齐 Anthropic 官方 Research 工程实践。 包含信息交叉验证、专业图表生成（Diagram Bridge 统一图表体系）、 数据来源分级标注、分析框架自动选择、报告组件驱动（不预设模板，按内容形态调用组件）、质量自检（6 步工作流）。 触发词：调研、研究、分析报告、对比分析、行业报告、技术选型、竞品分析、 市场调研、深度研究、出一份报告、帮我调研一下、了解一下xxx、 评估、诊断、健康度、差距分析。 即使用户没有明确说"调研"，只要意图是"系统性地了解某个命题并形成结论"，都应触发此技能。
MD 文件浏览器预览：GitHub 风格渲染 + 左侧自动目录。 在完成方案设计（specs）或开发计划（plans）的 MD 文件后触发。 询问用户是否要在浏览器中打开预览，确认后执行。 触发词：方案写完、计划写完、review MD、预览文档。 工作流位置：task-start 方案产出后 / 任意 MD 文档完成后
专业图表生成技能：根据需求自动选择合适的图表类型，生成符合设计规范的 PNG 图表。 覆盖 29 种图表：结构图（流程图、泳道图、时序图、架构图、状态图、ER图、类图、思维导图、甘特图、Kanban、Git Graph 等） 和统计图（柱状图、折线图、饼图、雷达图、热力图、散点图、桑基图、漏斗图、瀑布图、矩形树图、柱线混合图等）。 统一工具：HTML/SVG + 内联 JS 布局计算。ER/类图使用 ELKjs 布局引擎。 所有图表遵循统一的设计规范（配色/字体/组件/间距），风格现代简洁。 支持三种输出：PNG（默认）、HTML（富文档嵌入）、DSL（Mermaid 文本，嵌入 MD 文档）。 触发词：画图、画一个、生成图表、流程图、架构图、时序图、柱状图、对比图、关系图。 即使用户没有说"画图"，只要需求中涉及可视化展示（流程、架构、数据对比、关系），都应触发此技能。 被 deep-research 等其他技能调用时，同样遵循本规范生成图表。
项目知识库引擎：持续维护 docs/ 目录作为活的知识库。 灵感来源：Karpathy LLM Wiki — LLM 不只是写文档，而是持续维护知识库。 五个核心操作：Ingest（摄入新信息）、Query（检索知识）、Lint（健康检查）、Index（索引维护）、Synthesize（聚合全局视图）。 触发词：文档检查、清理文档、文档索引、docs 整理、知识库、文档过期了吗、架构文档、用户手册。 触发场景：task-manager 标 done 时自动触发 Ingest、定期 Lint 健检、用户查询项目历史、 task-finish 提醒后触发 Synthesize 更新 architecture/ 或 user-guide/。 即使用户没有说"文档管理"，只要涉及 docs/ 目录的整理/检查/更新，都应触发此技能。
提交前质量门禁：CR 自检（快速/深度）。在 commit 之前触发。 只负责代码质量自检，不负责复盘——复盘在需求标 done 时由 task-manager 触发。 触发词：提交代码、自检、准备提交。 工作流位置：task-start → task-execute → task-finish（自检）→ task-manager（需求关闭时复盘）