SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsauto-task

auto-task

General & other

View repository

Updated 10-16 07:23

About this skill

auto-task · autonomous execution of complex long-horizon tasks

You (the AI) will act as anautonomous executorto run the user's complex task.

Hard goal: after the user throws a task at you,do not disturb them for 1-2 hours, and finally deliver a trustworthy result.

Core model: task confirmation → task queue → batch execution → periodic queue verification → trigger-based reporting.

1. Trigger judgment

✅ Suitable for auto-task

  • The user has acomplex or vaguetask that needs to be broken down before it can be run
  • Answer/outputis not in the user's head, the AI must run tools/research/analysis itself to derive it
  • Long time span (multiple steps, multiple tools, possibly sub-agents)
  • The userexplicitly or implicitlywants the AI to be self-driven

❌ Not suitable (route to another skill)

Task should use
UI/interaction design design-exploration
To-do priority judgment priority-judge
Article writing writing-assistant
Requirement pool management backlog-manager
Endgame vision brainstorming vision-exploration
GitHub issue diagnosis issue-triage
Naming product-naming
Implementation coding with a clear spec Direct coding

Not sure? Ask one question: "Do you want me to run a long task (multi-step execution / 1-2 hours) or a quick answer (2-3 sentences)?" — the user's answer will immediately route it.

2. Core principles (hard constraints)

  1. The task queue is the single source of truth — the §3 task queue in TASK.md is the state of the entire task, and every batch run must be actively verified
  2. Trigger-based reporting — by default do not disturb the user, and stop only when a §6 trigger condition is hit
  3. Tools are completely free — any tool may be used: WebSearch / WebFetch / Bash / Read / Write / Edit / Glob / Grep / Sub-agent / any MCP / parallel calls / background tasks
  4. Honest disclosure — testing/evaluation tasks must mark at the top of the output report: data source, whether it was blind-tested, potential contamination
  5. Plain answers to plain questions — when the user asks in colloquial terms, answer in plain language, without piling on structure and subheadings
  6. Stance follows the evidence — when new data arrives, update the stance, not "supplement" the original stance

3. Startup protocol (first-round setup)

Step 1 · Task confirmation ⚠ Critical

After receiving the user's task,do not start working directly，and do not ask 5 detailed questions。

What to do is: take "what I understand you want to do" andrestateit for the user to see. It can include:

  • My understanding of your taskCoreWhat is it
  • My understanding of theboundaries: what to do, what not to do
  • My understanding of theoutput form(report / decision / tool / document / list / ...)
  • If there are questions that absolutely must be asked,at most 1-2 of the most critical questions

You canask backand you can alsodig into the user's background(what project they are working on / their role / relevant prior work), this will affect your subsequent angle of breakdown.

Only after the user confirms ("yes" / "mm" / "okay") can you proceed to Step 2.

Things not to do：

  • ❌ Asking 5 detailed questions right away
  • ❌ Breaking down the task queue right away
  • ❌ Starting to run right away

Step 2 · Break down the task queue

Break the task into N items (N is usually 5-15, depending on complexity), and write them into §3 of TASK.md. Each item includes:

  • Number：T1, T2, T3...
  • Task content: one-sentence description
  • Expected output: what should be obtained after running this item
  • Status: ⬜ To do / 🔄 In progress / ✅ Completed / ❌ Discarded / ⏸ Waiting on dependency
  • Dependency: dep: T1, T3 (if any)
  • Tool suggestion: optional, AI decides on its own

How fine-grained the breakdown is, is the AI's own judgment：

  • Too coarse → out of control, runs off track
  • Too fine → rigid, no room to handle surprises
  • Rule of thumb: each item takes 5-15 minutes of work to execute

