Agent Skills: Delegate repository work and verify the result

Let Codex use Google Antigravity CLI (agy) for repository exploration, bounded feature work, and project-scale implementation. Use when a Codex task benefits from delegated repository work while Codex retains diff review, verification, repair, and delivery assurance.

UncategorizedID: aiskillstore/marketplace/agy-worker

Install this agent skill to your local

pnpm dlx add-skill https://github.com/aiskillstore/marketplace/tree/HEAD/skills/cagdasyurekli/agy-worker

Skill Files

Browse the full folder contents for agy-worker.

Download Skill

Loading file tree…

skills/cagdasyurekli/agy-worker/SKILL.md

Skill Metadata

Name
agy-worker
Description
Let Codex use Google Antigravity CLI (agy) for repository exploration, bounded feature work, and project-scale implementation. Use when a Codex task benefits from delegated repository work while Codex retains diff review, verification, repair, and delivery assurance.

Delegate repository work and verify the result

Use this skill for useful repository exploration, bounded implementation, or broad project work through agy. The worker discovers ordinary structure and proposes or makes changes; Codex remains responsible for scope, diff review, driver-owned checks, repair decisions, and the final assurance label.

Resolve the installed package instead of guessing a checkout path:

PIPELINE="$(bash "$SKILL_ROOT/scripts/resolve-pipeline.sh")" || exit $?

Optionally check offline prerequisites before spending provider quota:

"$PIPELINE/doctor.sh" --repo /absolute/path/to/target

ready covers offline prerequisites only. It does not prove authentication, provider availability, task quality, or future job success. For installation and package orientation, read Package README.

Before every provider launch

Obtain explicit approval for the exact transmission mode, repository content, and task being sent unless that exact provider transmission was already approved.

For an ordinary job, prepare one concrete approval package covering foreseeable provider work, readable/writable scope, derived repair feedback, model, and budgets. Reuse that authority while it remains applicable. Fresh state hashes and internal candidate checks are mechanical bindings, not requests for another human approval. Ask again only for a material change in authority, content exposure, destination, or budget. Minimize approvals without treating exactly one approval as a hard requirement. Prepare manifests and private paths for the user; ordinary jobs require neither hand-authored JSON nor a Goal.

Prefer --provider-scope FILE --approve-transmission-sha SHA256 for bounded jobs. It binds exact reviewed read entries, their selected-content digest, and a write subset, then stages only selected entries in a fresh owner-private mode-0700 Gitless provider cwd. Whole-worktree dispatch remains an explicit exception. Treat the entire disposable worktree passed as --workdir as worker-readable and potentially transmissible to Google/Gemini, regardless of requested edit paths; --add-dir, prompt denylist instructions, qa-gate --only, and --allow do not narrow that read boundary. Neither workflow.sh run nor the advanced agy-worker.sh initial dispatch has an implicit transmission mode: launch requires either --approve-whole-worktree LAUNCH_APPROVAL_SHA256 or the scoped pair above. The deprecated facade-only --approve-preview-sha spelling cannot launch by itself and remains temporarily available only with --legacy-preview-approval. New jobs default to --provider-isolation session, which uses the existing AGY session without AGY sandbox or native host containment. AGY has normal user filesystem/network authority; selected-file staging and reconciliation are not host isolation. Include this execution mode in the initial approval alongside task/content, then reuse that approval while its scope remains unchanged. Explicit --provider-isolation native retains supported macOS scoped containment with private HOME/TMP and reviewed network/Keychain access; it never falls back to session mode. The native /usr/bin/security exception allows broader same-user Keychain operations, and its listener rule permits wildcard binds. Read Security and compatibility for those limits. Preserve the job's selected mode across continuation and repair. Provider-scope approval grants neither provider execution, Git action, driver acceptance, nor publication. Before each launch, ensure secrets, credentials, private keys, user-denied paths, and unrelated private files are absent from every entry approved for provider transmission; telling the worker not to read an approved entry is not a control.

Keep raw worker logs and local controller state outside the worktree and out of prompts. Installation does not authorize provider transmission, Git actions, publication, or acceptance.

Before every provider-launch attempt (initial start/run, resume, continue, and restart), tell the user in one or two concise user-facing sentences what task is being sent to AGY. Include a short public-safe task label, caller-selected model information, caller-selected effort when separately selectable, and the exact resolved model slug. For default selection where no model is selected or the default tier is used, state truthfully that the provider default model is used and that model or effort is unresolved, without inventing a resolved slug or thinking level. For fixed/compound/literal models where effort is not separately selectable, state that accurately without inferring backend reasoning or inventing a thinking level. The notice must precede every dispatch attempt and remain accurate afterward. If preflight fails before provider launch, explicitly state that the task was not sent to AGY. If provider reach is genuinely uncertain, state that it is unverified rather than claiming success. Direct model and effort selection remain caller-owned; recommendations are advisory.

For the complete transmission, environment, verifier, and compatibility boundaries, read Security and compatibility.

