@a2f0/agent-tool 0.1.7 → 0.1.9

package/README.md

@@ -101,6 +101,7 @@ agent-tool skills install --apply
 | `versions plan\|bump\|check <base-oid>` | Plan, rewrite, or check package versions against an exact base |
 | `versions prepare <base-oid>` | Bump, refresh `bun.lock`, validate, and commit versions; print a JSON receipt |
 | `versions resolve-conflicts` | Resolve only version-field conflicts in configured manifests |
+| `dependencies check-terraform-plan <json-file>` | Read-only screening for destructive or incomplete Terraform JSON plans |
 | `skills list` | List embedded portable skills |
 | `skills install [--harness all\|claude\|codex\|opencode] [--apply]` | Preview by default; install or update managed skills |
 | `skills check [--harness all\|claude\|codex\|opencode]` | Read-only CI check for current managed skills |
@@ -220,7 +221,8 @@ if new skills do not appear. OpenCode may list identical skills from both
 paths.
 
 The bundle provides `cross-agent-review`, `open-pr`, `squash-merge`, `ship-pr`,
-and `reset`. They make no package-manager or project-layout assumptions:
+`reset`, and `update-dependencies`. They make no package-manager or project-layout
+assumptions:
 
 - Keep validation commands, review-bot rules, and deployment checks in the
   project's `AGENTS.md`.
@@ -236,6 +238,52 @@ is no force mode. After updating the dependency, run
 fails for missing, outdated, unmanaged, or edited skills without writing
 anything. Use the same `--harness` for install and check.
 
+### Dependency upgrades
+
+Invoke `update-dependencies` in Claude Code, Codex, or OpenCode to inventory and
+upgrade package dependencies, runtimes, mise tools, Actions, native toolchains,
+Ansible, Terraform providers/modules, and other repository-owned pins. It reads
+official migration guides, upgrades coupled dependencies together, resolves
+deprecations, and records validated, constrained, and skipped upgrades. It follows
+the repository's existing upgrade skills and support policy.
+
+Read-only advisory checks cover baseline and candidate lockfiles, including
+resolved transitive and native dependencies. The skill traces findings to their
+owning dependency and prefers an upstream-supported fix. A scoped security patch
+override requires compatibility evidence, a regression check of the affected
+integration, and a documented removal condition; blind audit fixes and blanket
+compatibility overrides are excluded. Remaining advisories and audit limits are
+reported explicitly. For published packages, the skill also checks tarballs and
+consumer installs with their documented supported managers, including override
+syntax and runtime requirements.
+
+The skill requires a dry run before any infrastructure mutation, including ones
+triggered by hooks or CI on push/merge. Resource destruction or replacement, and
+previews that cannot establish safety, skip the affected upgrade group. A Wrangler
+bundle dry run alone does not prove remote resource safety. The skill does not
+itself authorize deployment or shipping; use `ship-pr` when requested.
+
+For a full refreshed Terraform saved plan, export its private JSON and screen it:
+
+```sh
+terraform show -json /private/path/upgrade.tfplan > /private/path/upgrade.json
+agent-tool dependencies check-terraform-plan /private/path/upgrade.json
+```
+
+The check returns JSON with `ok`, `issues`, and `resourceActions`, and exits 1 for
+unsafe or unsupported plans. It rejects delete and replacement actions, unknown
+actions, destructive drift, incomplete/deferred plans, unpassed checks, and opaque
+provider action invocations. It requires JSON format 1.x and `complete: true`
+(available from Terraform 1.8); older plans without completeness evidence fail.
+OpenTofu's current JSON format omits `complete` and is not accepted; report that
+limitation rather than fabricating the field.
+Missing `resource_changes` is valid for a complete empty or output-only plan;
+removing an output is not a resource deletion. Invalid JSON fails without echoing
+the input. The command never applies or contacts a backend and prints no attribute
+values. It cannot establish plan freshness, environment/identity, provider or
+provisioner side effects, or authorization; inspect those before deploying and
+apply the exact approved saved plan. Keep state and plans out of Git.
+
 ## Review guarantees and limits
 
 Reviews run against exact base and head snapshots. Review policy comes from the
@@ -271,7 +319,10 @@ can resolve fork PR bases; `pr open` supports same-repository branches.
 
 ## Development
 
