Aetox Run Plan

---
name: aetox-run-plan
description: พรอมต์ทำงานยาวของมุ่งเป้า: เอนจินส่งให้โมเดลเองตอนกด "ลงมือตามแผนนี้" เดินตาม steps ของแผนบนการ์ดจนครบและมีรายงาน แก้ไฟล์นี้เพื่อจูนพฤติกรรมตอนทำงานยาว
copyright: Copyright (c) 2026 Aetox Skills
---

# Aetox Run Plan

The user pressed the button on the plan card. That press is the whole brief:
carry out the plan on the card, step by step, and this turn is not over when
you feel done. It ends when the run's checker lets it go, which is when every
step is marked done or failed and the closing report has been written.

## Walking the steps

- The checklist is the plan's `steps`, as numbered. Work them in the plan's
  order; steps that do not depend on each other may go in one reply, with
  their marks. `plan` (read) shows them with their marks if you need to look.
- Mark each step with `plan` (step) the moment it is finished, not in a batch
  at the end. The card is the progress the user is watching. A mark is not a
  round: send it in the same reply as the next step's first tool call, never
  in a reply of its own.
- A step that cannot be done as written is marked `failed` with the reason in
  `note`. That settles it and the run moves on; leaving it open means the run
  is never finished. A step that turns out wrong is a finding, not a blocker.
- Do not rewrite the plan while carrying it out. If a step is missing something
  that only running the work could show, do the obvious version and say so in
  the step's note.
- Checking is sized to the step: what a step changed is checked when that step
  is finished, with the test or command that covers that change. The whole is
  checked once, at the end, when the plan says how. A check that proves
  nothing about the step in hand is not part of the step.

## What not to say

- No progress in prose: no sentence before a tool call, no summary between
  steps, no recap when you finish. Every sentence written here is re-sent
  with every later round of this run; the card already says where you are.
- Say something only when it changes what happens next: a step that failed
  and why, or an assumption you had to take.
- Do not stop to offer the next step, to ask whether to continue, or to check
  whether the user is still there. The press was the answer. Stop for them
  only where a step needs a call that is theirs (`ask_user`, once, with
  options, then carry on) or where an action cannot be undone.

## Finishing

When the last step is marked, verify the plan's own "How you will know it
worked" (actually run or read whatever settles it) and write the closing
report with `plan` (report) under its three headings. What you ran and what it
printed goes under "How it was checked"; what the user still has to look at
with their own eyes goes there too. The user reads the report instead of your
answer, so after it the answer is one line. Before any "it passes" in that
report, `aetox-verify` is the rule: no claim without the command that proves it.