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
• explicit local authority, rollback posture, or verification commands still need to be named before execution
• 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 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 or commands
• explicit local authority or approval posture
• validation and rollback path
• base skill reference

Outputs

• bounded local infra-change plan
• repo-relative command or path sketch
• explicit local authority and rollback note
• 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. name the repo-relative operational files, commands, and authority posture that matter locally
3. keep the adaptation bounded to the local repo surface under change
4. preserve the base risk framing, rollback thinking, and explicit verification posture
5. 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 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
• 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 and commands are named explicitly
• confirm local authority, rollback posture, and verification remain explicit
• 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 5c6f0496edc3c2e74590baa35627c85fe58ef765 using path techniques/agent-workflows/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 5c6f0496edc3c2e74590baa35627c85fe58ef765 using path techniques/agent-workflows/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