AgentStack
SKILL verified Apache-2.0 Self-run

Aoa Change Protocol

skill-8dionysus-aoa-skills-aoa-change-protocol · by 8Dionysus

Plan and execute a bounded, non-trivial repository change with explicit verification and reporting. Use when code, config, docs, or operational surfaces change in a meaningful way and the task benefits from an explicit plan. Do not use for trivial wording fixes or when a more specific risk skill fits better.

No reviews yet
0 installs
10 views
0.0% view→install

Install

$ agentstack add skill-8dionysus-aoa-skills-aoa-change-protocol

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No 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.

Are you the author of Aoa Change Protocol? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

aoa-change-protocol

Intent

Ground non-trivial changes in the owner route before editing, then keep the diff reviewable and explicitly verified without hidden scope expansion.

Trigger boundary

Use this skill when:

  • the change affects code, config, docs, or operational surfaces in a meaningful way
  • the task benefits from an explicit plan and verification path
  • the task touches more than a trivial wording fix
  • the request references previous work, sibling repositories, root surfaces, mechanics, generated outputs, or owner boundaries that must be inspected before planning

Do not use this skill when:

  • the edit is tiny and has no meaningful review or operational consequence
  • a more specific risk skill should be used instead

Inputs

  • target goal
  • owner repository or route surface
  • touched files or surfaces
  • source-of-truth or route-law surfaces that constrain the change
  • optional prior-session evidence when the request asks how this repository,

tool, MCP, hook, validator, failure, or change pattern behaved before, preferably as a compact usage-chain packet when the question is about usage, outcomes, consequences, recurrence, or nearby errors for a stable anchor

  • main risk
  • intended validation path
  • rollback idea

Outputs

  • explicit plan
  • scoped change
  • named verification result
  • post-change route review when source-of-truth, generated, decision, roadmap, changelog, quest, mechanic, or owner surfaces may have moved
  • concise final report

Procedure

  1. choose the owner repository and read the nearest route card, AGENTS.md, source-of-truth surfaces, and local validation path before planning
  2. state the goal, touched surfaces, and evidence already inspected; if the request depends on prior work, inspect the current repo state rather than relying on memory
  3. when prior-session behavior matters for risk, speed, or recurrence, use

aoa-session-memory-evidence-route or an equivalent read-only aoa-session-memory-mcp packet; for a stable skill/MCP/hook/tool/script/test anchor, ask for usage-chain first when the question is how it was used, what happened after, or which failures/consequences followed; use entity-dossier when source identity, graph/cooccurrence/timeline context, related entities, or a heavier human packet is needed; expand to usage audit, neighborhood, literal, graph, goal, or answer routes only when the first packet is stale, truncated, missing refs, or too coarse; use the result as route evidence only

  1. identify the main risk, owner boundary, and rollback or recovery shape before editing
  2. prepare the smallest reviewable change that follows the current source route
  3. avoid unrelated cleanup, opportunistic refactors, or importing a sibling owner's authority into the local surface
  4. apply the change inside the declared scope
  5. run or name explicit verification, including generated/export rebuilds when source surfaces feed derived outputs
  6. perform the narrow post-change route review only for surfaces whose meaning actually moved
  7. report what changed, what was verified, what was skipped, what remains risky, and where the next owner route is

Contracts

  • the change must remain reviewable
  • verification must be explicit, not implied
  • the change should stay inside the declared scope
  • rollback thinking should exist before apply
  • the plan should be grounded in inspected source surfaces, not only conversation memory or generic pattern recall
  • generated, exported, compact, or derived surfaces should be refreshed from source rather than hand-authored as truth
  • prior-session evidence can shape risk and route choice, but it does not

override current owner files, validators, or live runtime state

  • cross-repo or mechanics changes should name owner boundaries and stop-lines before moving content

Risks and anti-patterns

  • over-formalizing trivial edits
  • symbolic verification that creates false safety
  • using the report as a substitute for a readable diff
  • silently expanding the task during implementation
  • planning from stale memory when the repository already has route cards, mechanics, or source-of-truth docs that answer the question
  • treating legacy, provenance, generated, or sibling-owner surfaces as if they were the active local contract
  • inserting broad law blocks into local surfaces instead of shaping the change through the existing route

Verification

  • confirm the owner route and relevant source surfaces were inspected before apply
  • confirm the change stayed scoped
  • confirm at least one explicit verification step was run or intentionally skipped with explanation
  • if prior-session evidence was used, confirm the usage-chain, dossier, or

fallback route packet refs were named and current source/runtime evidence still controlled the change

  • confirm generated or export surfaces were rebuilt when canonical inputs changed
  • confirm the post-change route review touched only surfaces whose meaning moved
  • confirm the report includes outcome, rollback thinking, skipped checks, and remaining owner-route risk

Technique traceability

Manifest-backed techniques:

  • 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, When to use, Inputs, Outputs, Core procedure, Contracts, Risks, Validation
  • AOA-T-0002 from 8Dionysus/aoa-techniques at cd276f040d55d490bd015b8698c7a5d594b9f875 using path techniques/instruction/docs-boundary/source-of-truth-layout/TECHNIQUE.md and sections: Intent, When to use, Inputs, Outputs, Core procedure, Contracts, Risks, Validation

Adaptation points

Project overlays should add:

  • local source-of-truth files
  • local validation commands
  • local risk tiers
  • approval or review rules
  • local post-change route review surfaces such as changelog, roadmap, decision records, generated indexes, questbooks, or mechanics ledgers

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.