abyss-safe-infra-change

# abyss-safe-infra-change

## Intent
Use this skill to adapt `aoa-safe-infra-change` to an `abyss-*` repository when the base operational workflow is correct but the local repo still needs repo-relative commands, authority notes, and risk framing.

## Trigger boundary
Use this skill when:
- the base `aoa-safe-infra-change` workflow is already correct, but an `abyss-*` repo needs repo-relative operational surfaces, commands, or approval notes
- the task is a bounded infrastructure, service, configuration, or operational change inside one local repo family
- the local surface is repo-owned operational material such as a compose file, service wrapper, env or config template, bootstrap script, deployment toggle, restart rule, runtime check, or generated operational receipt
- explicit local authority, rollback posture, or verification commands still need to be named before execution
- the change needs a local preflight, preview, stop line, or recovery anchor matched to the touched surface rather than a generic safety claim
- the family review doc and bundle-local checklist still need to stay aligned

Do not use this skill when:
- the task is really about producing a shareable public-safe artifact rather than the operational change itself; use `abyss-sanitized-share`
- no `abyss-*` repo adaptation is needed and the base `aoa-safe-infra-change` skill is sufficient
- the overlay would only restate the base workflow without adding a real local surface
- the main question is whether authority exists at all; use `aoa-approval-gate-check`
- the main need is to prefer or interpret a preview path before execution; use `aoa-dry-run-first`
- the touched surface belongs to a stronger owner repo, host-level service, secret plane, or deployment environment that has not been explicitly confirmed for this change
- the work would widen into broader project doctrine instead of a thin local overlay

## Inputs
- target operational change and touched local surface
- repo-relative operational files, commands, generated receipts, or runtime check paths
- surface class, side-effect class, and expected blast radius
- explicit local authority, approval posture, and stop condition
- preflight or preview path when one exists
- validation path and rollback or recovery anchor
- sensitivity notes for raw logs, host details, secrets, or unpublished runtime data
- base skill reference

## Outputs
- bounded local infra-change plan
- repo-relative command, path, or receipt sketch
- explicit local authority, approval, stop-line, and rollback note
- surface-specific verification plan with the smallest honest proof
- note about any material that must be sanitized before sharing
- pointer to the family review surface
- concise verification note for the local repo surface

## Procedure
1. start from `aoa-safe-infra-change` instead of inventing a new project-family workflow
2. read the nearest repo route card before treating a path as locally owned
3. classify the touched surface: source config, generated operational receipt, runtime wrapper, launch command, environment template, deployment toggle, or verification script
4. name the side effect, authority posture, stop condition, and rollback or recovery anchor before proposing execution
5. choose the smallest local preflight or preview that can prove the change shape without performing a stronger mutation
6. keep commands and paths repo-relative unless the operator explicitly authorizes a host or environment path
7. preserve the base risk framing, rollback thinking, and explicit verification posture
8. make explicit what still requires downstream human approval or repo-specific judgment

## Contracts
- preserve the base skill meaning
- keep paths and commands repo-relative
- keep local authority explicit
- keep host paths, secrets, credentials, and unpublished operational details out of shareable notes unless separately sanitized
- do not convert a generated receipt or runtime artifact into source authority
- keep the overlay explicit-only, public-safe, and reviewable

## Risks and anti-patterns
- hiding downstream authority inside vague local operational notes
- turning a thin overlay into project doctrine or a scenario bundle
- naming repo-relative commands without enough verification or rollback context
- treating a dry-run, generated receipt, or log sample as proof of a live mutation that did not happen
- using an `abyss-*` label to claim authority over a sibling owner or host-level surface
- copying raw runtime data into a review note when `abyss-sanitized-share` is the correct next step
- silently changing the base workflow instead of adapting the local repo surface

## Verification
- confirm the base skill is still the correct workflow
- confirm repo-relative paths, commands, receipts, or runtime checks are named explicitly
- confirm local authority, stop condition, rollback posture, and verification remain explicit
- confirm the selected preflight or preview is proportional to the side effect
- confirm no stronger host, secret, deployment, or sibling-owner authority was implied
- confirm the adaptation stays bounded to the local repo surface
- confirm the family review doc and bundle-local checklist stay aligned

## Technique traceability
Manifest-backed techniques:
- AOA-T-0028 from `8Dionysus/aoa-techniques` at `cd276f040d55d490bd015b8698c7a5d594b9f875` using path `techniques/execution/agent-workflows-core/confirmation-gated-mutating-action/TECHNIQUE.md` and sections: Intent, When to use, Inputs, Outputs, Core procedure, Contracts, Risks, Validation
- AOA-T-0001 from `8Dionysus/aoa-techniques` at `cd276f040d55d490bd015b8698c7a5d594b9f875` using path `techniques/execution/agent-workflows-core/plan-diff-apply-verify-report/TECHNIQUE.md` and sections: Intent, Outputs, Contracts, Risks, Validation

## Adaptation points
- repo-relative operational surfaces
- local authority and approval notes
- local validation commands
- rollback or recovery expectations
- family review doc and bundle-local review checklist