do-long-task 是一个面向长任务执行的入口 skill。它不负责替你决定“大任务做什么”，而是负责把已经确定的长任务稳定推进到底。
用途
适用于需要跨多个步骤持续推进的开发、修复、重构、迁移或验收任务；适用于任务会经历上下文压缩、会话中断、测试失败、恢复续跑的情况；适用于任务必须把计划、进度、发现、失败和验证写入文件，而不能依赖聊天记忆的情况；适用于任务已经有明确的唯一主任务源，通常是 OpenSpec 的 tasks.md。
不适用场景包括：单文件小改动或一次性格式化；只是在回答问题、解释方案，或者还在做需求探索；写 changeset、提交信息、更新日志这类短任务；不需要 checkpoint、恢复续跑、失败记录的简单操作。
提示词生成模式
当用户要求生成 Claude Code /goal 或 Codex /goal 提示词、生成长任务执行提示词，或用 do-long-task 写 1500 字以内提示词时，进入提示词生成模式。该模式只做一件事：输出一段可复制给 Claude Code /goal 或 Codex /goal 使用的长任务执行提示词，不开始执行该长任务。生成提示词时不修改 OpenSpec 工件，不创建或更新 agent-progress.md / agent-findings.md，不运行测试、lint、typecheck 或 validate 命令，不把聊天 checklist 当任务源。默认把最终提示词控制在 1500 字以内；如果用户指定更短或更长的字数限制，以用户指定为准。如果用户没有提供 openspec/changes/<change-name> 或 tasks.md 路径，不臆造路径，而是输出带 <change-name> 的占位模板，并列出需要用户补齐的占位符。
协作与任务源
需要协作的全局技能是 openspec。执行 OpenSpec change 时，先使用 openspec 理解 proposal.md、design.md、specs/ 和 tasks.md 的工件链。业务项目内如果存在项目级 OpenSpec 技能，必须先发现并读取，再执行 change。按项目根目录优先检查 .claude/skills、.codex/skills、.agents/skills、.agent/skills 中与 openspec 相关的技能入口；只读取当前任务需要的技能与 reference。当检测到当前任务位于 openspec/changes/<change> 下时，必须以当前 OpenSpec 工件链为准，tasks.md 是唯一可执行任务源。长任务执行中发现遗漏任务时，先更新当前 change 的 tasks.md，再继续执行；不得只把遗漏任务写在聊天 checklist、agent-progress.md 或子代理报告里。
固定产物位置门禁
执行模式下，必须先确定唯一的 OpenSpec change 根目录，再创建或更新 agent-progress.md / agent-findings.md。规范位置只有两类：正在执行的 change 位于 openspec/changes/<change-name>/，已归档的 change 位于 openspec/changes/archive/**/<change-name>/。确定 change 根目录时按优先级判定：用户明确给出的路径；当前工作目录位于某个 change 内；扫描到唯一一个与用户目标、tasks.md 标题或当前 checkpoint 明确匹配的 change 目录。如果无法唯一确定 change 根目录，不要在当前目录、仓库根目录、openspec/changes/ 顶层、openspec/changes/archive/ 顶层、普通报告目录或 skill 目录中创建这两个文件，先提示用户补齐 change 路径。
错位文件检查与迁移
执行模式每次启动、恢复、上下文压缩后、创建固定产物前，以及完成前，都要检查工作区内是否已有错位的 agent-progress.md / agent-findings.md。对每个命中文件判断路径是否位于规范 active change 根目录或 archive change 根目录。若路径不规范，立即警告用户，列出相对路径、不规范原因、准备迁移到的 change 目录及归属证据。若当前任务已唯一确定 active change，把错位内容迁移或合并到该 change 根目录对应文件；目标文件已存在时，追加一个“Migrated from <relative-path> on <YYYY-MM-DD>”小节，保留原文和迁移原因。若内容属于已归档任务且能唯一识别 archive 下的具体 change 目录，迁移到对应文件。若存在多个候选 change、无法从内容识别归属，或迁移可能覆盖已有记录，停止并询问用户。迁移后回读目标文件确认内容存在，再删除错位源文件；不能确认时保留源文件并记录风险。不要把迁移理解为整理到 reports，这两个文件是 OpenSpec change 的附属状态文件，只能跟随具体 active change 或 archive change。
先读什么
开始前先读：AGENT_LONGTASK.md（如果存在）；按 AGENT_LONGTASK.md 读取路由选中的 references/.md；当前 skill 的 SKILL.md；业务项目内 .claude/skills、.codex/skills、.agents/skills、.agent/skills 中与 OpenSpec 相关的项目级技能；当前 OpenSpec change 的 proposal.md、design.md、specs//spec.md、tasks.md；先扫描并处理错位的 agent-progress.md / agent-findings.md；change 根目录的 agent-progress.md 与 agent-findings.md。如果这些文件有缺失，就先补齐，再继续。
核心纪律
任务源只用一份，若项目使用 OpenSpec，就以 tasks.md 为唯一任务清单，不再创建第二套任务系统。每次只处理一个明确的 task 或 checkpoint，不跳过未完成任务，不把未验证内容标记为完成，代码修改后必须做相关验证。OpenSpec 工件链必须完整维护：先读 proposal.md、design.md、specs//spec.md、tasks.md 再动手；发现遗漏任务先扩展 tasks.md；改变用户可见行为先同步 specs//spec.md；改变技术路线先同步 design.md。过程报告、进度文档、调研文档若需保存在当前 OpenSpec change 内，必须放入 tasks.md 或项目 OpenSpec 规范明确指定的子目录，并使用 YYYY-MM-DD-*.md 命名，不得在 change 根目录散放 markdown。change 根目录只保留 OpenSpec 核心工件、agent-progress.md、agent-findings.md 以及项目规范明确允许的根级文件。
状态文件 harness 控制
agent-progress.md 与 agent-findings.md 是交接状态文件，不是事件日志、聊天转储或原始输出仓库。agent-progress.md 采用覆盖式快照：每次 checkpoint 或 task 边界更新当前快照，修改现有状态，不逐条追加；快照只保留当前 checkpoint、当前 task、状态、最近验证摘要、阻塞点、下一步和证据索引；默认软上限为 40 行；只保留最近 3 个证据索引。agent-findings.md 记录去重后的持久发现：每条发现必须回答结论是什么、证据在哪里、状态是什么、后续动作是什么；状态只使用 active、superseded、resolved；默认软上限为 80 行或 20 条有效发现。写入前逐项检查：下一位 agent 是否会因这条信息采取不同动作；是否有证据索引或明确状态；是否已存在同义条目；是否属于任务清单。
标准推进方式与完成前检查
开始前刷新文件状态，确定唯一 change 根目录并处理错位文件；选定一个 task，理清验收标准和验证命令；核对是否需要同步 design.md、specs/*/spec.md 或补写 tasks.md；只做最小可验证改动；运行相关测试、lint、typecheck、OpenSpec validate 或其他必要验证；把进展写入规范位置；只有满足验收标准才勾为完成；进入下一个 task 前重新读取文件状态。完成前需确认代码已实现、验收标准已满足、验证命令已通过或已记录替代方式、agent-progress.md 与 agent-findings.md 已更新、新增 markdown 未散落根目录、状态文件仍在 change 根目录且只保留摘要索引、工作区无错位文件、没有未解决的 CRITICAL 问题。
限制与注意
长任务靠文件，不靠聊天记忆；只保留一个任务源；小步推进；每步都要能恢复；先验证再完成。不要每个小步骤都问用户是否继续，除非遇到真正阻塞。只有遇到权限问题、破坏性风险、需求冲突、产品决策问题，或连续 3 次同类失败时，才暂停并请求用户介入。关于收费、价格、平台与具体效果，资料中暂未提供。