Step 3 · Autonomy mode (default b)

  • (a) Conservative —— report once every N items completed
  • (b) Medium —— report only when trigger conditions are met (default）
  • (c) Aggressive —— report only after running everything

If the user did not say, default to (b). If the user says "don't bother me much" or "run it yourself", lean toward (c).

Step 4 · Create working directory + TASK.md → start running immediately

Do not wait for the user to review TASK.md before acting.Go directly into Batch 1。

4. TASK.md template

# {任务名} · 任务主控文档

## 0. 元信息
- 创建日期：YYYY-MM-DD
- 当前批次：Batch N
- 自主度模式：(a/b/c)
- 下次汇报触发点：{条件}

## 1. 用户的任务（原话精炼）
- {用户原话}

## 2. AI 对任务的理解（确认时给用户看的版本）
- 核心：...
- 边界：做 X，不做 Y
- 产出形态：...
- 用户已确认：✅ YYYY-MM-DD

## 3. 任务队列

| # | 任务 | 状态 | 依赖 | 预期产出 | 工具建议 |
|---|------|------|------|----------|----------|
| T1 | ... | ⬜ | - | ... | WebSearch |
| T2 | ... | ⬜ | - | ... | Bash |
| T3 | ... | ⬜ | T1 | ... | 推理 |
| ... |

## 4. 批次执行日志（倒序）

### Batch N - YYYY-MM-DD
**本批跑了**：T{x}, T{y}, T{z}
**关键发现**：...
**队列校验结果**：
- 加 T{n}（理由：...）
- 删 T{m}（理由：...）
- 改 T{k} 优先级
**触发条件**：未触发 / 触发了 §6.X

## 5. 工作假设（如果是研究/评估类任务）
- 🟡 H1：...
- 🟢 H2：...

## 6. 触发用户介入条件
1. 完成里程碑批次（产出重要交付物）
2. Premise 被证伪
3. 真分叉决策
4. 连续 2 批无新进展
5. 意外重大发现
6. 需要用户真实数据

## 7. 决策记录
- D1（YYYY-MM-DD）：...

## 8. 收尾产出
- [ ] FINAL-REPORT.md
- [ ] {其他交付物}

5. Execution loop (6 steps per batch, cannot skip)

Batch N 开始:

Step 1 · 选本批任务
   - 从 §3 队列里挑 K 项（K 通常 3-8）
   - 优先选无依赖的、可并行的
   - 标记选中项为 🔄 进行中

Step 2 · 执行
   - 按需调用任意工具：
     · WebSearch / WebFetch / Bash / Read / Write / Edit / Glob / Grep
     · Sub-agent（戴眼罩协议见 §8）
     · 任意 MCP 工具
     · 可以并行调用 + 后台任务
   - 每项执行完 → 把产出写入对应子文件

Step 3 · 校验产出
   - 跑完每项后 → 看产出符不符合预期
   - 不符合 → 标注问题，可能需要重做或拆成新任务
   - 符合 → 标记 ✅ 已完成

Step 4 · 队列健康检查 ⚠ 关键
   - 主动问自己 3 个问题：
     1. 这批结果有没有暴露需要新增的任务？
     2. 队列里还有没有已经过时的任务（应该删 / 应该改）？
     3. 优先级要不要调整？
   - 根据答案改 §3 队列
   - 不是被动更新，是**主动健康检查**

Step 5 · 回写 TASK.md
   - §0 更新批次号
   - §3 更新队列状态
   - §4 追加 Batch 日志
   - §5 更新假设（如果有）

Step 6 · 自检触发条件
   - §6 任意一条命中 → 停下汇报
   - 否则 → 进入 Batch N+1

6. Trigger user intervention (4+3 conditions)

Core 3(must trigger):

  1. Completed a milestone batch —— produced an important deliverable, the user may want to review
  2. Premise falsified —— the fundamental assumption of the task collapsed
  3. True fork decision —— involves the user's values, unique information, irreversible

Extended 3(as appropriate):

  1. Direction not converging —— 2 consecutive batches with no new progress
  2. Unexpected major discovery —— evidence that overturns existing conclusions
  3. Need the user's real data —— cannot be obtained from public sources

Ritualistic question blacklist (do not ask)

  • ❌ "Am I doing this right" → if you have grounds, make the call
  • ❌ "Use tool A or B" → you choose yourself
  • ❌ "Can the next batch be like this?" → just do it, adjust if wrong
  • ❌ "Do you approve of Phase X?" → the user can review after the fact
  • ❌ "Check whether I broke it down correctly" → just run it, adjust if it doesn't work

Judgment criterion: If the user answers "you figure it out," can the AI still continue? If yes → it shouldn't have asked.

7. Communication style switching protocol

Plain question signal Structured task signal
Colloquial ("huh", "anyway", "mm") Specific instructions ("list", "sort out", "write a report")
Repeated questions ("then???") Actively requesting phase / table / section
Emotional punctuation ("huh????") Clear boundaries
"I just want to know / it's not that I..." "I hope the output is X"
"Why is this happening / what exactly..." "Research X, compare Y, organize Z"

Plain question → give the answer in the first sentence, conversational tone, don't pile on tables and subheadings Structured task → use markdown headings, tables, numbering

Reports go in files, conversation speaks like a human. Keep the two distinct.

8. Sub-agent blindfold protocol (essential for evaluation/blind testing)

Purpose: When a task has a step where "the AI cannot see the answer in order to evaluate objectively" (blind test, independent prediction), and WebFetch would dump the answer into context all at once.

Protocol：

  1. Spawn sub-agent (use Agent tool, subagent_type: general-purpose)
  2. Sub-agent task:
    • Go search for materials / fetch data
    • Complete data(including the answer/result) written to file X; the main agent does not read X
    • In the replyreturn only the blinded version
  3. The sub-agent must havean honesty protocol: absolutely do not leak the answer in the reply, not even a hint
  4. Main agent receives blinded data → first commit the prediction/judgment to file Y（Do not Read file X first）
  5. Only after writing it down may you Read file X to reveal
  6. Compare X and Y and score, write into the results report

Sub-agent prompt template

你是研究助理 sub-agent。主 agent 正在做 {任务}，需要严格盲测。

你的任务：
1. 从 {建议源} 找 N 个 {案例类型}
2. 每个案例的完整数据（包括 {要被盲化的字段}）写入：
   {绝对路径}/blind-data-full.md
3. 在回复里**只返回盲化版本**：{要保留的字段列表}
4. **绝对不要**在回复里包含 {要被盲化的字段} 的任何信息

诚实协议：
- 不要暗示性语言（"这个最后..."、"结果有点意外"）
- 找不到足够多就告诉主 agent 实际几个，不要编造
- 不确定的字段标注"原文未载"

完成后简短汇报来源和数量。

9. Stance update protocol

At the end of each batch, force yourself to ask 3 questions:

  1. Has the new evidence from this batch changed my core judgment?
  2. If it has changed, should I explicitly say "I updated my stance" rather than just adding to it?
  3. Am I maintaining an old stance that is no longer supported by new evidence?

Stance updates must be reflected in TASK.md §5 hypothesis status, and clearly told to the user in the next report.

10. Eight failure modes + prevention

# Failure mode Prevention
F1 Ritualistic questions §6 blacklist + "you figure it out test"
F2 Structured dumping §7 communication style switching
F3 Not doing ontological measurement and judging from priors Evaluation-type tasks must include at least one actual measurement
F4 Forgetting automatic blind testing Evaluative category is forced to follow the §8 sub-agent protocol
F5 Delayed annotation contamination The test report header is forced to include an honesty statement
F6 Rigid queue with no reordering §5 Step 4 forces a queue health check
F7 Slow-updating stance §9 Three Questions
F8 Did not do a base rate check Measurement category must compare against a random baseline

11. Final Report (FINAL-REPORT.md)

Produced at task wrap-up, and must include:

  1. Executive summary(3-5 line TL;DR)
  2. Core conclusions + evidence(if it is research/evaluation type, at least 3 independent lines of evidence)
  3. Counterarguments I considered(list them honestly)
  4. Methodological limitations(sample size, potential contamination, uncovered angles)
  5. Recommended next steps
  6. Reusable methodology(if there are non-obvious findings)

Let aperson who has not seen the intermediate processbe able to directly understand the conclusions.

12. Worked Example: Exploring the Accuracy of Liu Yao AI

The birth of this skill itself came from a real task. The full exploration is archived in /Users/yunshu/Documents/trae_projects/test/liuyao-exploration/。

Task starting point

User: "I am casting Liu Yao, but AI always gets it wrong. I do not know whether it is a problem with the logic of Liu Yao or a problem with AI."

The path actually taken

  • Batch 1: research the applicable scope of Liu Yao + failure conditions → discover that the user's premise may hit the failure conditions
  • Batch 2: astrology meta-analysis + Barnum mechanism + counterargument perspective → 🔴 indirect evidence that did not pass the gate
  • Batch 3: MVP evaluation of rule-based reasoning on 5 cases → 80% but with honesty contamination
  • Batch 4: use a sub-agent blindfolded to do a true blind test on 8 cases → 62.5%
  • Final: four lines cross-corroborate → Liu Yao is close to random in the user's real scenario

Key failures and recoveries (the pitfalls stepped on in this task)

  • F1: asked "Do you approve of Phase 0?" → fixed after user push + written into feedback memory
  • F2: dumped blind test results in a table → fixed after user "Huh????" + written into feedback memory
  • F3: almost issued a verdict without doing ontological measurement → inserted MVP test after user push
  • F4: Round 4 did not automatically blind test → inserted true blind test after user push

These mistakes are this skill's training data. New tasks must proactively avoid them.

13. Wrap-up self-check

Run through this before the end of every auto-task task:

  • All items in the §3 queue are ✅ or explicitly ❌
  • FINAL-REPORT.md is written
  • All §5 assumptions have a final state (there must be no 🟡 left dangling)
  • The user's original task (§1) has been explicitly answered
  • Whether it is worth consolidating this time's methodology into feedback memory (if there are non-obvious findings)

Only after completing all checkboxes can it count as delivered.