---
name: an-task
description: 根据目标、范围、风险和不确定性选择 L0-L3 流程，并推进到实际产出、结构化 Review 和归档。适用于开发、写作、研究、分析、设计、整理和配置等需要 AI 执行的任务。用户明确下达“开始吧”“开始做”“实现”“动手”“开工”“按方案执行”等进入执行态的指令时，无论此前讨论了多少轮，都必须先经过本 Skill 分流。
---

# AI Native 任务执行

使用最轻但足够安全的流程完成实际工作。阶段、生命周期和 Review 契约以 `conventions/workflow.md` 为唯一权威定义；流程等级只按 `conventions/flow-policy.md` 判断。

## 〇、触发与逐消息重新分流

- 设计讨论、方案澄清、需求确认、答疑等不产生实际产出的对话属于讨论态，不触发本 Skill，AI 正常参与讨论即可。
- 用户明确下达“开始吧”“开始做”“实现”“动手”“开工”“按方案执行”“可以做了”等进入执行态的指令时，无论此前讨论了多少轮，都必须先进入本 Skill 分流，按流程等级推进；不得因前文已有方案或上下文连续而直接执行。
- 每收到一条新消息都重新分流：仍在澄清讨论则保持讨论态；已明确要求执行则进入任务分流。上下文连续性不构成跳过分流的理由。
- 无法判断是否进入执行态时，按 `flow-policy.md` 的暂停条件向用户确认，不默认直接执行。

## 一、流程分级

自主判断 L0-L3，并用一句话向用户说明等级和理由。不要让用户选择流程等级、方案或检查动作。只有 `flow-policy.md` 定义的暂停条件成立时才请求确认；调查中发现风险升高时立即升级。

## 二、输入与历史任务

用户可以直接描述任务，也可以提供文件、目录或链接。将未加工内容视为 raw；只有 L2/L3 或确有恢复需要时才保存到 Artifact。

仅当用户明确提到继续、恢复、上次或之前的任务时，才搜索活跃和已归档 Artifact：

- 活跃项从 `artifacts/index.json` 定位，确认后继续。
- 已归档项保持只读；需要继续时创建新 Artifact，并用 `parentArtifactId` 关联历史 ID。
- 匹配不唯一时才请求用户选择。

## 三、L0/L1

L0：定位材料，完成最小正确产出，执行最小检查并总结，不创建 Artifact。

L1 默认同样不创建 Artifact。需要恢复、追踪或后续扩展时创建轻量 Artifact，至少包含：

```text
artifacts/{artifact-id}/
├── artifact.json
├── raw/task.md
├── execution/summary.md
└── review/review.json
```

L1 的轻量检查标准直接写入 `review.json.criteria[].description`，不要求创建 requirements。

## 四、创建 L2/L3 Artifact

1. 生成以 UTC 日期开头的 `YYYYMMDD__task-name` ID；`task-name` 只使用小写字母、数字和连字符，同日重名时追加稳定短后缀。
2. 创建 `artifact.json`，初始状态为 `in_progress`。
3. 将 `id`、`path`、`status`、`updatedAt` 写入 `artifacts/index.json`。
4. 阶段目录按需要创建，不创建空目录。

机器字段、时间格式、deliverables 元素和索引路径统一遵循 `conventions/workflow.md`，不要在 Skill 内另建字段。

每阶段结束后同时更新 `artifact.json.updatedAt` 和索引项的 `updatedAt`。实际交付物写入 `projects/` 或用户指定位置，并将 `{ kind: "deliverable", path, description }` 加入 `deliverables`；过程文档和子 Artifact 不加入该数组。

## 五、背景读取

L2/L3 在提炼需求前只前置读取：

```text
background/AGENTS.md
background/overview.md
```

随后根据 `background/AGENTS.md` 和实际存在的文档按需读取相关背景。不得假设 `product`、`tech`、`features` 等固定行业目录。任务执行期间不修改 background。

## 六、阶段执行

### raw

将用户提供的原始描述保存到 `raw/task.md`。引用本地材料时优先记录来源路径；只有任务需要独立快照且不包含凭据、隐私数据或无必要大文件时才复制。

### requirements

将目标、范围、约束、依赖、开放问题和完成标准写入固定门禁文件 `requirements/requirements.md`。每项完成标准使用唯一稳定 ID：

```markdown
## 完成标准
- [ ] AC-1: ...
- [ ] AC-2: ...
```

requirements 中的复选框只便于阅读，不是机器状态；实际检查结论只写入 `review.json`。

### design 与 spec

比较可行方案并选择符合现有结构、风险最低、改动最小的方案。L2 可以把简要 design 作为 requirements 中的独立章节；L3 使用 `design/`。spec 至少记录执行步骤、影响位置、产出要求、约束和 Review 计划。

### execution

按 spec 完成实际工作。将产出位置、执行摘要、偏离 spec 的事项和补充决策写入 `execution/summary.md`，并更新 `artifact.json.deliverables`。

### review

调用 `$an-review` 按稳定 ID 检查实际产出。Review 结果必须写入 `review/review.json`，Markdown 报告仅供阅读。可修复问题由 Review 修复时，必须同步更新 execution 摘要。

- PASS：将状态更新为 `completed`。
- REVIEW：保持 `in_progress` 或 `paused`；用户明确接受并记录 `acceptance` 后，由 `$an-archive` 直接事务归档。
- BLOCKED：保持 `in_progress` 或根据阻塞情况改为 `paused`。

### archive

PASS 状态为 `completed` 后只调用一次 `$an-archive`；已接受 REVIEW 和 cancelled 任务也调用同一 Skill。摘要、移动、状态和索引更新均由 Archive 事务脚本负责，`an-task` 不重复执行。用户明确要求暂不归档时保留当前状态。

归档完成后，只有本任务形成了可长期复用且已有事实依据的新背景时，才运行 `$an-refresh`。不得在归档前直接修改 background。

## 七、暂停、取消与恢复

- 用户暂停：将状态改为 `paused`，在 execution 摘要记录下一步；恢复时改为 `in_progress` 并同步索引。
- 用户取消：将状态改为 `cancelled`，记录取消原因和未完成范围，再使用 `$an-archive` 执行取消归档。
- 用户修改前序结果：回到对应阶段；若原状态为 `completed`，先改回 `in_progress`、清除旧 acceptance，再更新后续记录并重新 Review。
- 无法执行检查：记录原因、替代证据和风险，不得伪造通过结果。
