build: update agent skills

.agents/skills/apm-workflow/SKILL.md

@@ -61,6 +61,38 @@ hashes, and review for every changed third-party dependency.
 10. Treat the CLI and agent dependencies as supply-chain-sensitive code. Check the
    repository policy and any organization policy before proceeding.
 
+### 1.1 Regenerate a lockfile without losing deployment ownership
+
+When a CLI migration or ledger repair requires deleting and rebuilding the lockfile,
+preserve the old lockfile's ownership evidence before removing it. Generated target
+files can remain on disk after the ledger is gone; a new resolver may then classify
+them as unmanaged local content, skip the collision, and silently omit a requested
+Skill or resource from the new lockfile.
+
+1. From the old lockfile, record the selected packages and Skill subsets, deployment
+   owners, deployed paths, content hashes, target roots, and generator version. Compare
+   this snapshot with `apm.yml` and the filesystem before changing anything.
+2. Identify collisions in the actual target root. Distinguish paths owned by the old
+   APM ledger from project-authored Skills, files owned by another package, and unknown
+   local content. Never move or delete a path whose ownership is ambiguous.
+3. Before removing the old lockfile, move only the exact, verified APM-owned generated
+   collision paths to a task-specific temporary backup outside the repository. Preserve
+   relative paths and hashes so the old deployment can be restored. Do not use
+   `--force` to overwrite a collision or clear the entire agent target.
+4. Remove only the validated project lockfile, regenerate it with the selected CLI, and
+   run the frozen install. A skipped-file or collision warning is a blocker, even when
+   the command exits successfully.
+5. Compare the new package list, requested Skill subsets, deployed paths, and target
+   roots with the manifest and the old snapshot. Every removed or added path needs an
+   expected dependency or generator explanation; an unexpectedly missing selected
+   Skill is lock-generation failure.
+6. Run `apm audit --ci` and directly verify representative restored files and hashes.
+   If regeneration, installation, comparison, or audit fails, restore the old lockfile
+   and backed-up paths instead of accepting a partial deployment.
+7. Delete the temporary backup only after the new lockfile, deployed output, diff, and
+   audit all pass. Record any ownership ambiguity or tool collision behavior in the
+   handoff.
+
 ## 2. Obtain the selected eligible APM version safely
 
 Reuse an installed copy only when its exact version matches the selected

.agents/skills/docker-quality-check/SKILL.md

@@ -3,31 +3,38 @@ name: docker-quality-check
 description: >-
   Quality-check Dockerfiles, Compose configurations, container startup scripts,
   image CI, and container documentation. Use when creating, editing, or reviewing
-  container build, runtime, orchestration, or publication changes.
+  container build, runtime, orchestration, publication, or explicitly authorized
+  registry image deletion changes.
 ---
 
 # Docker Quality Check
 
 ## When to Use
 
 - Use for changes to Dockerfiles, Compose files, container entrypoints, image build
-  automation, or container-facing documentation.
+  automation, registry publication or deletion, or container-facing documentation.
 - Use before committing or publishing container changes.
 
 ## Goals
 
 - Keep container builds reproducible, minimal, and suitable for the intended runtime.
 - Validate both Dockerfile syntax and the changed build or Compose behavior.
 - Make third-party images, downloaded tools, and CI actions traceable and reviewable.
+- Keep notices for software distributed in the image visible and distinct from
+  development-only dependency notices.
 
 ## Workflow
 
 1. Read the changed container files and repository guidance. Identify the build targets,
    runtime user, exposed services, mounted paths, environment variables, and expected
    startup behavior.
 2. Run the repository's documented container checks. When no project-specific command
