| name | aoa-safe-infra-change |
| description | Make bounded infrastructure, configuration, service, or operational changes with explicit risk framing, proportional verification, and rollback thinking. Use when a change has runtime or deployment implications and needs stronger discipline than a normal code edit. Do not use for purely local code changes, or when the main need is approval classification or preview-first execution. |
| license | Apache-2.0 |
| compatibility | Designed for Codex or similar coding agents with repository file access and an interactive shell. Network access is optional and only needed when repository validation or referenced workflows require it. |
| metadata | {"aoa_scope":"risk","aoa_status":"canonical","aoa_invocation_mode":"explicit-only","aoa_source_skill_path":"skills/risk/aoa-safe-infra-change/SKILL.md","aoa_source_repo":"8Dionysus/aoa-skills","aoa_technique_dependencies":"AOA-T-0028,AOA-T-0001","aoa_portable_profile":"codex-facing-wave-3"} |
aoa-safe-infra-change
Intent
Use this skill to shape infrastructure, service, configuration, or operational changes into a safer bounded workflow.
Trigger boundary
Use this skill when:
- the task changes infrastructure, services, configuration, orchestration, or operational surfaces
- the change has runtime, safety, or deployment implications
- the task needs stronger verification and rollback thinking than a normal code edit
Do not use this skill when:
- the task is a purely local code change with no operational implications
- a more specific risk skill should be used instead
- the operator has not provided enough authority for the requested action
- 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
Inputs
- target change
- touched operational surfaces
- stated authority or approval state
- validation path
- rollback idea
Outputs
- explicit risk-aware plan
- bounded infrastructure or config change, or bounded execution recommendation
- verification result
- report with remaining risk notes
Procedure
- identify the operational surface and main risk
- confirm whether the change belongs to a high-risk or explicit-only category
- keep the change small and reviewable
- avoid unrelated cleanup or hidden expansion of scope
- verify the result using the strongest practical bounded checks available
- report what changed, what was verified, and what remains risky or deferred
Contracts
- infrastructure changes should stay explicit and reviewable
- risk should be named before apply, not after failure
- verification should be stronger than symbolic confidence
- rollback thinking should exist before execution
Risks and anti-patterns
- treating infra edits like ordinary code edits
- making broad config or orchestration changes under a narrow task label
- relying on weak verification for changes with real runtime impact
- skipping explicit risk framing because the diff looks small
Verification
- confirm the operational surface was named clearly
- confirm the change stayed bounded
- confirm verification was explicit and proportional to the risk
- confirm rollback or recovery thinking was present before execution or recommendation
- confirm the report includes unresolved risk or recovery notes
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
Future project overlays may add:
- local risk classifications
- approval rules
- preferred validation commands
- rollback or recovery expectations
