一键导入
an-task-split
将大任务拆分为多个子任务,每个子任务的 requirements 文档控制在 200 行以内。当用户想要:1) 拆分一个大任务 2) 将任务分解为多个小任务 3) 执行 /an-task-split 命令 4) 提到"任务拆分"、"分解任务"、"大任务"、"拆分"等关键词时触发此技能。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
将大任务拆分为多个子任务,每个子任务的 requirements 文档控制在 200 行以内。当用户想要:1) 拆分一个大任务 2) 将任务分解为多个小任务 3) 执行 /an-task-split 命令 4) 提到"任务拆分"、"分解任务"、"大任务"、"拆分"等关键词时触发此技能。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
将现有工程转换为 AI Native 项目结构。当用户想要:1) 将现有项目转换为 AI Native 格式 2) 为已有代码生成 background/conventions/artifacts 文档 3) 执行 /an-init 命令 4) 让 AI 理解并接管现有项目 时触发此技能。**始终使用中文与用户沟通。**
探测、生成和运行 AI Native 可执行命令清单,包括验证、构建、代码检查、类型检查、代码生成和本地开发命令。用户询问可执行规则、项目命令、验证命令,或 /an-init 后需要让 projects 工程可被 AI 直接运行时使用。
根据实际代码和结果反向更新 background 背景知识库。当用户想要:1) 刷新/更新 background 文档 2) 代码已变但文档未同步 3) 执行 /an-refresh 命令 4) 提到"更新背景"、"刷新背景"、"同步文档"、"反推文档"等关键词时触发此技能。
根据输入的任务描述,先智能判断任务复杂度与风险,再选择 L0 直接处理、L1 快速修复、L2 标准开发或 L3 完整流程。适用于开发任务、bug 修复、代码重构、配置修改、文档更新、需求实现等。当用户想要:1) 开始一个开发任务 2) 提供了任务/票据/想法的原始描述 3) 执行 /an-task 命令 4) 提到"开发"、"实现"、"修复"、"添加"等关键词时触发此技能。触发后不要默认套完整流程;小改动可不创建 artifacts,直接实现、验证并总结。
基于 SOC 职业分类
| name | an-task-split |
| description | 将大任务拆分为多个子任务,每个子任务的 requirements 文档控制在 200 行以内。当用户想要:1) 拆分一个大任务 2) 将任务分解为多个小任务 3) 执行 /an-task-split 命令 4) 提到"任务拆分"、"分解任务"、"大任务"、"拆分"等关键词时触发此技能。 |
将大任务拆分为多个可独立推进的子任务,每个子任务的 requirements 控制在 200 行以内。
你是该领域的业务专家,具备丰富的产品和技术经验。你需要以专家视角理解用户任务,识别自然的业务边界和功能边界,做出合理的拆分决策。
用户可通过以下方式提供 raw-input:
artifacts/xxx/raw-input/task.md)raw-input → split-plan
目标:保存用户的原始大任务描述,不做加工。
行为:
artifacts/{YYYYMMDD}__{feature-name}/artifacts/{YYYYMMDD}__{feature-name}/raw-input/task.md产出物:
artifacts/{YYYYMMDD}__{feature-name}/raw-input/
└── task.md # 原始输入内容
目标:以业务专家视角分析任务,产出拆分方案。
前置:阅读以下文档获取上下文:
background/product/overview.md — 主题定位background/domains.md — 领域模型(如存在)background/features.md — 交付状态(如存在)行为:
产出物:artifacts/{YYYYMMDD}__{feature-name}/split-plan.md
# {任务名称} 拆分方案
## 任务理解
{以业务专家视角,阐述对任务全貌的理解}
## 拆分依据
{从哪些维度进行了拆分,为什么选择这些边界}
## 拆分概览
| 序号 | 子任务名称 | 核心目标 | 预估行数 | 依赖 |
|------|-----------|---------|---------|------|
| 1 | sub-1 | {一句话} | ~N行 | - |
| 2 | sub-2 | {一句话} | ~N行 | sub-1 |
## 依赖关系
{子任务之间的依赖拓扑描述}
## 子任务定义
### sub-1: {名称}
- **目标**: {一句话描述}
- **核心场景**: {关键业务场景}
- **关键验收标准**: {最核心的 AC 要点}
- **预估行数**: ~N行
- **Artifact**: artifacts/{YYYYMMDD}__{sub-1}/
### sub-2: {名称}
...
## 执行顺序建议
1. sub-1 → 2. sub-2 → ...
检查点:向用户展示拆分方案,等待用户审核确认。用户可能:
确认拆分方案后,更新项目根 AGENTS.md 的活跃 Artifacts 表:
| Artifact | 描述 | 状态 |
|----------|------|------|
| artifacts/{YYYYMMDD}__{feature-name} | {总任务拆分方案} | ✅ 完成 |
| artifacts/{YYYYMMDD}__{sub-1} | {子任务描述} | 🚧 待启动 |
| artifacts/{YYYYMMDD}__{sub-2} | {子任务描述} | 🚧 待启动 |
拆分完成后,用户可对每个子任务分别调用 an-task 进入标准工作流。拆分方案中的子任务定义可作为 an-task 的 raw-input 使用。
| 情况 | 处理 |
|---|---|
| 用户想修改拆分方案 | 调整 split-plan.md 后重新确认 |
| 用户只想推进部分子任务 | 仅创建选定子任务的产出目录 |
| 原始任务本身不大(预估 requirements < 200 行) | 告知用户无需拆分,建议直接使用 an-task |