用途：将 Feature 的一个原子实现切片，转换为详细的 task-NNN-slug.md 任务文件，供工程师或编码智能体执行。输出路径为 {product_root}/docs/versions/{version_san}/tasks/task-NNN-slug.md；子版本放在 subversions/{subversion_san}/tasks/ 下。
主要能力：覆盖 Backend、Frontend、Infrastructure 三层；任务分类包括 Error（已有功能缺陷）、Improvement（已有功能行为变更）、Implementation（新功能）。核心原则是不写一句话摘要，实施者需明确做什么、可能路径、适用技术栈与规则、验证标准，且详细部分不得逐字重复摘要。
使用方式：先做 harness discovery，从 {harness_root}/rules/.md 加载规则，优先读 architecture-rules.md；仅当 {harness_root} 不存在时才使用旧版 .cursor/rules/.mdc。严格读取 requirements.md，不得虚构表或端点。输入包括来自 orchestrator 的原子任务描述、层类型、requirements.md、任务编号 NNN 与依赖任务。依赖规则：外键父任务先于子任务，任务顺序反映迁移/API 顺序；前端消费 API 时后端任务先于前端任务。完整文件模板见 references/task-schema.md。
分层要求：前端涉及 UI 时需 data-testid 契约（kebab-case，带 btn-、input-、form- 等前缀）；认证表单需 marketing panel、PasswordInput、按前端规则提供 i18n 键；所有字符串走翻译键，日期/货币用 useFormat()；新增菜单项需 groupKey（若存在导航规则）。后端在 uses_grogoo: false（默认）时使用 Sanctum 与手动模块，不引用 Grogoo；多租户时在验收标准中显式校验 company_id / 所有权。
适用场景与限制：适用于后端、前端、基础设施实现任务的生成；不负责 E2E 测试（用 e2e-test-generator）和后端单元测试（用 unit-test-task-generator）。相关技能：后端实现任务后用 unit-test-task-generator，前端 UI 任务后用 e2e-test-generator，版本全部任务写完后用 execution-handoff-generator 收尾。资料未提供具体安装命令、收费与平台信息。