agpair
Overview
Use this skill when your AI coding agent is the reviewer/controller and Antigravity is the executor.
agpair is the control surface for:
- preflight health checks
- task dispatch
- terminal-phase waiting
- evidence review
- semantic follow-up (
continue,approve,reject,retry)
It is not a second orchestrator and it is not the semantic decision-maker.
Triggering
This skill is intended to trigger when the user asks their AI agent to:
- send or delegate work to Antigravity
- use
agpair - inspect
doctor,daemon,task status, ortask logs - review an
EVIDENCE_PACK - approve, reject, continue, or retry a delegated task
For the strongest activation, the user can explicitly say use agpair or send this to Antigravity via agpair.
Workflow
1. Preflight first
Before any semantic action, check:
agpair doctor --repo-path <absolute-repo-path>agpair daemon status
Do not continue if the target repo is unhealthy:
desktop_reader_conflict=truerepo_bridge_session_ready=false
2. Inspect task truth
Use:
agpair task status <TASK_ID>agpair task logs <TASK_ID> --limit 20
Do not choose continue, approve, reject, or retry until status and logs were read.
3. Blocking wait discipline
If you enter a blocking wait path (task start default --wait, task wait, or semantic commands with default --wait):
- treat the wait as an active operation until it exits
- keep consuming the same long-running command session, or keep checking:
agpair task active-waitsagpair task status <TASK_ID>
- do not tell the user the task is done while an active waiter still exists
ACK means accepted, not completed.
4. Guard against premature intervention
If agpair task active-waits shows the task, or task status shows waiter_state=waiting:
- do not send another semantic action on the same task
- do not abandon/retry the task
- only use
--forceif the waiter is clearly orphaned
5. Pick one semantic action
Choose exactly one:
continuefor same-session follow-upapprovewhen evidence is good enough for finalizationrejectwhen work must continue in the same sessionretryonly when the session is stale or not worth continuing
Required gates
Before claiming completion:
- health was checked
- current task status was checked
- latest logs were checked
- if blocking wait was started, polling continued until terminal exit
- no same-task semantic action was sent while an active waiter existed
Anti-patterns
- Do not start a blocking wait and then stop polling while the conversation is still alive.
- Do not treat
ACKas proof of progress. - Do not jump straight to
continuebecause the user said “继续”. - Do not hide
desktop_reader_conflictorrepo_bridge_session_ready=false. - Do not invent commands or transport paths outside the real
agpairCLI.