-   exists, use `hadolint` for each changed Dockerfile and `docker compose config` for
-   each changed Compose configuration.
+   exists, use the Dockerfile frontend's official build checks (`docker buildx build
+   --check`) for each changed Dockerfile and `docker compose config` for each changed
+   Compose configuration. Pass the same context, file, target, platform, and build
+   arguments as the affected build contract. Treat hadolint as an optional additive
+   check only when the repository intentionally relies on its ShellCheck or package
+   policy rules and the selected hadolint parser supports the Dockerfile syntax.
 3. Build the affected image or target with `docker build` or `docker compose build`.
    Pass only the build arguments and secrets required by the documented build contract;
    never place credentials in image layers, build logs, or committed configuration.
@@ -37,7 +44,16 @@ description: >-
 5. Inspect image and runtime safety: use a non-root user where feasible, keep the final
    image free of build-only tooling and secrets, define a clear entrypoint, and avoid
    mutable base-image tags when an immutable digest is practical.
-6. For newly introduced or updated external images, downloaded executables, or GitHub
+6. Inventory third-party software copied, installed, linked, or otherwise distributed in
+   the final image. Put notices for the primary bundled application and other shipped
+   runtime content at the top of `THIRD_PARTY_NOTICES.md`, before build tools, CI Actions,
+   Agent Skills, or other development-only dependencies. For each primary bundled
+   application, record its source, bundled location, version source, and license. Verify
+   that required upstream license and notice files remain in the final image. Add a
+   README disclosure that names the application, version source, and license and links to
+   both `THIRD_PARTY_NOTICES.md` and upstream license information. Mark unavailable
+   version, license, or final-image evidence as unverified rather than inferring a pass.
+7. For newly introduced or updated external images, downloaded executables, or GitHub
    Actions, use `security-check` to assess provenance, version or digest pinning,
    release age, checksums, permissions, and runtime behavior. Pin GitHub Actions to
    full commit SHAs with accurate version comments. Use
@@ -46,24 +62,33 @@ description: >-
    `apm-workflow` and keep `apm audit --ci` in the outer source-check action.
    Keep Markdown source validation in that same action so container-only
    changes cannot bypass the repository documentation gate.
-7. Summarize commands run, build and smoke-test results, and every skipped check with a
+8. Summarize commands run, build and smoke-test results, and every skipped check with a
    concrete reason.
+9. For an explicitly authorized registry image deletion, follow
+   [registry-image-deletion.md](references/registry-image-deletion.md). Treat registry
+   state as the source of truth: resolve exact targets before mutation, account for
+   shared manifests and registry-specific deletion units, and verify retained and
+   removed references independently afterward. This procedure does not define a
+   retention policy or recommend when deletion should occur.
 
-## CI Tool Pinning
+## Dockerfile Check Selection
 
-When a workflow installs hadolint, pin both the release version and the SHA-256 of the
-exact platform asset. Download over HTTPS, verify the hash before making the file
-executable, and install it only into the runner's temporary directory. Before changing
-a pin, verify the official release provenance and the repository's required adoption
-cooldown. Use the bundled `check-docker-source` action when its single-Dockerfile contract fits.
+Prefer BuildKit build checks because they use the Dockerfile frontend selected by the
+repository and validate build options as well as the file. In GitHub Actions, use
+`docker/build-push-action` with `call: check`, or the equivalent
+`docker buildx build --check` command after setting up Buildx. A check invocation does
+not execute the image build, so keep a real build as a separate integrated-source gate.
 
-Replace the version and checksum together only after independently verifying the
-official release asset. Do not use a floating download URL or skip hash verification.
+Do not silently substitute hadolint when BuildKit checks are available. Hadolint parses
+the Dockerfile independently and can reject supported frontend syntax before its rules
+run. When a repository adds hadolint for complementary rules, document that purpose,
+verify syntax compatibility, and pin the version and exact asset SHA-256 under the
+repository's adoption policy.
 
 ## Default Checks
 
 ```shell