Route the request

| User intent | Workflow | Default cycle budget | Driver responsibility | |---|---|---:|---| | Explore, understand, review, or plan | explore | 2 | Spot-check material claims and state coverage limits. | | Implement a feature, refactor, tests, or a bounded repair | task | 2 | Inspect the diff and run relevant project checks. | | Build a project or perform broad audit-and-fix work | project | 5 | Review repo-wide changes and run build/test/lint as applicable. |

explore and task accept 1..2 cycles; project accepts 1..5. Personas are optional prompt specializations, not capability, approval, routing, verification, or quality gates.

The advanced raw dispatcher also offers an opt-in --boost profile for one bounded task cycle. Boost may invoke provider-side subagents and protected tools, so it requires the exact job-bound --approve-boost-risk-sha printed by the rejected preflight. The acknowledgement does not grant runtime permissions or widen provider scope. Boost is restricted to accept-edits, one cycle, no persona, and default slash protection; the controller accepts a result only when the provider init frame reports both agent=Boost and permission_mode=request-review. A Boost job cannot resume, restart, or continue. Treat any failed attempt as terminal and request a new job and fresh approval rather than reusing its conversation.

For material UX, lifecycle, trust-boundary, security, data-semantics, or other domain plans: A coordinator and suitable domain expert must co-plan. Freeze user journeys, acceptance tests, and authority/privacy constraints before implementation. The final acceptor must be a different agent or fresh context; no planner or implementer may self-accept. Purely mechanical changes are exempt. Verification v2 and the controller bind candidate evidence, not agent identity or governance. The final human-readable handoff must report the planner/reviewer separation.

Explicit delegation-first requires running the delegation-policy.sh evaluator before substantive repository work. The controller records are local: the runtime cannot infer prior work or approval and must never silently authorize direct-Codex fallback after a missing approval, hard stop, preflight failure, provider failure, or exhausted budget. Direct-Codex and second-eye work remain explicit policy choices.

Use the primary lifecycle

Prefer the portable workflow.sh facade for run --preview, approved run, read-only status, and verify-finalize. For ordinary use, supply only an absolute repository and job ID; optional --base overrides the first-call HEAD binding. The facade derives owner-private state and delegates branch-backed disposable-worktree creation to the job lifecycle. Review the content-free preview, then repeat the same repository/job ID with --approve-whole-worktree and its exact manifest digest, or preview with --provider-scope and repeat it with the exact --approve-transmission-sha. Preview and stale approval retain those bindings. Explicit state/worktree/branch/base inputs remain an all-or-nothing advanced compatibility surface. The lifecycle may roll back only clean façade-created resources from the same failing pre-dispatch invocation and refuses any drift or dispatch evidence.

Facade status can project an explicitly supplied existing low-level job state, dispatcher state, or dispatcher job ID. Treat its available actions as read-only facts; run any mutation through the named low-level lifecycle authority.

After a candidate arrives:

  1. Inspect the actual Git diff; do not trust files_changed or worker prose.
  2. Select build, test, lint, or type-check commands yourself. Never execute commands_run or tests_run from an envelope.
  3. Run writable checks in a verification copy so generated artifacts cannot change the bound candidate.
  4. Bind only sanitized driver findings to the current candidate in Verification v2.
  5. Continue the same conversation for a bounded repair when useful, or finalize with an accurate verified, partially_verified, rejected, or blocked disposition.

Do not delete a useful candidate merely because a check fails or the cycle budget ends. A fresh restart is an explicit user decision, not an automatic retry.

The copyable facade, lifecycle-state, Verification v2, isolated-copy, gate/receipt, and finalization procedures live in Project lifecycle and verification. For actionable failure diagnosis, read Troubleshooting.

Hard stops and delivery

Do not dispatch or continue when:

  • the exact provider transmission is unapproved;
  • secrets, denied paths, or unrelated private content remain anywhere in the default worktree transmission or inside scoped entries approved for staging;
  • the requested write can escape the disposable worktree, enter .git, or traverse a symlink boundary;
  • the task requires dangerous permission or approval bypass flags;
  • a commit, push, PR, feedback submission, release, installation, update, account action, or other external write lacks its own authorization.

Unknown files, incomplete architecture knowledge, an unknown first test command, lack of a persona, or a failed first check are not hard stops by themselves. Discover what is needed, preserve the candidate, and report evidence limits honestly.

Before changing agy-facing flags or claims, resolve the installed package and run "$PIPELINE/ground-truth.sh" without arguments, then inspect its current agy --help output; do not describe that interface from memory. Its default interface phase invokes only agy --version and agy --help. --account is a separate explicit action because it inspects account-owned model, agent, plugin, and local-settings state. An agy exit zero with empty ordinary output is possible: consume result.structured_output, not the echoed schema.

Before delivery, review the exact candidate bytes and run the relevant driver-owned checks. Report only what those checks establish. Do not claim provider success, completeness, release state, security, or general correctness from offline evidence.