-Development and the CI workflow use Bun 1.4.2.
+Development and all build/release workflows use Bun 1.4.2 and TypeScript 7.0.2.
+The compiler is used through `tsc`; this repository does not depend on its removed
+JavaScript compiler API. Runtime consumers still support Bun 1.3.11 or newer;
+CI also runs the installed-package smoke and plan-guard tests on that minimum.
 
 ```sh
 bun install --frozen-lockfile

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@a2f0/agent-tool",
-  "version": "0.1.7",
+  "version": "0.1.9",
   "type": "module",
   "description": "Portable cross-agent review, PR workflows, and shared skills",
   "license": "UNLICENSED",
@@ -31,7 +31,7 @@
     "build": "bun run generate && bun build --compile --minify src/index.ts --outfile dist/agent-tool"
   },
   "devDependencies": {
-    "@types/bun": "1.3.11",
-    "typescript": "5.9.3"
+    "@types/bun": "1.4.2",
+    "typescript": "7.0.2"
   }
 }

package/skills/update-dependencies/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: update-dependencies
+description: Update a repository's dependency manifests, lockfiles, runtimes, tools, and CI pins with upstream migrations, compatibility checks, and non-destructive infrastructure previews.
+---
+
+# Update Dependencies
+
+Use the repository's package managers and installed `agent-tool`. Read `AGENTS.md`,
+README, linked setup/release documents, and repository-owned upgrade skills before
+editing. Follow their hooks, version policy, checks, and requested stopping point.
+Update applicable dependencies throughout the repository, including workspaces
+and examples. This skill does not authorize deploying, merging, publishing, or
+changing global tools; use existing user authorization and `ship-pr` when shipping
+is requested. Default dependency-update merge subject: `chore: update dependencies`,
+subject to repository title policy and any explicit user subject.
+
+## Safety before execution
+
+**Always dry-run before any infrastructure apply or deployment. Never destroy,
+replace, or recreate a resource during an upgrade.** This includes Terraform,
+OpenTofu, Wrangler, Ansible, other infrastructure tools, and effects triggered by
+installation, tests, hooks, Git push, opening a PR, CI, or merging. Greenfield
+projects and approval to ship do not waive this rule.
+
+Before running project commands or pushing, trace their scripts, hooks, workflow
+triggers, reusable workflows, and deployment commands. A dry-run flag alone is
+insufficient: inspect tasks, provisioners, plugins, external programs, and actions
+that can mutate despite preview mode. Avoid such a preview unless its effects
+are proven read-only. Do not run destroy/delete, taint/replace, state removal,
+backend migration, forced database reset, or an automatic "repair" that bypasses
+the rule. Do not hide destruction with targeting, disabled refresh, ignored
+changes, new resource identities, or weakened policy.
+
+Preview with the proposed versions and complete configuration for each affected
+environment, using its real backend/workspace/account, variables, inventory, and
+resource identities. An empty local state, mocked credentials, validate-only run,
+or bundle build cannot establish safety for production. Check the current baseline
+as well when needed to distinguish existing drift from the upgrade. Keep state,
+binary plans, JSON plans, and secret-bearing diffs out of Git and public reports.
+
+If a preview proposes deletion or replacement, fails, is incomplete, omits
+affected resources, or cannot establish safety, skip that dependency and its
+coupled migrations. Restore only this task's edits to the affected compatibility
+group, retain independent safe upgrades, and record the reason and affected
+resources. Never apply to find out. A preview is not deployment authorization.
+
+Before an authorized apply/deploy, verify the exact validated commit, toolchain,
+configuration, environment, and current state still match the preview. Re-preview
+after relevant changes or drift. CI must enforce the same order and stop on an
+unsafe preview before mutation; a successful local preview does not excuse an
+unguarded push- or merge-triggered deployment. Establish a narrowly scoped guard
+when authorized and reviewable, or hold the affected upgrade before triggering
+that workflow. Do not disable protections to ship. A plan must be inspected before
+the operation; inspecting deployment logs afterward is too late.
+An unsafe workflow triggered on every branch push also blocks pushing otherwise
+independent upgrades until that trigger has a proven safe guard.
+
+### Terraform and OpenTofu
+
+Read core, provider, and module upgrade guides, including intermediate major
+migrations. Regenerate provider locks with the pinned CLI, preserving supported
+platform hashes. Backend initialization/migration is also subject to the safety
+gate. Inspect external data programs and provisioners before planning.
+
+Use a full refreshed saved plan with locking and the real variables, for example
+`terraform plan -input=false -out=<private-plan>`; if using `-detailed-exitcode`,
+0 and 2 are success, 1 is failure. Inspect `terraform show -json <private-plan>`.
+Run `agent-tool dependencies check-terraform-plan <private-plan.json>` to check
+supported JSON resource actions. It fails for every action containing `delete`,
+including both replacement orders, unknown actions, incomplete/deferred plans,
+failed checks, or opaque provider action invocations. It prints actions and
+diagnostics without resource attribute values; it does not prove that a plan is
+fresh, comprehensive, authentic, or that provider code has no hidden effects.
+Older/unsupported plan formats that cannot establish completeness are skipped.
+OpenTofu currently omits `complete` in its JSON format and is rejected by this
+helper; report that limitation rather than adding a synthetic completeness flag.
+Also inspect resource identity, drift, warnings, provider semantics, and any
+effects outside resource actions. For an authorized apply, consume the exact
+approved saved plan, not an uninspected newly generated plan.
+
+Source: [Terraform JSON plan format](https://developer.hashicorp.com/terraform/internals/json-format).
+
+### Wrangler and other deployment tools
+
+Use the proposed pinned Wrangler for `wrangler deploy --dry-run` with the same
+build/configuration/environment used by deployment. This checks bundling, not a
+complete remote resource plan. Separately verify account, worker name, routes,
+bindings and resource IDs against the existing deployment and read migration
+semantics. Review Durable Object deleted/renamed classes, D1 schema/data
+migrations, storage resources, queues, containers, and deployment integrations.
+Never infer "no destruction" from a successful bundle. Resource removals,
+replacement, or unprovable remote effects skip the affected group. Apply the
+equivalent preview and identity checks to other tools rather than assuming they
+share Terraform's guarantees.
+
+Source: [Wrangler command documentation](https://developers.cloudflare.com/workers/wrangler/commands/).
+
+### Ansible
+
+Check controller Python, ansible-core, collections/roles, and target Python support
+together; read porting guides. Inspect all tasks and invoked scripts before
+`ansible-playbook --check --diff` with the real inventory and variables.
+`check_mode: false` forces mutation even with `--check`; unsupported modules and
+conditions based on registered results can omit effects. Inspect deletion,
+recreation, service/data reset, and package removal semantics beyond the diff.
+Skipped or opaque tasks are a safety gap, not a clean preview. Redact diffs.
+
+Source: [Ansible check mode limits](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_checkmode.html).
+
+## Inventory and choose compatible targets
+
+Record each dependency source, current resolved version, latest stable candidate,
+selected target, compatibility constraints, upstream migration links, and checks.
+Query authoritative registries, official releases, support matrices, and migration
+guides at execution time; do not treat remembered versions or prereleases as
+latest stable. Inspect runtime requirements, peer dependencies, ABI/API changes,
+platform availability, maintained release lines, and changed defaults, including
+security, privacy/telemetry, data retention, and postinstall/native behavior.
+Check transitive dependencies' peer/runtime constraints as well as direct ones. Unsupported
+or unpublished targets stay pinned with an explanation.
+
+Inventory manifests, locks, tool configuration, CI/reusable actions, containers,
+scripts, deployment files, and executable documentation. Search duplicate version
+pins and aliases, not just filenames; exclude vendored/generated snapshots unless
+the repository owns their update process. Examples of sources to inspect:
+
+| Ecosystem | Sources and compatibility group |
+| --- | --- |
+| JavaScript/TypeScript | All package.json dependency fields, overrides/resolutions, workspace catalogs, packageManager/engines, npm/Bun/pnpm/Yarn locks, Node/Bun pins, compiler and lint/build/test plugins |
+| Toolchains | mise.toml/.mise.toml, mise.lock, .tool-versions, runtime version files, tool URLs/checksums, CI pins and container images; include every tool declared by mise, not just mise itself |
+| Python/Ansible | pyproject/requirements, uv/Poetry/pip locks, Python pins, ansible-core, collection/role requirements, lint plugins and managed host constraints |
+| Ruby/iOS | .ruby-version, Gemfile/lock, Bundler, CocoaPods, Podfile/lock, podspecs, Swift packages and Xcode/iOS deployment requirements |
+| Infrastructure | Terraform/OpenTofu CLI constraints, provider locks/constraints, module versions/Git refs, Wrangler and Cloudflare integration dependencies |
+| CI/system/native | Actions/reusable workflow refs, Docker tags/digests, OS images/packages, Rust/Cargo toolchain and locks, Go modules, Gradle/AGP/Kotlin/JDK and other repository-specific manifests |
+
+Build connected compatibility groups before editing. Select the newest supported
+combination, which can be older than an individual package's latest. Upgrade the
+framework first or keep its compatible toolchain pinned; do not force peer
+resolution, drop compatibility checks, or add blanket overrides to make installs
+pass. Preserve source pin policy (exact version, digest, full Git SHA) and resolve
+immutable pins from verified upstream releases. Preserve intentional runtime
+minimums unless migration requires changing the support contract.
+
+For React Native, use its version-specific upgrade guide/template diffs and
+repository upgrade skills. Couple React and its renderer, native modules,
+Metro/Babel, CLI, codegen, Hermes/New Architecture, CocoaPods/Bundler/Ruby,
+Xcode/iOS deployment targets, and Android Gradle/AGP/Kotlin/JDK/SDK/NDK. For Expo,
+use the chosen SDK's supported React Native/dependency matrix and its dependency
+checks. Do not independently update framework-managed pods or generated native
+files; use the framework's regeneration workflow and prove iOS/Android builds.
+Permissive peer ranges alone do not prove native renderer or toolchain compatibility;
+check the framework's actual supported versions and native implementation.
+An unavailable native toolchain is a reported validation limit; do not claim the
+group verified. See [React Native upgrading](https://reactnative.dev/docs/upgrading).
+
+Check developer tools' own dependencies too: a compiler release without its old
+programmatic API may break test/lint runners that import it even when `tsc` passes.
+Action runtime upgrades can require newer self-hosted runners; preserve workflow
+permissions, action inputs/outputs, caching, artifact semantics, and job names.
+
+Check current advisories with read-only ecosystem audits against the baseline and
+proposed lockfiles, using the repository's configured registry/advisory sources.
+Do not send private dependency metadata to an unconfigured or unauthorized service;
+report the resulting coverage limit. Cover direct and resolved transitive dependencies,
+including native/platform-specific binaries. Latest direct packages can still
+pin vulnerable transitive versions. Trace each finding to its owning dependency,
+verify affected versions, runtime conditions, and remediation in the maintainer's
+advisory and fixed release. When the owner's range permits a fixed version, use a
+targeted refresh with the lockfile's owning manager and preserve unrelated
+resolutions; otherwise prefer a supported owner upgrade.
+If the owner still pins a vulnerable version, a narrowly scoped security patch
+override may be used only with API/ABI/runtime compatibility evidence and focused
+regression checks of the actual affected integration. Document its rationale and
+removal condition; a passing install or bundle alone is insufficient. Do not run
+blind audit fixes or use blanket overrides to bypass compatibility constraints.
+Report unresolved advisories and unavailable audit coverage accurately; current
+direct pins or a partial clean audit do not
+establish that the whole dependency graph is safe.
+
+## Migrate and validate
+
+Capture relevant baseline checks and warnings first, after screening their side
+effects. Update one compatibility group at a time. Read the upstream instructions
+for every breaking step; implement required source/config/schema migrations and
+removed API replacements. Use the manager that owns each lockfile, on the selected
+runtime, and inspect the resulting diff. Refresh transitive dependencies through
+their owning direct dependency; do not hand-edit integrity hashes or lock entries.
+Review intentional patches, overrides, and pins before removal; retain them until
+upstream fixes and regression checks demonstrate they are unnecessary.
+Avoid unrelated global installations or environment changes. Use task-local or
+repository-scoped tools for testing changed runtime pins.
+For published packages, also validate tarballs and consumer installs with their
+documented supported package managers, including manifest/override syntax and
+runtime requirements. A successful owning-manager install does not prove that
+published metadata works for those consumers.
+
+Run the repository's setup/hooks, frozen installs, lint, typechecks, tests, builds,
+package/platform smoke checks, and relevant safe integration previews. Resolve
+upgrade-related deprecation warnings at their source. Do not suppress warnings,
+weaken tests, or disable checks; report remaining upstream/pre-existing warnings
+with evidence and keep a target pinned when migration cannot be completed.
+Add focused regression coverage when a migration changes behavior; avoid tests
+that merely assert version strings. Re-run checks after repairs. Report checks
+blocked by missing credentials, platforms, or external services accurately.
+Re-audit the final resolved graph after migrations and repairs.
+
+Confirm every inventory row is upgraded, already current, intentionally constrained,
+or skipped with a concrete reason. Do not present an unresolved group as complete.
+When upgrading agent-tool itself, install its managed skills with the same harness
+scope and commit the ownership manifest; never edit generated managed skill copies.
+
+When changes depend on another repository's release, ship the producer first and
+confirm publishing and registry availability before pinning the consumer; include
+its exact version/commit and API migration notes. Independent groups may proceed.
+Use the installed `ship-pr` for authorized shipping and independently review every
+changed HEAD. Check deployment safety again before its push/open/merge operations.
+
+## Report
+
+Keep a compact ledger of old/selected versions, completed migrations, validation
+and warning results, preview environment/commit/tool versions and safe action
+summary, and every skipped/constrained dependency with the reason. Include baseline
+and final audit results, security overrides with their rationale and removal
+condition, unresolved advisories, and audit coverage limits. For shipping,
+include branch, reviewed commit/verdict, PR, merge, publish/deploy result, and final
+checkout state. For a repository sweep, keep one entry per repository, including
+unready or unchanged checkouts. Do not publish credentials, state, or plan contents.

package/src/cli.ts

@@ -1,8 +1,9 @@
 import { execFileSync } from "node:child_process";
-import { writeFileSync, writeSync } from "node:fs";
+import { readFileSync, writeFileSync, writeSync } from "node:fs";
 import path from "node:path";
 import { DEFAULT_CONFIG, loadConfig } from "./config";
 import { doctor } from "./doctor";
+import { checkTerraformPlan } from "./dependencies/terraformPlan";
 import { review } from "./harnesses";
 import { runAgentToolAction } from "./runAgentToolAction";
 import { BUNDLED_SKILLS } from "./skills/bundled";
@@ -23,6 +24,7 @@ Usage: agent-tool [--repo <directory>] [--config <file>] <command>
   pr merge <subject-or-empty> <head-oid> <base-branch>
   versions <plan|bump|check|prepare> <base-oid>
   versions resolve-conflicts
+  dependencies check-terraform-plan <json-file>  Read-only destructive-plan check
   skills list
   skills install [--harness <all|claude|codex|opencode>] [--apply]
   skills check [--harness <all|claude|codex|opencode>]
@@ -58,6 +60,14 @@ export function main(argv = process.argv.slice(2)): number {
     writeSync(1, HELP); return 0;
   }
   if (command === "--version") { usage(args.length === 0, "Unexpected version arguments."); writeSync(1, `${metadata.version}\n`); return 0; }
+  if (command === "dependencies") {
+    usage(args.length === 2 && args[0] === "check-terraform-plan", "Usage: agent-tool dependencies check-terraform-plan <json-file>");
+    const source = readFileSync(args[1], "utf8");
+    let plan: unknown;
+    try { plan = JSON.parse(source); } catch { throw new Error("Invalid Terraform plan JSON."); }
+    const result = checkTerraformPlan(plan);
+    output(result); return result.ok ? 0 : 1;
+  }
   if (command === "init") {
     usage(args.length === 0, "Usage: agent-tool init");
     writeFileSync(path.join(process.cwd(), "agent-tool.json"), `${JSON.stringify(DEFAULT_CONFIG, null, 2)}\n`, { flag: "wx" });

package/src/dependencies/terraformPlan.ts

@@ -0,0 +1,69 @@
+/** Read-only screening of Terraform show -json output, not deployment approval. */
+export interface TerraformPlanCheck {
+  ok: boolean;
+  issues: string[];
+  resourceActions: { address: string; actions: string[] }[];
+}
+
+function record(value: unknown): value is Record<string, unknown> {
+  return value !== null && typeof value === "object" && !Array.isArray(value);
+}
+
+export function checkTerraformPlan(value: unknown): TerraformPlanCheck {
+  const issues: string[] = [];
+  const resourceActions: TerraformPlanCheck["resourceActions"] = [];
+  const result = () => ({ ok: issues.length === 0, issues, resourceActions });
+  if (!record(value)) {
+    issues.push("Expected a Terraform JSON plan object.");
+    return result();
+  }
+  if (typeof value.format_version !== "string" || !/^1\.\d+$/.test(value.format_version)) issues.push("Unsupported or missing plan format_version; expected 1.x.");
+  if (typeof value.terraform_version !== "string" || !value.terraform_version) issues.push("Missing terraform_version.");
+  if (!record(value.planned_values) || !record(value.configuration)) issues.push("Expected saved-plan planned_values and configuration; state JSON is not a plan.");
+  if (value.complete !== true) issues.push("Plan completeness is not established (complete must be true).");
+  if (value.errored !== undefined && value.errored !== false) issues.push("Planning errored or errored is malformed.");
+
+  for (const name of ["deferred_changes", "action_invocations", "deferred_action_invocations"]) {
+    if (value[name] !== undefined && (!Array.isArray(value[name]) || value[name].length !== 0)) issues.push(`${name} contains unsupported or incomplete operations.`);
+  }
+
+  // Missing resource_changes is valid for a complete empty/output-only plan.
+  for (const name of ["resource_changes", "resource_drift"]) {
+    const changes = value[name];
+    if (changes === undefined) continue;
+    if (!Array.isArray(changes)) { issues.push(`${name} must be an array.`); continue; }
+    for (const [index, item] of changes.entries()) {
+      const label = record(item) && typeof item.address === "string" && item.address ? item.address : `${name}[${index}]`;
+      if (!record(item) || typeof item.address !== "string" || !item.address || (item.mode !== "managed" && item.mode !== "data") || !record(item.change)) {
+        issues.push(`${label}: malformed resource change.`);
+        continue;
+      }
+      const actions = item.change.actions;
+      if (!Array.isArray(actions) || actions.length === 0 || !actions.every((action): action is string => typeof action === "string")) {
+        issues.push(`${label}: missing or malformed actions.`);
+        continue;
+      }
+      if (name === "resource_changes") resourceActions.push({ address: item.address, actions });
+      if (actions.includes("delete")) issues.push(`${label}: deletion or replacement is forbidden.`);
+      else if (actions.length !== 1 || !["no-op", "create", "read", "update"].includes(actions[0])) issues.push(`${label}: unsupported resource action.`);
+      if (item.change.replace_paths !== undefined && (!Array.isArray(item.change.replace_paths) || item.change.replace_paths.length !== 0)) issues.push(`${label}: replacement paths are forbidden or malformed.`);
+    }
+  }
+
+  const checks = value.checks;
+  if (checks !== undefined) {
+    if (!Array.isArray(checks)) issues.push("checks must be an array.");
+    else for (const [index, check] of checks.entries()) {
+      if (record(check) && check.status === "unknown") issues.push(`checks[${index}]: condition cannot be established before apply; skip this upgrade.`);
+      else if (!record(check) || check.status !== "pass") issues.push(`checks[${index}]: check did not pass or is malformed.`);
+      if (record(check) && check.instances !== undefined) {
+        if (!Array.isArray(check.instances)) issues.push(`checks[${index}]: instances must be an array.`);
+        else for (const instance of check.instances) {
+          if (record(instance) && instance.status === "unknown") issues.push(`checks[${index}]: instance condition cannot be established before apply; skip this upgrade.`);
+          else if (!record(instance) || instance.status !== "pass") issues.push(`checks[${index}]: instance check did not pass or is malformed.`);
+        }
+      }
+    }
+  }
+  return result();
+}

package/src/skills/bundled.ts

@@ -4,5 +4,6 @@ export const BUNDLED_SKILLS: Readonly<Record<string, string>> = {
   "open-pr": "---\nname: open-pr\ndescription: Open a GitHub pull request for the current feature branch with a validated title and a reviewable description.\n---\n\n# Open PR\n\nUse the installed `agent-tool`. Follow repository policy for validation, commits,\nand branch naming. Resolve the repository and default branch with Git and `gh`;\ndo not assume the branch is named main. Preserve unrelated work and finish\nrequested changes and appropriate checks before publishing them.\n\nEnsure the intended commit is on a feature branch and push it through the\nrepository's normal push workflow, naming the PR repository's remote and branch\nexplicitly, as in `git push -u origin HEAD`; a bare push follows whatever\nupstream the branch tracks, which may be a local branch. Respect existing push\nauthorization; do not bypass hooks. If the user only requested a draft\ndescription, prepare that text without publishing a PR.\n\nWrite a title that satisfies the data-only `agent-tool.json` subject policy.\nDescribe the concrete resulting behavior and relevant validation. Put multiline\nbody text in a temporary file, then run:\n\n```sh\nagent-tool pr open 'feat: describe the change' < /path/to/pr-body.txt\n```\n\nOmitting the title uses the latest commit subject. The tool refuses duplicate\nopen PRs and requires the branch to be pushed at its local HEAD. It does not\npush for you. Resolve a fork's head/base identities explicitly if the repository\nuses fork PRs; the initial open helper supports same-repository branches.\n\nReport the created PR link and any remaining validation or review work.\n",
   "reset": "---\nname: reset\ndescription: Return a clean checkout to its updated default branch after confirmed shipping or an explicit checkout cleanup request.\n---\n\n# Reset\n\nThis is checkout cleanup, not a destructive Git reset. Read repository guidance\nfor setup and hooks. Determine the default branch through the repository's\nremote metadata rather than assuming main.\n\nCheck worktree and index first. Preserve user edits; if they prevent switching,\nreport the condition instead of discarding or automatically stashing them. For\npost-merge cleanup, confirm the PR is MERGED before removing a feature branch.\n\nFetch the default branch, switch to it, and update by fast-forward only. A\ndiverged default branch requires inspection rather than forced replacement.\nDelete a merged feature branch only within the requested cleanup scope and\nafter verifying its exact commit is the shipped commit; squash merging does not\nmake Git ancestry-based branch deletion proof of shipping. Honor keep-branch.\n\nRun only the hook installer or dependency setup documented by this repository\nwhen the updated checkout requires it. Do not assume a package manager or copy\nsetup commands from another project. Report final branch, commit, and any\nunfinished cleanup.\n",
   "ship-pr": "---\nname: ship-pr\ndescription: Complete an authorized commit, independent review, repair, PR, CI, and squash-merge workflow for a GitHub repository.\n---\n\n# Ship PR\n\nUse the installed `agent-tool`. Read repository guidance and policy first;\nvalidation, versioning, package management, and hook installation remain project\nconcerns. Shipping authorizes this workflow within the user's stated scope.\nPreserve unrelated edits and honor requested stopping points such as open-PR\nonly, report-only review, or keeping the feature branch.\n\n1. Finish the requested change on a feature branch. Create it with\n   `git switch --no-track -c <branch>`; settings such as\n   `branch.autosetupmerge=always` otherwise make it track a local branch.\n   Validate it with appropriate project checks and commit only the intended\n   files.\n2. Determine the current PR's base repository and branch, or the repository's\n   default branch when no PR exists. Fetch and pin its exact base. Integrate it\n   using the repository's normal workflow, resolving conflicts without losing\n   user work. If project policy versions packages, prepare versions against the\n   pinned base after every integration or repair and before each review, using\n   the project's commands or `agent-tool versions prepare <base-oid>`, which\n   commits bumped manifests and the refreshed lockfile.\n   `agent-tool versions resolve-conflicts` resolves conflicts confined to\n   version fields. Review the resulting committed HEAD with an independent\n   reviewer using the bundled cross-agent-review skill. Repair blocking findings\n   and review every changed HEAD again. Review failure blocks shipping.\n3. Push the reviewed HEAD through normal hooks, then verify the pushed SHA still\n   equals the reviewed SHA. If a hook changed content or HEAD, review that result.\n   Open the PR using the open-pr skill, or update the existing PR as needed.\n4. Allow any configured review bots time to respond, then fetch unresolved PR\n   review threads. Follow repository policy for feedback: fix valid findings,\n   reply in the original threads, and resolve only fully addressed comments.\n   Validate, commit, push, and independently review every feedback or CI repair.\n   Wait for CI, recheck the live base, PR base branch, and local and remote heads.\n   A changed base requires integration, validation, and another review. When\n   versions are managed, `agent-tool versions check <base-oid>` must pass for the\n   live base. Use the squash-merge skill to merge the exact reviewed HEAD.\n5. After confirmed MERGED, honor keep-branch; otherwise use the reset skill to\n   return to the updated default branch and apply any documented project setup.\n6. When the project deploys the merged branch, verify the deployment for the\n   merge commit and run its documented live checks. Report deployment failures\n   separately from a successful merge; follow project policy for repairs.\n\nNever infer a clean review from process success alone or carry a review across\ncontent changes. Do not weaken configured CI policy to get a merge through.\nIf a step fails, preserve useful intermediate work and report the concrete\nremaining issue. Report PR link, merged commit, review verdict, validation, and\nfinal checkout state.\n",
-  "squash-merge": "---\nname: squash-merge\ndescription: Squash-merge a reviewed GitHub pull request while binding the mutation to the reviewed commit and checking CI.\n---\n\n# Squash Merge\n\nUse the installed `agent-tool` and repository merge policy. Merge only within\nthe user's authorized scope. Have the exact reviewed HEAD, base commit, and base\nbranch available, and read the verdict and unresolved findings. BLOCKER or MAJOR\nfindings require repair and a new review before merging.\nFollow the repository's review-bot policy and require all actionable blocking\nreview feedback to be addressed before merging.\n\nWait for required checks using `gh pr checks --watch --fail-fast`. Refresh the\nPR and live base from the repository that owns the PR. Confirm local HEAD and PR\nHEAD both equal the reviewed commit, the base branch is unchanged, the live base\nstill equals the reviewed base, and that base is an ancestor of reviewed HEAD.\nIf any identity changed, refresh, validate, and review again.\n\nUse a title that satisfies `agent-tool.json` and pass both reviewed HEAD and\nbase branch:\n\n```sh\nagent-tool pr merge 'feat: describe the change' <reviewed-head-oid> <base-branch>\n```\n\nThe helper enforces HEAD atomically through GitHub's `expectedHeadOid`, checks\nCI, rejects queued or automatic merges, and creates a subject-only squash with\nthe PR reference. GitHub has no atomic expected-base argument in this mutation;\nrepository branch protection must enforce any required base freshness. With\n`merge.requireStrictBaseFreshness`, the helper refuses to merge unless an\nactive strict status ruleset that the actor cannot bypass protects the base. Do\nnot retarget the PR concurrently with merging.\n\nConfirm GitHub reports MERGED before any cleanup. A failed or uncertain mutation\nis not evidence of a merge. Preserve the branch on failure. After a confirmed\nmerge, perform checkout cleanup only when requested or as part of an authorized\nshipping workflow. Report the PR and merge result.\n"
+  "squash-merge": "---\nname: squash-merge\ndescription: Squash-merge a reviewed GitHub pull request while binding the mutation to the reviewed commit and checking CI.\n---\n\n# Squash Merge\n\nUse the installed `agent-tool` and repository merge policy. Merge only within\nthe user's authorized scope. Have the exact reviewed HEAD, base commit, and base\nbranch available, and read the verdict and unresolved findings. BLOCKER or MAJOR\nfindings require repair and a new review before merging.\nFollow the repository's review-bot policy and require all actionable blocking\nreview feedback to be addressed before merging.\n\nWait for required checks using `gh pr checks --watch --fail-fast`. Refresh the\nPR and live base from the repository that owns the PR. Confirm local HEAD and PR\nHEAD both equal the reviewed commit, the base branch is unchanged, the live base\nstill equals the reviewed base, and that base is an ancestor of reviewed HEAD.\nIf any identity changed, refresh, validate, and review again.\n\nUse a title that satisfies `agent-tool.json` and pass both reviewed HEAD and\nbase branch:\n\n```sh\nagent-tool pr merge 'feat: describe the change' <reviewed-head-oid> <base-branch>\n```\n\nThe helper enforces HEAD atomically through GitHub's `expectedHeadOid`, checks\nCI, rejects queued or automatic merges, and creates a subject-only squash with\nthe PR reference. GitHub has no atomic expected-base argument in this mutation;\nrepository branch protection must enforce any required base freshness. With\n`merge.requireStrictBaseFreshness`, the helper refuses to merge unless an\nactive strict status ruleset that the actor cannot bypass protects the base. Do\nnot retarget the PR concurrently with merging.\n\nConfirm GitHub reports MERGED before any cleanup. A failed or uncertain mutation\nis not evidence of a merge. Preserve the branch on failure. After a confirmed\nmerge, perform checkout cleanup only when requested or as part of an authorized\nshipping workflow. Report the PR and merge result.\n",
+  "update-dependencies": "---\nname: update-dependencies\ndescription: Update a repository's dependency manifests, lockfiles, runtimes, tools, and CI pins with upstream migrations, compatibility checks, and non-destructive infrastructure previews.\n---\n\n# Update Dependencies\n\nUse the repository's package managers and installed `agent-tool`. Read `AGENTS.md`,\nREADME, linked setup/release documents, and repository-owned upgrade skills before\nediting. Follow their hooks, version policy, checks, and requested stopping point.\nUpdate applicable dependencies throughout the repository, including workspaces\nand examples. This skill does not authorize deploying, merging, publishing, or\nchanging global tools; use existing user authorization and `ship-pr` when shipping\nis requested. Default dependency-update merge subject: `chore: update dependencies`,\nsubject to repository title policy and any explicit user subject.\n\n## Safety before execution\n\n**Always dry-run before any infrastructure apply or deployment. Never destroy,\nreplace, or recreate a resource during an upgrade.** This includes Terraform,\nOpenTofu, Wrangler, Ansible, other infrastructure tools, and effects triggered by\ninstallation, tests, hooks, Git push, opening a PR, CI, or merging. Greenfield\nprojects and approval to ship do not waive this rule.\n\nBefore running project commands or pushing, trace their scripts, hooks, workflow\ntriggers, reusable workflows, and deployment commands. A dry-run flag alone is\ninsufficient: inspect tasks, provisioners, plugins, external programs, and actions\nthat can mutate despite preview mode. Avoid such a preview unless its effects\nare proven read-only. Do not run destroy/delete, taint/replace, state removal,\nbackend migration, forced database reset, or an automatic \"repair\" that bypasses\nthe rule. Do not hide destruction with targeting, disabled refresh, ignored\nchanges, new resource identities, or weakened policy.\n\nPreview with the proposed versions and complete configuration for each affected\nenvironment, using its real backend/workspace/account, variables, inventory, and\nresource identities. An empty local state, mocked credentials, validate-only run,\nor bundle build cannot establish safety for production. Check the current baseline\nas well when needed to distinguish existing drift from the upgrade. Keep state,\nbinary plans, JSON plans, and secret-bearing diffs out of Git and public reports.\n\nIf a preview proposes deletion or replacement, fails, is incomplete, omits\naffected resources, or cannot establish safety, skip that dependency and its\ncoupled migrations. Restore only this task's edits to the affected compatibility\ngroup, retain independent safe upgrades, and record the reason and affected\nresources. Never apply to find out. A preview is not deployment authorization.\n\nBefore an authorized apply/deploy, verify the exact validated commit, toolchain,\nconfiguration, environment, and current state still match the preview. Re-preview\nafter relevant changes or drift. CI must enforce the same order and stop on an\nunsafe preview before mutation; a successful local preview does not excuse an\nunguarded push- or merge-triggered deployment. Establish a narrowly scoped guard\nwhen authorized and reviewable, or hold the affected upgrade before triggering\nthat workflow. Do not disable protections to ship. A plan must be inspected before\nthe operation; inspecting deployment logs afterward is too late.\nAn unsafe workflow triggered on every branch push also blocks pushing otherwise\nindependent upgrades until that trigger has a proven safe guard.\n\n### Terraform and OpenTofu\n\nRead core, provider, and module upgrade guides, including intermediate major\nmigrations. Regenerate provider locks with the pinned CLI, preserving supported\nplatform hashes. Backend initialization/migration is also subject to the safety\ngate. Inspect external data programs and provisioners before planning.\n\nUse a full refreshed saved plan with locking and the real variables, for example\n`terraform plan -input=false -out=<private-plan>`; if using `-detailed-exitcode`,\n0 and 2 are success, 1 is failure. Inspect `terraform show -json <private-plan>`.\nRun `agent-tool dependencies check-terraform-plan <private-plan.json>` to check\nsupported JSON resource actions. It fails for every action containing `delete`,\nincluding both replacement orders, unknown actions, incomplete/deferred plans,\nfailed checks, or opaque provider action invocations. It prints actions and\ndiagnostics without resource attribute values; it does not prove that a plan is\nfresh, comprehensive, authentic, or that provider code has no hidden effects.\nOlder/unsupported plan formats that cannot establish completeness are skipped.\nOpenTofu currently omits `complete` in its JSON format and is rejected by this\nhelper; report that limitation rather than adding a synthetic completeness flag.\nAlso inspect resource identity, drift, warnings, provider semantics, and any\neffects outside resource actions. For an authorized apply, consume the exact\napproved saved plan, not an uninspected newly generated plan.\n\nSource: [Terraform JSON plan format](https://developer.hashicorp.com/terraform/internals/json-format).\n\n### Wrangler and other deployment tools\n\nUse the proposed pinned Wrangler for `wrangler deploy --dry-run` with the same\nbuild/configuration/environment used by deployment. This checks bundling, not a\ncomplete remote resource plan. Separately verify account, worker name, routes,\nbindings and resource IDs against the existing deployment and read migration\nsemantics. Review Durable Object deleted/renamed classes, D1 schema/data\nmigrations, storage resources, queues, containers, and deployment integrations.\nNever infer \"no destruction\" from a successful bundle. Resource removals,\nreplacement, or unprovable remote effects skip the affected group. Apply the\nequivalent preview and identity checks to other tools rather than assuming they\nshare Terraform's guarantees.\n\nSource: [Wrangler command documentation](https://developers.cloudflare.com/workers/wrangler/commands/).\n\n### Ansible\n\nCheck controller Python, ansible-core, collections/roles, and target Python support\ntogether; read porting guides. Inspect all tasks and invoked scripts before\n`ansible-playbook --check --diff` with the real inventory and variables.\n`check_mode: false` forces mutation even with `--check`; unsupported modules and\nconditions based on registered results can omit effects. Inspect deletion,\nrecreation, service/data reset, and package removal semantics beyond the diff.\nSkipped or opaque tasks are a safety gap, not a clean preview. Redact diffs.\n\nSource: [Ansible check mode limits](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_checkmode.html).\n\n## Inventory and choose compatible targets\n\nRecord each dependency source, current resolved version, latest stable candidate,\nselected target, compatibility constraints, upstream migration links, and checks.\nQuery authoritative registries, official releases, support matrices, and migration\nguides at execution time; do not treat remembered versions or prereleases as\nlatest stable. Inspect runtime requirements, peer dependencies, ABI/API changes,\nplatform availability, maintained release lines, and changed defaults, including\nsecurity, privacy/telemetry, data retention, and postinstall/native behavior.\nCheck transitive dependencies' peer/runtime constraints as well as direct ones. Unsupported\nor unpublished targets stay pinned with an explanation.\n\nInventory manifests, locks, tool configuration, CI/reusable actions, containers,\nscripts, deployment files, and executable documentation. Search duplicate version\npins and aliases, not just filenames; exclude vendored/generated snapshots unless\nthe repository owns their update process. Examples of sources to inspect:\n\n| Ecosystem | Sources and compatibility group |\n| --- | --- |\n| JavaScript/TypeScript | All package.json dependency fields, overrides/resolutions, workspace catalogs, packageManager/engines, npm/Bun/pnpm/Yarn locks, Node/Bun pins, compiler and lint/build/test plugins |\n| Toolchains | mise.toml/.mise.toml, mise.lock, .tool-versions, runtime version files, tool URLs/checksums, CI pins and container images; include every tool declared by mise, not just mise itself |\n| Python/Ansible | pyproject/requirements, uv/Poetry/pip locks, Python pins, ansible-core, collection/role requirements, lint plugins and managed host constraints |\n| Ruby/iOS | .ruby-version, Gemfile/lock, Bundler, CocoaPods, Podfile/lock, podspecs, Swift packages and Xcode/iOS deployment requirements |\n| Infrastructure | Terraform/OpenTofu CLI constraints, provider locks/constraints, module versions/Git refs, Wrangler and Cloudflare integration dependencies |\n| CI/system/native | Actions/reusable workflow refs, Docker tags/digests, OS images/packages, Rust/Cargo toolchain and locks, Go modules, Gradle/AGP/Kotlin/JDK and other repository-specific manifests |\n\nBuild connected compatibility groups before editing. Select the newest supported\ncombination, which can be older than an individual package's latest. Upgrade the\nframework first or keep its compatible toolchain pinned; do not force peer\nresolution, drop compatibility checks, or add blanket overrides to make installs\npass. Preserve source pin policy (exact version, digest, full Git SHA) and resolve\nimmutable pins from verified upstream releases. Preserve intentional runtime\nminimums unless migration requires changing the support contract.\n\nFor React Native, use its version-specific upgrade guide/template diffs and\nrepository upgrade skills. Couple React and its renderer, native modules,\nMetro/Babel, CLI, codegen, Hermes/New Architecture, CocoaPods/Bundler/Ruby,\nXcode/iOS deployment targets, and Android Gradle/AGP/Kotlin/JDK/SDK/NDK. For Expo,\nuse the chosen SDK's supported React Native/dependency matrix and its dependency\nchecks. Do not independently update framework-managed pods or generated native\nfiles; use the framework's regeneration workflow and prove iOS/Android builds.\nPermissive peer ranges alone do not prove native renderer or toolchain compatibility;\ncheck the framework's actual supported versions and native implementation.\nAn unavailable native toolchain is a reported validation limit; do not claim the\ngroup verified. See [React Native upgrading](https://reactnative.dev/docs/upgrading).\n\nCheck developer tools' own dependencies too: a compiler release without its old\nprogrammatic API may break test/lint runners that import it even when `tsc` passes.\nAction runtime upgrades can require newer self-hosted runners; preserve workflow\npermissions, action inputs/outputs, caching, artifact semantics, and job names.\n\nCheck current advisories with read-only ecosystem audits against the baseline and\nproposed lockfiles, using the repository's configured registry/advisory sources.\nDo not send private dependency metadata to an unconfigured or unauthorized service;\nreport the resulting coverage limit. Cover direct and resolved transitive dependencies,\nincluding native/platform-specific binaries. Latest direct packages can still\npin vulnerable transitive versions. Trace each finding to its owning dependency,\nverify affected versions, runtime conditions, and remediation in the maintainer's\nadvisory and fixed release. When the owner's range permits a fixed version, use a\ntargeted refresh with the lockfile's owning manager and preserve unrelated\nresolutions; otherwise prefer a supported owner upgrade.\nIf the owner still pins a vulnerable version, a narrowly scoped security patch\noverride may be used only with API/ABI/runtime compatibility evidence and focused\nregression checks of the actual affected integration. Document its rationale and\nremoval condition; a passing install or bundle alone is insufficient. Do not run\nblind audit fixes or use blanket overrides to bypass compatibility constraints.\nReport unresolved advisories and unavailable audit coverage accurately; current\ndirect pins or a partial clean audit do not\nestablish that the whole dependency graph is safe.\n\n## Migrate and validate\n\nCapture relevant baseline checks and warnings first, after screening their side\neffects. Update one compatibility group at a time. Read the upstream instructions\nfor every breaking step; implement required source/config/schema migrations and\nremoved API replacements. Use the manager that owns each lockfile, on the selected\nruntime, and inspect the resulting diff. Refresh transitive dependencies through\ntheir owning direct dependency; do not hand-edit integrity hashes or lock entries.\nReview intentional patches, overrides, and pins before removal; retain them until\nupstream fixes and regression checks demonstrate they are unnecessary.\nAvoid unrelated global installations or environment changes. Use task-local or\nrepository-scoped tools for testing changed runtime pins.\nFor published packages, also validate tarballs and consumer installs with their\ndocumented supported package managers, including manifest/override syntax and\nruntime requirements. A successful owning-manager install does not prove that\npublished metadata works for those consumers.\n\nRun the repository's setup/hooks, frozen installs, lint, typechecks, tests, builds,\npackage/platform smoke checks, and relevant safe integration previews. Resolve\nupgrade-related deprecation warnings at their source. Do not suppress warnings,\nweaken tests, or disable checks; report remaining upstream/pre-existing warnings\nwith evidence and keep a target pinned when migration cannot be completed.\nAdd focused regression coverage when a migration changes behavior; avoid tests\nthat merely assert version strings. Re-run checks after repairs. Report checks\nblocked by missing credentials, platforms, or external services accurately.\nRe-audit the final resolved graph after migrations and repairs.\n\nConfirm every inventory row is upgraded, already current, intentionally constrained,\nor skipped with a concrete reason. Do not present an unresolved group as complete.\nWhen upgrading agent-tool itself, install its managed skills with the same harness\nscope and commit the ownership manifest; never edit generated managed skill copies.\n\nWhen changes depend on another repository's release, ship the producer first and\nconfirm publishing and registry availability before pinning the consumer; include\nits exact version/commit and API migration notes. Independent groups may proceed.\nUse the installed `ship-pr` for authorized shipping and independently review every\nchanged HEAD. Check deployment safety again before its push/open/merge operations.\n\n## Report\n\nKeep a compact ledger of old/selected versions, completed migrations, validation\nand warning results, preview environment/commit/tool versions and safe action\nsummary, and every skipped/constrained dependency with the reason. Include baseline\nand final audit results, security overrides with their rationale and removal\ncondition, unresolved advisories, and audit coverage limits. For shipping,\ninclude branch, reviewed commit/verdict, PR, merge, publish/deploy result, and final\ncheckout state. For a repository sweep, keep one entry per repository, including\nunready or unchanged checkouts. Do not publish credentials, state, or plan contents.\n"
 };