用途
wtf.write-task 用于创建一个 GitHub Task issue，即“可实现的独立工作单元”。它的核心作用是把父 Feature 的验收标准（Acceptance Criteria）转换成 Gherkin 场景，从而在需求向实现传递的过程中不丢失信息。
主要能力
- 识别父 Feature：通过 AskUserQuestion 询问任务属于哪个 Feature，或从编排器传入的上下文直接使用。
- 命名任务：可从验收标准提议、由用户自行描述，或在无 Feature 上下文时单独描述。
- 澄清歧义：围绕范围、入口/出口、数据契约、错误处理、角色权限、性能要求、聚合、不变量、领域事件、限界上下文等主题逐个提问，不臆测答案。
- 探索代码库与 wiki：搜索会触及的文件模块、现有模式、集成点接口、相邻测试、依赖关系、聚合类、领域事件定义，并查阅术语表、wiki 或 ADR 以核对统一语言。
- 跨 Feature 依赖扫描：从 Epic 的 Feature Breakdown 中获取同级 Feature 及其 Proposed Tasks 清单，列出现有同级任务，找出范围重叠或需先行完成的任务。
- 垂直切片评估：按范围门控第一阶段判断任务是否能独立交付，是否过宽，或是否具有依赖。
- 询问契约：确认 API 契约、事件、数据 schema，并按 DDD 写作规则命名领域事件。
- 生成 Gherkin：为每条验收标准至少写一个快乐路径场景，并视情补充失败或边界场景；场景描述可观察结果而非内部状态，只使用统一语言，不引用实现细节。
- 起草任务：按 TASK 模板填写各章节，包括设计参考、可观测性、发布方式等。
- 范围门控：按第二阶段判断任务是否过大，并给出拆分策略（迁移与行为分离、按部署边界拆分、按用户旅程拆分）。
- 用户评审：展示草稿，重点确认 Gherkin 是否覆盖 Feature 验收标准。
- 创建并关联 issue：将正文写入临时文件，通过 gh-body helper 创建 issue，标题由 claude-haiku-4-5-20251001 子代理生成；随后将 issue 归类为 Task，并在扩展可用时建立原生子 issue 与依赖关系。
- 继续下一步：统计剩余任务，提供“为任务做设计”“写下一个任务”“写一个 Feature”“停止”等选项。
使用方式
该技能通过一系列步骤运行，依赖 GitHub CLI 环境检查、模板加载，以及多个参考文档（提问风格、规格层级、DDD 写作规则、STE 写作规范、范围门控、issue 分类、gh-body helper 等）。创建 issue 时，正文先写入临时文件，再通过 python3 .wtf/gh-body.py create --title "🛠 Task: <title>" --body-file "$BODY" 创建，以保证多行 UTF-8 内容在 Windows 上也能正确保留。标题用子代理生成，issue 归类为 Task；当扩展可用时，用 gh sub-issue add 关联父 Feature，用 gh issue-dependency add 建立阻塞关系。若扩展不可用，则警告用户，且不把关系引用写进 issue 正文。
适用场景
适用于用户想要创建任务、编写工单、把功能拆解为实现工作、分解故事、或定义验收标准等情境。也可从 wtf.feature-to-tasks 或 wtf.write-feature 等编排流程中被调用。
限制
技能运行依赖 GitHub CLI 安装与认证、TASK 模板文件及各类参考文档；若 gh 未安装或未认证则停止。原生子 issue 与依赖链接需要相应 GitHub 扩展，扩展不可用时只发出警告。是否创建原生关系由第 0 步的检查结果决定。关于该技能的收费、价格、平台支持等事实，资料中暂未提供。