القائمة
任务管理核心方法论——状态机、GWT 验收、task.json 结构、规划分解、实施流程、提交规范、子代理策略。触发场景：(1) 创建或管理任务，(2) 写 acceptance 验收条件，(3) 规划任务分解，(4) 判断任务状态转移，(5) 管理 blocked_by 依赖，(6) 写 commit message，(7) 用户说"任务"、"task"、"规划"、"分解"、"验收"
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | dtask |
| description | 任务管理核心方法论——状态机、GWT 验收、task.json 结构、规划分解、实施流程、提交规范、子代理策略。触发场景：(1) 创建或管理任务，(2) 写 acceptance 验收条件，(3) 规划任务分解，(4) 判断任务状态转移，(5) 管理 blocked_by 依赖，(6) 写 commit message，(7) 用户说"任务"、"task"、"规划"、"分解"、"验收" |
| argument-hint | [功能描述] [category] [blocked_by] |
| allowed-tools | ["Read","Write","Edit","Bash","Grep","Glob"] |
任务管理核心方法论：从需求到验收的完整生命周期。
| 状态 | 含义 | 修改权限 |
|---|---|---|
| InDraft | 需求草稿中 | 主代理可改 title/description/acceptance/steps |
| InSpec | 已确认锁定 | 主代理只能改 status |
| InProgress | 实施中 | 主代理可改 status |
| InReview | 验证中 | 主代理可改 status |
| Done | 已完成 | 主代理可改 status |
| Cancelled | 已取消 | 主代理可改 status |
| 当前 | 事件 | 新状态 | 规则 |
|---|---|---|---|
| InDraft | 人工确认 | InSpec | Agent 不可再改需求字段 |
| InDraft | 取消 | Cancelled | - |
| InSpec | 开始实施 | InProgress | - |
| InSpec | 发现问题 | (保持) | 退回 InDraft 重确认 |
| InProgress | 完成准备验证 | InReview | - |
| InProgress | 遇阻塞 | InSpec | 记录原因 |
| InProgress | 取消 | Cancelled | - |
| InReview | 通过(小幅度) | Done | 自审 |
| InReview | 通过(大幅度) | Done | 需人工确认 |
| InReview | 失败返工 | InProgress | - |
| InReview | 取消 | Cancelled | - |
| Done | (终态) | — | 忽略所有事件 |
| Cancelled | 重新激活 | InSpec | 直接锁定 |
| 场景 | 判定结果 | 证据等级要求 |
|---|---|---|
| API/字段契约变更 | 大幅度，需人工确认 | L1-L2 运行态证据 |
| 单任务 >2000 行 | 大幅度，需人工确认 | L1-L3 自动化证据 |
| 字段默认值变化影响调用方 | 大幅度，需人工确认 | L1 调用链证据 |
| 小幅度+acceptance 全通过 | 小幅度，自审 Done | L3+ 至少一项 |
证据等级：L1=运行态 / L2=调用链 / L3=自动化断言 / L4=表面观察 / L5=间接推断。仅 L5 不可宣称完成。
| 依赖链类型 | 判定结果 |
|---|---|
| A→B→C（无回边） | 合规 |
| A→B→C→A（有回边） | 违规，拒绝 |
| A→B 与 B→A 隐藏在不同描述 | 违规，拒绝 |
functional/ui/bugfix 类必须用 GWT；infra/refactor 类可选。
格式："Given [前置条件] When [用户动作] Then [预期结果]"
infra/refactor 可用简单描述如 "构建产物不超过 500KB"Then 子句自检：能否写成 expect(actual).toBe(expected)？不能则细化。
| 键名 | 类型 | 说明 |
|---|---|---|
id | 数字 | 从 1 递增，永不复用 |
title | 字符串 | 一句话描述（动词开头） |
description | 字符串 | 背景+关键约束 |
acceptance | 数组 | GWT 格式验收场景 |
steps | 数组 | 实施步骤，绝对路径；[锁定]=技术选型，[建议]=实现细节 |
files_modified | 数组 | (可选) 并行冲突检测 |
category | 字符串 | functional/ui/bugfix/refactor/infra |
blocked_by | 数组 | (可选) 前置任务 ID |
status | 字符串 | 运行时状态 |
任务分类：
| 分类值 | 适用场景 |
|---|---|
functional | 新增业务功能、API、核心逻辑 |
ui | 页面、组件、交互、样式 |
bugfix | 修复已知 bug |
refactor | 不改变行为的代码结构优化 |
infra | 构建、部署、配置、脚本 |
语义：前置任务未完成，当前无法开始。 权限：InDraft 自由；InSpec 可改需记录；InProgress 及之后不可改（需退回 InSpec）。 何时使用：前置任务未 Done 且当前依赖其输出时。已 Done 或仅代码调用关系时不使用。
合法性检查：
自动清理：
InDraft 阶段：提炼功能点 → 拆分为可描述任务 → 定义验收条件 → 识别依赖排序 → 展示结果 → 写入 task.json（状态 InDraft）。
InSpec 阶段：人工确认后 Agent 改为 InSpec；此后只能修改 status 字段；需改需求则退回 InDraft。
代码 < 2000 行；有明确 acceptance（GWT）；有清晰 steps（绝对路径）；不依赖未完成任务或在 blocked_by 标注。
状态一律 InDraft；ID 递增不复用；category: functional/ui/bugfix/refactor/infra；追加到列表末尾；必须含 acceptance（GWT）；steps 必须自包含。
| 判断问题 | 可预期 | 不可预期 |
|---|---|---|
| 团队做过类似？ | 做过 | 没做过 |
| 90% 把握？ | 有 | 没有 |
| 外部依赖可控？ | 可控 | 不可控 |
| 多模块集成测过？ | 测过 | 没测过 |
全部可预期 → 直接 InProgress；任一不可预期 → 先验证再 InProgress。
大幅度修改：API/字段变更 或 单任务 >2000 行。其余自审即可。
自审原则：只实现 acceptance 要求，不多不少；不引入技术债。
| 偏差等级 | 权限 | 例子 | 记录要求 |
|---|---|---|---|
| L1: Bug 修复 | 自动修复 | 类型错误/import缺失/语法错误 | session 文件 |
| L2: 关键缺失 | 自动补充 | 缺少错误处理/输入验证 | session 文件 |
| L3: 阻塞问题 | 自动修复 | 依赖缺失/配置格式错误 | session 文件 |
| L4: 架构变更 | 必须问用户 | 新建数据库表/切换框架/破坏性 API 变更 | DECISION TRACE |
单任务累计 L1-L3 ≤5 次，超则评估 acceptance/steps 缺陷。
[Task#N] 标题 - completed
Category: functional/ui/refactor/infra/bugfix
Files: src/auth.ts, src/models/user.ts
Evidence: L1-L3 (运行态+自动化)
Status: Done
[Task#N] 标题 - completed (并行)
## 子代理 A (auth 模块)
Files: src/auth.ts, src/middleware.ts
Evidence: L2-L3
Acceptance: [x] GWT-1 PASS [x] GWT-2 PASS
Status: InReview(超前 3/5)
大任务实施过程中记录中间进度，写入 session 文件。
触发条件（满足任一即触发）：
并行条件（同时满足）：问题域不相交、无共享写文件、files_modified 无重叠。 串行条件（满足任一）：后步依赖前步输出 / 需积累上下文。
| 要素 | 说明 |
|---|---|
| 专业化分工 | 探索类 haiku 只读；验证类跑测试；实施类主模型写代码 |
| Worktree 隔离 | 并行实施可用 worktree 隔离 |
| Coordinator Pattern | task.json 状态由主代理维护 |
| 超前计数器 | 主代理内存维护，session 重启后统计恢复 |
| 交接清单 | acceptance PASS/FAIL 逐条 + 代码变更摘要 + 遗留阻塞点 + 下一步前置条件 |
核心原则：未验证 = 未完成。所有 acceptance 逐条验证通过后才标记 InReview。
| 验证方式 | 适用场景 |
|---|---|
| 自动化（推荐） | verify.sh 脚本 |
| 手动 | Agent 提供步骤清单 → 人工反馈 |
| 人工审查 | 大幅度修改 REVIEW 请求 |
| 独立验证 | verifier agent |
失败处理：保持 InProgress，修复后重新验证。
归档管理——Task 归档与 Recording 物理归档的双轨机制、触发条件、手动步骤、验证清单。触发场景：(1) 终态任务数超阈值，(2) session 文件数超阈值，(3) 用户说"归档"、"archive"、"清理"
纠偏与误判排查方法论——退化信号检测、四行重写模板、止损序列、六类泛化误判排查表、与 BLOCKED 的边界判定。触发场景：(1) 出现退化信号（反复纠偏/目标漂移/证据缺失等），(2) 需要纠偏恢复，(3) 排查误判，(4) 判断是 correction 还是 BLOCKED，(5) 用户说"纠偏"、"偏了"、"不对"、"重写"、"止损"、"误判"
积木式能力验证方法论——判断「直接做 vs 先验证」、将不确定性分层隔离、沉淀可复用能力资产。触发场景：(1) 讨论技术可行性或方案选型，(2) 评估某个实现的不确定性，(3) 决定直接集成 vs 先做 Demo 验证，(4) 分析能力复用或知识沉淀策略，(5) 用户说"积木"、"Demo"、"能力验证"、"不确定性"
产品文档工具——正向（需求→文档）或逆向（代码→文档）两种模式。触发场景：(1) 为已有产品还原/补全文档，(2) 为新功能/模块编写产品文档，(3) 用户说"写文档"、"还原文档"、"doc"、"产品文档"
阶段边界决策锚点——四段式判断（启动/实施/验收/纠偏），含正例/反例/边界例。覆盖：基线失败处理、不确定性决策、入口门控、大幅度判定、执行偏差分级、并行串行选择、超前实施、Done 人工确认、blocked_by 判定、循环依赖、continuous_mode 续跑、recording 写入时机、decisions.md 写入时机。触发场景：(1) 需要做阶段边界决策，(2) 判断幅度大小，(3) 选择并行还是串行，(4) 判断是否需人工确认，(5) 用户说"判断"、"决策"、"幅度"、"并行"、"确认"
产品需求分析方法论——竞品分析、用户画像、需求优先级排序、迭代层次设计、方案对比、非功能性需求分类。触发场景：(1) 讨论产品规划或功能设计，(2) 进行需求分析或竞品调研，(3) 设计迭代路径或优先级排序，(4) 用户说"PRD"、"需求文档"、"竞品分析"、"产品规划"、"需求优先级"、"迭代规划"、"方案对比"