# Project Handoff > 基于真实项目生成或修订可交给另一模型或开发者执行的交接文档，明确实施方案、任务步骤、修改范围与验收要求。用于“生成执行交接方案”“把排查结果交给其他模型实施”等请求；不用于直接实施业务代码或仅整理聊天摘要。 - Skill: `tranhaianh20571-droid/project-handoff` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add tranhaianh20571-droid/project-handoff` - Raw SKILL.md: https://api.skillmd.com/api/skills/tranhaianh20571-droid/project-handoff/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tranhaianh20571-droid (https://skillmd.com/u/tranhaianh20571-droid) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tranhaianh20571-droid/project-handoff --- # 项目执行交接 生成基于项目证据、可独立接手、可执行和可验收的交接文档。只有“生成执行交接文档”一个入口：接受新目标或已有文档，审查是交付前的必经步骤，不单设模式。 ## 工作边界 - 默认只调查项目和编写文档，不顺带修改业务代码、安装工具、修改运行配置或操作真实业务数据。用户另有明确指令时按授权范围执行。 - 沿用项目文档布局、备份规则和现有成果；已有文档优先修订，不新增相互矛盾的事实来源。 - 交接文档应能脱离历史聊天使用。记录必要背景与已确认约束，不复制对话流水账。 - 根据任务复杂度控制篇幅。小任务简写，复杂任务再补接口、状态、恢复等细节；不强制每个项目采用相同技术方案。 ## 生成流程 ### 1. 调查项目基线 读取适用项目规则、已有需求/方案、工作区变更和与任务相关的源码、测试及构建入口。无需遍历无关模块。 - 核对仓库与运行环境；已有改动可能不在 HEAD 中，不能只记录提交号。 - 通过文件和关键符号定位代码，行号仅作辅助；命令来自实际依赖清单、脚本或 CI。 - 区分“已确认事实”“待验证假设”“拟新增内容”，记录必要证据及核对时间。 - 无法访问源码时说明限制，不编造文件、接口或命令。将必要调查列为任务，并指出受其阻塞的实施任务。 ### 2. 明确目标与边界 将用户意图转成可观察的结果，明确本次范围、非目标、权限和必须保持的行为。 优先从项目证据和已有约定解决问题。只有未决问题会影响目标、关键方案、数据安全或验收时才询问用户；不因普通实现细节反复确认。非阻断假设明确标注。 ### 3. 确定关键方案和修改职责 先确定接手者不应猜测的决策：相关接口、数据或状态变化、兼容策略、操作边界及失败行为；只为实际涉及的项目展开。 - 文件范围说明每个文件或模块需要承担的修改职责，不只列路径。 - 明确哪些是固定约束，哪些普通实现细节可由执行者判断。 - 尚未解决的关键设计先安排调查或验证任务，不包装成“直接实现”步骤。 - 涉及迁移、删除、共享数据或配置时，说明操作范围、恢复方法和验证条件；不向普通低风险修改套用无关流程。 ### 4. 拆分任务并关联验收 使用 [交接模板](assets/handoff-template.md) 生成文档，按依赖顺序组织任务。 - 每个任务解决一个明确问题，可独立审查和验证；不机械限制代码行数或文件数量。 - 为目标、任务和验收设置稳定编号，如 G-01、T01、AC-01，修订时保留原编号。 - 每项任务包含前置条件、涉及位置、具体动作、验证方法及执行记录。跨层行为需要多文件配合时，保持任务完整。 - 验证说明运行目录、必要环境、命令或人工操作及预期结果。未经执行的命令标明待执行；人工或平台验证缺少条件时说明限制。 - 全局约束、文件职责和总体验收各只写一次，任务用编号或章节引用；局部检查只补充本任务特有内容。 - 不默认委派子代理、自动提交 Git 或开展 GUI 操作；执行方式受当前授权和项目规则约束。 ### 5. 交付前自检并修订 对生成文档完成以下检查，发现问题先修订，不把审查作为用户必须另行选择的操作： 1. **事实可靠**：引用的文件、符号和命令有依据；拟新增内容与现有事实没有混淆。 2. **步骤可执行**：输入、依赖和预期行为明确；没有“完善逻辑”等缺少具体结果的关键步骤。 3. **目标可验收**：每个目标都有任务承接与验收依据；测试与实际风险相称，不要求无意义测试。 4. **范围一致**：方案、文件范围、任务、风险与交付没有矛盾或无关扩张，重复内容已合并。 核对本地文档链接及编号。不能声称自检证明实现正确，更不能将预期结果写成已运行通过。 ### 6. 交付接手入口 保存到用户指定位置或项目现有文档类别。没有文件写入授权时直接返回文档内容。 最终说明文档位置、适用基线、建议开始的任务及关键未决事项；简述实际完成的文档检查。交接文档包含必读资料和接手起点，执行者无需从聊天中寻找授权或设计决策。 ## 修订与执行记录规则 - 输入已有文档时，先核对代码与执行记录，再修改受影响部分。按项目规则备份，保留仍然有效的决策和证据。 - 历史验证注明对应版本或条件；环境或代码变化后不能自动当作当前通过。 - 新任务默认“未开始”；状态使用“未开始 / 进行中 / 已实现待验证 / 验证通过 / 阻塞”。已有状态仅在证据支持时保留。 - 执行者记录真实变更、验证结果、证据位置及下一步。写完代码不等于验收通过，跳过不等于通过。 - 普通实现细节允许自主调整；若必须改变目标、接口契约、数据安全边界或扩大修改范围，记录差异并交回规划者处理。没有证据时不得弱化验收来宣布完成。 - 方案修订只说明影响理解的变更原因，不积累冗长历史，不擅自覆盖已验证成果或其他人的工作。 ## 参考原则 以下是本工作流的参考实践，不代表任何公司的统一交接标准，也不保证不同能力模型的实现质量相同。用户只要求生成文档时，不必每次联网重查这些原则；具体 API、版本或其他不确定事实应按任务需要核实。 - [GitHub Spec Kit](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/)：需求、技术计划、任务与实施相互对应。 - [Google 工程实践](https://github.com/google/eng-practices/blob/master/review/developer/small-cls.md)：小而完整、便于审查的变更。 - [Anthropic 长任务实践](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)：增量推进、真实验证和可恢复上下文的进度记录。