Install
$ agentstack add skill-8dionysus-aoa-skills-abyss-safe-infra-change ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
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-changeworkflow is already correct, but anabyss-*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 baseaoa-safe-infra-changeskill 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
- start from
aoa-safe-infra-changeinstead of inventing a new project-family workflow - read the nearest repo route card before treating a path as locally owned
- classify the touched surface: source config, generated operational receipt, runtime wrapper, launch command, environment template, deployment toggle, or verification script
- name the side effect, authority posture, stop condition, and rollback or recovery anchor before proposing execution
- choose the smallest local preflight or preview that can prove the change shape without performing a stronger mutation
- keep commands and paths repo-relative unless the operator explicitly authorizes a host or environment path
- preserve the base risk framing, rollback thinking, and explicit verification posture
- 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-shareis 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-techniquesatcd276f040d55d490bd015b8698c7a5d594b9f875using pathtechniques/execution/agent-workflows-core/confirmation-gated-mutating-action/TECHNIQUE.mdand sections: Intent, When to use, Inputs, Outputs, Core procedure, Contracts, Risks, Validation - AOA-T-0001 from
8Dionysus/aoa-techniquesatcd276f040d55d490bd015b8698c7a5d594b9f875using pathtechniques/execution/agent-workflows-core/plan-diff-apply-verify-report/TECHNIQUE.mdand 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
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: 8Dionysus
- Source: 8Dionysus/aoa-skills
- License: Apache-2.0
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.