Initial release: airdo

This commit is contained in:
admin
2026-05-18 11:45:00 +08:00
commit 5e1684b73f
5 changed files with 210 additions and 0 deletions

38
commands/airdo.md Normal file
View File

@@ -0,0 +1,38 @@
---
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.