-hadolint Dockerfile
+docker buildx build --check .
 docker build -t local-validation .
 docker compose config
 ```
@@ -76,6 +101,7 @@ builds or starts correctly.
 
 Read [ci-template-contract.md](references/ci-template-contract.md) before creating or
 repairing Docker CI. The bundled files under `assets/github/` keep pull-request checks
-limited to lint and reserve image builds for the exact integrated main-branch commit.
+limited to source and BuildKit validation and reserve image builds for the exact integrated
+main-branch commit.
 Apply `github-actions-quality-check` for shared event, permission, runner, pinning, and
 repository-enforcement policy.

.agents/skills/docker-quality-check/agents/openai.yaml

@@ -1,6 +1,7 @@
 interface:
   display_name: "Docker Quality Check"
-  short_description: "Review container build and runtime changes."
+  short_description: "Review container lifecycle changes safely."
   default_prompt: >-
-    Use $docker-quality-check to review this Dockerfile, Compose, entrypoint, or
-    container CI change for build correctness, runtime safety, pinning, and validation.
+    Use $docker-quality-check to review this Dockerfile, Compose, entrypoint,
+    container CI, publication, or authorized registry deletion change for build
+    correctness, runtime safety, pinning, and validation.

.agents/skills/docker-quality-check/assets/github/actions/check-docker-source/action.yml

@@ -1,5 +1,5 @@
 name: Check Docker source
-description: Audit APM, lint Docker and Markdown source, and remove action-owned tools.
+description: Audit APM and lint Markdown source before Docker frontend checks.
 
 runs:
   using: composite
@@ -14,24 +14,8 @@ runs:
       shell: bash
       run: apm audit --ci
 
-    - name: Install checksum-verified hadolint
-      shell: bash
-      env:
-        HADOLINT_VERSION: v2.15.1
-        HADOLINT_SHA256: c7187db94eeeeca956519a6af171adc31453941a1e777961f6e680f697c8c507
-      run: bash "${{ github.action_path }}/install-hadolint.sh"
-
-    - name: Lint Dockerfile
-      shell: bash
-      run: hadolint Dockerfile
-
     - name: Lint Markdown source
       uses: DavidAnson/markdownlint-cli2-action@ce4853d43830c74c1753b39f3cf40f71c2031eb9 # v23.0.0
       with:
         config: .markdownlint-cli2.yaml
         globs: "**/*.md"
-
-    - name: Remove hadolint
-      if: always()
-      shell: bash
-      run: rm -rf -- "${RUNNER_TEMP}/hadolint"

.agents/skills/docker-quality-check/assets/github/workflows/main.yml

@@ -15,9 +15,8 @@ concurrency:
 jobs:
   check:
     name: Check
-    # Keep the lightweight gate independent from Docker daemon requirements.
-    runs-on: ubuntu-slim
-    timeout-minutes: 5
+    runs-on: ubuntu-24.04
+    timeout-minutes: 10
 
     steps:
       - name: Checkout integrated source
@@ -28,6 +27,16 @@ jobs:
       - name: Lint Docker source
         uses: ./.github/actions/check-docker-source
 
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0
+
+      - name: Check Docker build configuration
+        uses: docker/build-push-action@53b7df96c91f9c12dcc8a07bcb9ccacbed38856a # v7.3.0
+        with:
+          call: check
+          context: .
+          file: ./Dockerfile
+
   build:
     name: Build
     needs:

.agents/skills/docker-quality-check/assets/github/workflows/pull-request.yml

@@ -18,9 +18,8 @@ concurrency:
 jobs:
   check:
     name: Check
-    # Avoid a network-intensive image build for proposed source.
-    runs-on: ubuntu-slim
-    timeout-minutes: 5
+    runs-on: ubuntu-24.04
+    timeout-minutes: 10
 
     steps:
       - name: Checkout proposed source
@@ -30,3 +29,13 @@ jobs:
 
       - name: Lint Docker source
         uses: ./.github/actions/check-docker-source
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0
+
+      - name: Check Docker build configuration
+        uses: docker/build-push-action@53b7df96c91f9c12dcc8a07bcb9ccacbed38856a # v7.3.0
+        with:
+          call: check
+          context: .
+          file: ./Dockerfile

.agents/skills/docker-quality-check/references/ci-template-contract.md

@@ -2,34 +2,36 @@
 
 ## Purpose
 
-Use the bundled baseline for a repository with one root `Dockerfile`. It keeps proposed-source
-checks fast by running hadolint only. The integrated main-branch workflow repeats lint and then
-builds the exact merged commit without publishing it.
+Use the bundled baseline for a repository with one root `Dockerfile`. Proposed-source checks use
+the official Dockerfile frontend without executing a build. The integrated main-branch workflow
+repeats the check and then builds the exact merged commit without publishing it.
 
 ## Files
 
 | Skill asset | Consumer path | Contract |
 | --- | --- | --- |
-| `assets/github/actions/check-docker-source/action.yml` | `.github/actions/check-docker-source/action.yml` | Install checksum-verified hadolint and lint the root `Dockerfile`. |
-| `assets/github/workflows/pull-request.yml` | `.github/workflows/pull-request.yml` | Lint pull-request and merge-queue source; cancel superseded runs. |
-| `assets/github/workflows/main.yml` | `.github/workflows/main.yml` | Re-run lint and build the integrated commit; never cancel it. |
+| `assets/github/actions/check-docker-source/action.yml` | `.github/actions/check-docker-source/action.yml` | Audit APM and lint Markdown independently from Docker setup. |
+| `assets/github/workflows/pull-request.yml` | `.github/workflows/pull-request.yml` | Run BuildKit checks for pull-request and merge-queue source; cancel superseded runs. |
+| `assets/github/workflows/main.yml` | `.github/workflows/main.yml` | Re-run BuildKit checks and build the integrated commit; never cancel it. |
 
 Copy the files into the consumer repository. Consumer workflows must run committed
 repository-owned files and must not execute the installed Skill at runtime.
 
 ## Allowed substitutions
 
 - Replace `main` only with the confirmed protected integration branch.
-- Replace the root Dockerfile path or add a lint matrix when the repository owns multiple
+- Replace the root Dockerfile path or add a check matrix when the repository owns multiple
   Dockerfiles.
 - Pass repository-evidenced build contexts, Dockerfile paths, targets, build arguments, secrets,
   or cache settings to the integrated build.
 - Add Compose validation, tests, or smoke checks when the repository documents those contracts.
 - Add registry authentication and publication only in an integration job with the minimum required
   permissions and secrets.
 - Make an immutable release depend directly on the published image and every required image test.
-- Update external Action pins or the hadolint version and checksum only after `security-check`
-  verifies provenance, runtime behavior, exact identity, and cooldown eligibility.
+- Add hadolint only for documented complementary rules after verifying that it supports the
+  selected Dockerfile frontend syntax. Apply `security-check` to its version and asset checksum.
+- Update external Action pins only after `security-check` verifies provenance, runtime behavior,
+  exact identity, and cooldown eligibility.
 
 Do not add Docker build or publication to the pull-request workflow merely to mirror main. Do not
 expose registry credentials to proposed source, rebuild an image in a release job, or create a
@@ -40,7 +42,7 @@ release before the published image passes its required tests.
 1. Inventory existing workflow responsibilities and retire only duplicated entry workflows.
 2. Apply `github-actions-quality-check` and preserve its event, permission, concurrency, runner,
    and immutable-pin requirements.
-3. Run hadolint locally against every selected Dockerfile.
+3. Run `docker buildx build --check` locally with the selected build contract.
 4. Run actionlint across workflows and actions, ShellCheck against changed standalone shell
    scripts, and `pinact run --check --min-age 7`.
 5. Observe the Checks job on a pull request and both Checks and Build jobs on the integrated commit