39 lines
2.1 KiB
Markdown
39 lines
2.1 KiB
Markdown
---
|
|
description: Start, inspect, hand off, or finish one scoped AirDo task slice with automatic AirXDB/AirDbg routing and AirPlan result finalization
|
|
argument-hint: [enter|status|handoff|finish]
|
|
allowed-tools: [Read, Glob, Grep, Bash, Write, Edit]
|
|
---
|
|
|
|
# /airdo
|
|
|
|
Use AirDo for one narrow execution slice. It can run directly in the parent thread, but it is primarily designed to be launched as an isolated AirEng subagent.
|
|
|
|
## Steps
|
|
|
|
1. Parse `$ARGUMENTS`; default to `status` when empty.
|
|
2. Always operate from the current project root and store worker state under `AirPlan/state/airdo/`.
|
|
3. Run the matching mode:
|
|
|
|
```bash
|
|
python "$HOME/plugins/airdo/scripts/airdo_mode.py" --mode <enter|status|handoff|finish> --project . --task-id <task-id>
|
|
```
|
|
|
|
4. For `enter` or `handoff`, load:
|
|
- `AirPlan/AGENTS.md`
|
|
- `AirPlan/docs/architecture/adr/`
|
|
- `AirPlan/docs/architecture/c4/module.md`
|
|
- `AirPlan/plan.md`
|
|
- `AirPlan/todo.md`
|
|
- `AirPlan/state/airdo/tasks/<task-id>/brief.md`
|
|
|
|
5. When AirDo is invoked as an AirEng child:
|
|
- Treat the session as isolated and rebuild context only from the files above.
|
|
- Stay inside the task write scope from the brief/handoff.
|
|
- Finalize exactly one structured result under `AirPlan/state/airdo/results/<task-id>.json`.
|
|
- Treat `AirPlan/state/airdo/tasks/<task-id>/worker-state.json` `resultPath` as the canonical pointer to the latest result artifact. Do not assume the task-local template `result.json` is the finalized output.
|
|
- Do not stop at "准备实施", implementation-plan-only, or generic progress replies when the task is actionable. Continue editing, validating, and finalizing unless a real blocker or user decision is required.
|
|
- When the task changes planning or architecture reality, include concrete `documentUpdates` for `AirPlan/plan.md`, `AirPlan/docs/architecture/adr/`, and `AirPlan/docs/architecture/c4/module.md` instead of leaving those docs stale.
|
|
|
|
6. On GUI-like work, route acceptance through AirXDB before finishing.
|
|
7. On blockers or failed validation, route through AirDbg, continue through active repair briefs when present, and return one structured result for AirEng to merge.
|