메뉴
提交前质量门禁：CR 自检（快速/深度）。在 commit 之前触发。 只负责代码质量自检，不负责复盘——复盘在需求标 done 时由 task-manager 触发。 触发词：提交代码、自检、准备提交。 工作流位置：task-start → task-execute → task-finish（自检）→ task-manager（需求关闭时复盘）
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
通用写作技能：以"内容→组件→组合"的方式产出技术文档、产品文档、汇报材料。 覆盖 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/ 目录的整理/检查/更新，都应触发此技能。
需求全生命周期管理：收集、排序、清理、跟踪、关闭。 管理 docs/backlog/ 目录下的需求文件和 INDEX.md 索引。 核心职责：需求状态变更是整个工作流的驱动力—— open（收集）→ 启动 task-start → 执行 → done（关闭时触发复盘 + 经验沉淀 + 文档更新）。 触发词：梳理需求、排优先级、backlog、需求管理、看看还有什么要做的、需求池、 这个需求做完了、标记完成、关闭需求。 触发场景：开新迭代前梳理需求、积累了一堆需求要排序、定期清理过期需求、需求完成关闭时。 本 skill 管"做不做、做哪个、做完了吗"，task-start 管"怎么做"，plan 管"做到哪了"。
| name | task-finish |
| version | 1.1.0 |
| last_updated | "2026-04-08T00:00:00.000Z" |
| repository | https://github.com/312362115/claude |
| changelog | skills/task-finish/CHANGELOG.md |
| description | 提交前质量门禁：CR 自检（快速/深度）。在 commit 之前触发。 只负责代码质量自检，不负责复盘——复盘在需求标 done 时由 task-manager 触发。 触发词：提交代码、自检、准备提交。 工作流位置：task-start → task-execute → task-finish（自检）→ task-manager（需求关闭时复盘） |
提交前自检发现问题的成本是上线后的 1/10。 本 skill 只负责代码质量门禁。复盘沉淀在需求关闭时由 task-manager 触发。
准备提交
│
├─ 单文件小改动（修 typo、调样式、改注释）？
│ └─ YES → 【跳过】直接提交
│
├─ 改动 ≤3 文件，不涉及公共接口？
│ └─ YES → 【快速自检】执行第二步的快速清单（5 项）
│
└─ 改动 >3 文件 / 涉及公共接口 / 核心业务逻辑？
└─ YES → 【深度自检】执行第二步的完整清单（15 项）
用"审查别人代码"的视角审查自己的代码。
git diff 审查自己的改动：逐文件看 diff，而不是凭记忆| # | 检查项 | 要点 |
|---|---|---|
| 1 | 改动解决了目标问题？ | 跑一遍核心路径确认 |
| 2 | 没有遗留 debug 代码？ | console.log、print、TODO hack |
| 3 | 命名清晰、无硬编码敏感信息？ | 密钥、token、密码 |
| 4 | 没有混入不相关变更？ | 改动范围最小化 |
| 5 | 代码能正常运行？ | 改后验证，不是"我觉得对" |
正确性检查：
设计检查：
安全检查：
可维护性检查：
task-start — 启动：对焦需求 + 设计方案
│
↓
task-execute — 执行：持续编码 + 跨会话进度管理
│
↓
task-finish（本 skill）— 提交前自检
│
├─ 自检通过 → 提交代码
├─ 文档同步提醒（按改动内容判断，可能同时命中多条）：
│ ├─ 涉及新模块 / 模块间交互变更？→ 提醒更新 architecture/ 或 user-guide/（docs-management.Synthesize）
│ ├─ 涉及依赖/工具链/环境配置变更？→ 提醒更新 guides/
│ └─ 涉及部署流程/基础设施变更？→ 提醒更新 runbooks/
├─ 涉及上线服务？→ 提示跑 security-audit（安全审查）
├─ 准备发版？→ 引导到 release skill
│
↓ 提交完成后
├─ 主动询问用户："这个需求是否彻底完成？如果是，可以标记 done 触发复盘和经验沉淀。"
│
↓ （用户确认完成）
task-manager 标 done — 触发复盘 + 经验沉淀 + docs-management.Ingest
复盘不在 task-finish 中触发。 因为"编码完成"不等于"需求完成"——后续可能还有手动测试、bug 修复、调整。 复盘在需求被用户明确标记为 done 时，由 task-manager 触发，确保覆盖完整的交付过程。 但 task-finish 有责任提醒：提交代码后主动询问用户是否需要关闭需求，避免复盘被遗忘。