Includes AirPlan design documents, AircOding-alpha1-plan, AirPlanV2, AirPlan-ParaV2, AirPlan-Para V1 reference docs, and all working code changes across packages. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2.1 KiB
Executable File
2.1 KiB
Executable File
description, argument-hint, allowed-tools
| description | argument-hint | allowed-tools | |||||||
|---|---|---|---|---|---|---|---|---|---|
| Start, inspect, hand off, or finish one scoped AirDo task slice with automatic AirXDB/AirDbg routing and AirPlan result finalization |
|
|
/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
- Parse
$ARGUMENTS; default tostatuswhen empty. - Always operate from the current project root and store worker state under
AirPlan/state/airdo/. - Run the matching mode:
python "$HOME/plugins/airdo/scripts/airdo_mode.py" --mode <enter|status|handoff|finish> --project . --task-id <task-id>
-
For
enterorhandoff, load:AirPlan/AGENTS.mdAirPlan/docs/architecture/adr/AirPlan/docs/architecture/c4/module.mdAirPlan/plan.mdAirPlan/todo.mdAirPlan/state/airdo/tasks/<task-id>/brief.md
-
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.jsonresultPathas the canonical pointer to the latest result artifact. Do not assume the task-local templateresult.jsonis 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
documentUpdatesforAirPlan/plan.md,AirPlan/docs/architecture/adr/, andAirPlan/docs/architecture/c4/module.mdinstead of leaving those docs stale.
-
On GUI-like work, route acceptance through AirXDB before finishing.
-
On blockers or failed validation, route through AirDbg, continue through active repair briefs when present, and return one structured result for AirEng to merge.