agpair

Delegate coding work to Antigravity through agpair CLI: dispatch a task, wait for EVIDENCE_PACK or COMMITTED, inspect doctor/daemon health, review logs, or s...

Security Scan

The skill's instructions and metadata are internally consistent with a CLI-based bridge to Antigravity, but it omits declaring the required agpair binary and the skill requests shell execution ability — you should verify the CLI's provenance before enabling it.

Purpose & Capability

The name, description, and SKILL.md all describe controlling an 'agpair' CLI to dispatch and monitor Antigravity tasks; this capability legitimately requires the agpair CLI and shell access. However, the skill's declared requirements list no required binaries (it should declare the agpair executable), so there's a small mismatch between stated purpose and declared requirements.

Instruction Scope

SKILL.md only instructs the agent to run agpair CLI commands (doctor, daemon status, task status, task logs, active-waits, semantic actions) and to follow clear gating/guard rules. The instructions do not request unrelated files, network endpoints, or credentials; they do require knowledge of an absolute repo path (implying filesystem context) but do not tell the agent to exfiltrate other data.

Install Mechanism

This is an instruction-only skill with no install spec or code files, so nothing new is written to disk by the skill itself. The claw.json points to a GitHub repository, but there is no automatic download or extract step in the skill package.

Credentials

The skill does not request any environment variables, credentials, or config paths. The only notable item is the declared permission for 'shell' in claw.json, which is proportional to running a local CLI but is a broad capability that you should be aware of.

Persistence & Privilege

The skill is not forced-always, it is user-invocable, and it does not request persistent presence or modify other skills' configurations. Autonomous model invocation is enabled (platform default) but that is not in itself a red flag here.

Assessment

This skill appears to be what it says: a control surface for an external agpair CLI. Before installing, verify you have a trusted agpair CLI binary available and that it comes from the repository listed in claw.json (https://github.com/logicrw/agpair). Ask the publisher to explicitly declare the required binary in the skill metadata. Be aware the skill will run shell commands (claw.json lists 'shell' permission) — if you enable it, run initial tests in a sandbox or on a non-sensitive repo to confirm behavior. If you don't trust the agpair executable's source, do not enable the skill or restrict the agent's ability to execute shell commands.

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, or task 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=true
• repo_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-waits
  • agpair 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 --force if the waiter is clearly orphaned

5. Pick one semantic action

Choose exactly one:

• continue for same-session follow-up
• approve when evidence is good enough for finalization
• reject when work must continue in the same session
• retry only 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 ACK as proof of progress.
• Do not jump straight to continue because the user said “继续”.
• Do not hide desktop_reader_conflict or repo_bridge_session_ready=false.
• Do not invent commands or transport paths outside the real agpair CLI.