clawgate

clawgate: OpenClaw Execution Governance

An OpenClaw governance skill that keeps low-risk work moving, reduces confirmation noise, and hard-stops risky actions before they slip through.

中文说明 · License: Apache-2.0

---

Start Here

If you only need the shortest correct setup path:

1. Install clawgate into your active OpenClaw skills path.
2. Paste the exact block from clawgate/references/agents-snippet.md into your real always-injected AGENTS.md or equivalent standing-order entry point.
3. Run npm run validate:activation:strict.
4. Run npm run validate.

If step 2 is skipped, the skill is installed but not active.

Search Terms

This repository is for users searching for:

• OpenClaw governance skill
• OpenClaw approval policy
• OpenClaw confirmation guardrails
• OpenClaw AGENTS activation snippet
• OpenClaw plugin install safety
• OpenClaw router / broadcast approval control

Why This Exists

Most agent setups fail in one of two ways:

1. Safe work gets slowed down by repetitive confirmations.
2. Risky work moves too casually once tools are available.

clawgate is built for one job: make OpenClaw execution safer without making routine work slower. It does not try to solve every agent problem. It focuses on one operational decision:

• when to execute now
• when to keep medium-risk work moving
• when to stop hard

What You Get

After clawgate is actually integrated into OpenClaw, an agent is much more likely to:

1. Execute low-risk work directly instead of asking again.
2. Execute medium-risk work directly, then verify and report.
3. Aim for a continuous LOW/MEDIUM closed loop: end with verify + report only, without unnecessary tail offers like Next Step or If you need, I can....
4. Hard-stop on destructive, privileged, costly, external, or OpenClaw-core actions, and split truly critical actions into itemized approval.
5. Escalate OpenClaw-specific surfaces more aggressively than generic developer tasks.
6. Give both operators and OpenClaw search a clearer signal that this is an approval, confirmation, and risk-governance skill.
7. Stay honest about the boundary between skill-layer guidance and runtime enforcement.

That no-tail-filler rule is an execution-result preference, not a ban on explicit structured fields in activation or audit templates.

Installation alone does not create that effect. This repository needs real OpenClaw injection to become active governance.

Promise To Contract Map

• LOW / MEDIUM should move directly: see SKILL.md, risk-matrix.md, checklist.md
• HIGH should hard-stop for explicit approval and CRITICAL should require itemized approval: see SKILL.md, agents-snippet.md, risk-matrix.md, confirmation-templates.md
• no-tail-filler is a governance goal for LOW / MEDIUM execution-result replies: see SKILL.md, risk-matrix.md, checklist.md
• human acceptance prompts should reflect the same LOW/MEDIUM no-tail intent: see openclaw-prompts.md, evals.json
• install is not activation: see SKILL.md, agents-snippet.md
• plugin failure should route to recovery: see SKILL.md, examples.md, evals.json

Core Behavior

• LOW: execute directly, verify, then report
• MEDIUM: execute directly, report with Action -> Verify -> Result
• HIGH: require an actually blocked confirmation with Risk: HIGH, Scope, Impact, Possible Consequence, Missing Fields when relevant, and Continue or Cancel
• CRITICAL: require itemized approval with explicit authorization granularity and Approve Each Item

Current State

Current practical status:

• runtime behavior is useful only after real activation, not after install alone
• activation:strict is the merge and release gate for injected-snippet correctness
• LOW, MEDIUM, HIGH, and CRITICAL behavior should be judged from real injected OpenClaw replies, not from repo text alone
• if runtime behavior looks stale, fix activation drift first before changing prompts, templates, or harnesses

Why It Is OpenClaw-Specific

This repository does not treat OpenClaw like an ordinary coding environment. It explicitly escalates risk around surfaces such as:

• ~/.openclaw/openclaw.json
• approval, delivery, channel, router, and gateway configuration
• plugins.entries and plugin wiring
• extension install/remove/update flows
• gateway restart or shared service restart
• external delivery integrations
• cross-instance or shared-workspace actions

Reading these surfaces can still be LOW. Single-instance non-sensitive maintenance with backup + validation + rollback may stay MEDIUM. Mutating sensitive or shared surfaces is usually HIGH. Cross-instance shared-router, auth/token, bulk delete, or broadcast external work is CRITICAL. Combining plugin install + config mutation + restart is always blocked HIGH. If shared data deletion, shared router mutation, everyone scope, and cross-instance impact hit any two or more signals together, the request must be treated as CRITICAL.

Without vs With

Without clawgate

• "Install this plugin and wire it into OpenClaw."
• Agent treats it like normal dev setup work and pushes ahead too casually.
• Result: shared config, gateway, or delivery behavior can break.

With clawgate

• After the skill is wired into real OpenClaw entry points, the same request is escalated as OpenClaw-sensitive.
• Agent asks for explicit confirmation, states impact, and routes toward guarded install / recovery lanes when needed.
• Result: lower friction on safe work, higher friction where it actually matters.

Installation Is Not Activation

This repository is a governance package. It does not automatically become live behavior just because it exists on disk or is installed somewhere.

To affect actual OpenClaw execution, it must be injected through a real entry point such as:

• AGENTS.md
• standing orders
• runtime approval policy

What This Skill Does Well

• risk classification into LOW, MEDIUM, HIGH, and CRITICAL
• low- and medium-risk execution without unnecessary permission friction
• continuous LOW/MEDIUM execution with tail-offer suppression as a governance goal
• OpenClaw-specific escalation rules
• bounded approval windows and recoverability-aware downgrade rules
• preference-aware reduction of result verbosity for repeated MEDIUM patterns
• routing risky work toward clarification, protection, installer, or recovery workflows

What This Skill Does Not Do

• it is not a replacement for clarify-first
• it is not a generic implementation or architecture advisor
• it is not a runtime policy engine
• it does not provide non-bypassable enforcement by itself

If the real problem is ambiguity, use clarify-first first. If the requirement is guaranteed blocking of dangerous actions, that belongs in OpenClaw runtime and policy.

Repository Layout

• clawgate/SKILL.md: main skill contract
• clawgate/references/risk-matrix.md: OpenClaw-oriented risk rules
• clawgate/references/confirmation-templates.md: high-risk confirmation patterns
• clawgate/references/examples.md: example triggers and boundaries
• clawgate/references/checklist.md: execution checklist
• clawgate/references/single-instance-profile.md: single-instance downgrade profile
• clawgate/evals/evals.json: