القائمة
Use when an agent or automation can touch external systems — stay read-only/reversible by default and gate consequential acts behind durable human approval.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
| name | reversible-by-default-confirm-consequential |
| description | Use when an agent or automation can touch external systems — stay read-only/reversible by default and gate consequential acts behind durable human approval. |
Build the system so it cannot harm anything it does not own: read-only and reversible on every external system by default, with each consequential or outward-facing action paused for an authorized human's approval. The pause must be durable — persisted before you wait — so a stopped run survives restarts.
Apply whenever an agent or automation can reach a system you do not fully control: ticketing, wikis, repos, email, payment APIs, production data, customer-facing surfaces. Apply the moment a workflow's output could become public, mutate shared state, or be hard to undo.
Red-flag thoughts that mean STOP and apply this skill:
Reversibility is your blast-radius control. If the agent can only read external systems and only writes to its own store, the worst failure is a bad draft sitting in your DB — not a corrupted ticket, a wrong email blast, or a force-pushed branch. A human-approval gate converts the agent from an autonomous actor into a proposer, which is the only safe posture when actions are public or hard to undo.
Durability is what makes the gate real. An in-memory pause is a promise that survives only until the next deploy, OOM, or autoscaler event — and consequential runs are exactly the ones you cannot afford to silently drop or blindly re-run. Persisting before waiting means a paused decision is a durable, auditable object, not a thread you are praying stays alive. And a test pinning read-only access is what keeps the invariant true six months and twenty commits later, when the original author is gone and "just one write" looks harmless.
On the project this was distilled from — a hexagonal, human-in-the-loop AI agent that drafts documentation from a ticketing system and was shipped to a cloud runtime — the safety posture was enforced at three layers:
test_ticketing_adapter) exercised every adapter method and asserted set(seen) == {"GET"} — proving nothing but reads ever reached the external SaaS. Adding a write breaks the build.resume call rehydrated and continued "even on a fresh instance after scale-to-zero" (DEPLOYMENT docs §4), backed by private ingress and read-only egress credentials.You can apply the same shape without knowing that project: read-only external adapters, a test that pins it, persist-then-pause for approval, checkpointed state, and infra that assumes the code might be wrong.
A later field test showed the rule guarding its own author: an agent about to push a release tag was stopped by its permission layer because the human had approved "the version jump" but had never named the irreversible act the tag would trigger — publication to a public package registry. The release proceeded only after the human explicitly authorized publishing that version. That is rule 8 operating as written: the consequential act was the publish, not the push.
What a machine can check: that the read-only claim survives contact. A recording-transport test driving every external adapter and asserting read-only verbs — adding a write breaks the build; a resume-after-restart test proving the approval pause is durable, not in-memory; deploy manifests linted for private ingress and read-only egress credentials. At runtime, permission layers that classify by downstream consequence enforce rule 8 mechanically — gating the tag push that is a publish, not just commands that look scary.
Related skills: