Files
AirCoding/AirPlan/docs/spec/AirPlan-ParaV2/plugins/airdo/commands/airdo.md
AirCoding ae44be31d5 chore: push all design docs, V2 plan specs, and current working state
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>
2026-06-12 17:12:29 +08:00

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
enter|status|handoff|finish
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:
python "$HOME/plugins/airdo/scripts/airdo_mode.py" --mode <enter|status|handoff|finish> --project . --task-id <task-id>
  1. 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
  2. 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.
  3. On GUI-like work, route acceptance through AirXDB before finishing.

  4. On blockers or failed validation, route through AirDbg, continue through active repair briefs when present, and return one structured result for AirEng to merge.