mcpField
P
persistent-side-effects

persistent-side-effects

github.com/liaoannAgent workflows039 installsUpdated 4w ago
Repository

About persistent-side-effects

Persistent Side Effects is an agent skill that defines which implementation actions are covered by an accepted request and which need specific approval. It helps agents keep changes within scope and distinguish necessary local validation from external or destructive actions.

Key features

  1. 01Define implementation authorization boundaries
  2. 02List changes covered by accepted requests
  3. 03Require approval for sensitive actions
  4. 04Check authorization against scope and impact
  5. 05Set a completion criterion for side effects

Use cases

  1. 01Decide whether an implementation step needs approval
  2. 02Keep code changes within an accepted plan
  3. 03Review permissions before destructive or external actions

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/liaoann/skills --skill persistent-side-effects

After installing, type/persistent-side-effectsin Claude Code to confirm it loaded.

Details

From the project README

Persistent Side Effects

An accepted implementation request or plan authorizes necessary changes within its scope, not every action an agent could take. A question, investigation, or planning request alone does not authorize implementation.

Covered by Implementation Approval

Without asking again for each file or command:

  • Create or edit source files and tests needed for the accepted outcome.
  • Update generated artifacts through the project's expected tooling when required by those changes.
  • Run known-safe local validation and fix failures caused by the requested change within the same scope. Disposable fixtures and expected build/test outputs are included when the environment is known to be isolated from production.
  • Make necessary local-support edits under /agentic-change-governance.

The plan need not enumerate exact filenames. Authorization follows the accepted outcome and boundaries; a test demanding a change is not itself authorization. Unknown test isolation, production access, or destructive command behavior must be resolved before running the command.

Require Specific Approval

Unless already explicitly approved for this task:

  • Staging, committing, creating or switching branches, pushing, publishing, or deploying.
  • Destructive actions such as deleting or moving existing user-visible files, overwriting unrelated work, dropping data, or removing containers or volumes.
  • Changes outside the accepted scope or new design decisions under /agentic-change-governance.
  • Creating persistent environments or changing shared/external systems.
  • Scratch, planning, notes, or convenience artifacts not needed for the deliverable. Keep these in the conversation by default.

Approval for one action does not imply another: implementation does not imply commit, and creating a container does not imply permission to remove it. Existing harness restrictions and explicit user prohibitions still apply.

Approval Check

Identify the action, its affected resources, and the request or plan that authorizes it. Ask only for the missing decision when it falls outside that authority; do not re-ask for an action already specifically approved. If scope or impact is uncertain, clarify before acting.

Completion Criterion

Every side effect is either necessary within accepted implementation scope and covered above, or specifically approved before execution. No unrelated work, protected resource, or external system was changed under an inferred blanket approval.

Comments

Markdown supported