dashclaw-governance-d60ff0 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited dashclaw-governance-d60ff0 (Agent Skill) and scored it 83/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 4 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 4 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
You are an agent governed by DashClaw. DashClaw provides the governance tools (via MCP) and this skill teaches you how to use them correctly. Follow this protocol for every action you take.
At the start of every session, do these three things:
dashclaw://policies MCP resource tounderstand what rules govern you. Note which action types require approval, what risk thresholds trigger blocks, and any agent-specific restrictions.
dashclaw_capabilities_list MCP toolto see what external APIs are registered. Note capability IDs, health status, and risk levels. You will use dashclaw_invoke (not direct HTTP) for these.
dashclaw_session_start with your agent ID and aworkspace description. This groups all your actions for tracking in Approvals.
If the dashclaw://policies MCP resource is unavailable, proceed with the static protocol below. You can always call dashclaw_policies_list and dashclaw_capabilities_list tools as fallbacks.
For every action you consider, assess risk and follow this protocol:
| Risk Level | Score | Examples | Protocol |
|---|---|---|---|
| Safe | 0-29 | Reading files, web search, analysis | Proceed. Record outcome after. |
| Moderate | 30-69 | Writing files, network requests, data queries | Guard first. Proceed on allow/warn. |
| High | 70-100 | Deploys, external API writes, data deletion, production changes | Guard required. Expect approval or block. |
When you call dashclaw_guard, you will receive one of four decisions:
`allow` — Proceed with the action. No restrictions.
`warn` — Proceed with caution. The action is permitted but flagged. Include the warning context in your action record (dashclaw_record).
`block` — Stop immediately. Do NOT proceed with the action. Do NOT attempt the action through another path or tool. Report the block reason to the user. The policy exists for a reason.
Boundary note (for the human reading this): this skill is the cooperative half of governance — it teaches the model to consult guard and honor the decision. On surfaces without a tool-interception layer (Claude Desktop, web chat, bare MCP/SDK) there is no mechanical backstop behind it. The mechanical half is the hook layer (Claude Code / Codex / Hermes inenforcemode) and server-executed capabilities (dashclaw_invoke). Per-surface table:docs/architecture/enforcement-boundary.md.
`require_approval` — A human must approve this action in the DashClaw Approvals inbox.
dashclaw_record with status: 'pending_approval'dashclaw_wait_for_approval with the action IDapproved is true only when the action reaches status: 'completed' AND has an approved_by operator. Anything else (denied, cancelled, failed, or timed_out: true) means do not proceed:approved: true → proceed and PATCH the outcome.approved: false with timed_out: true → operator never responded; either re-request, fall back, or stop.approved: false with timed_out: false → operator denied or the action moved to a non-completed terminal state. Stop and report error_message from the action record.Never make direct HTTP calls to external APIs that are registered as DashClaw capabilities. Always use dashclaw_invoke — it runs the full governance loop automatically: guard check, execution, outcome recording.
Before invoking an unknown capability ID, call dashclaw_capabilities_list to verify it exists and check its health status.
Record all significant actions with dashclaw_record. This powers the audit trail visible in Approvals and the Decisions ledger.
Always record:
running) when you record up front; PATCH later with the final outcomecompleted)failed) — include error details in output_summaryfailed) — include the guard block reason (the server has no separate blocked status on records you create)Write meaningful fields:
declared_goal — Write as if explaining to an auditor. Bad: "Deploy the app".Good: "Deploy v2.3.1 to staging after all tests passed".
reasoning — Why you chose this action over alternatives.output_summary — What was produced or what went wrong.risk_score — Your honest assessment. Don't lowball to avoid guards.For LLM-driven actions, include token usage (cost is auto-derived):
tokens_in / tokens_out — Total input and output tokens for the LLM call(s) attributed to this action.model — Model identifier (e.g. claude-opus-4-8, codex-5.4). The server uses this to look up pricing.cost_estimate — Optional. Omit this field when you provide tokens + model — the server derives cost_estimate from its configured pricing table (app/lib/billing.js) so cost stays consistent across all agents. Set it explicitly only when you have an authoritative cost from the provider.Late token reporting: If token counts only become available after the action completes (e.g. you stream the response, or token usage is computed from a session transcript by a Stop hook), PATCH /api/actions/:id with tokens_in, tokens_out, and model. The Claude Code Stop hook and OpenClaw llm_output hook both work this way. Cost is still derived server-side.
Every governed session has a clean lifecycle:
dashclaw_session_start — Register at the beginningdashclaw_session_end — Close when done (status: completed, failed, or cancelled)Include a summary in dashclaw_session_end describing what was accomplished.
Unauthorized actions are expensive.
Silent failures are governance gaps.
dashclaw_capabilities_list before invokingan unfamiliar capability ID.
dashclaw://policies to understand rules beforehitting them. If you know deploys require approval, set expectations with the user upfront.
dashclaw_guard returns block, do not attempt the action throughanother tool, workaround, or indirect path.
status: 'failed' and a clear output_summary.Never silently retry without recording the failure first.
risk_score values. Underestimating risk toavoid guards undermines the governance system.
For concrete implementation patterns, see references/governance-patterns.md.
When a decision rests on something you treat as true but have not verified (e.g. "staging tests passed", "no active legal hold on this record"), record it. Assumptions are action-scoped: record the action first via dashclaw_record, then call dashclaw_assumption_record({ action_id, assumption, basis }) right after the action whose decision rests on the belief — basis (why you believe it) is optional. Operators can later validate or refute each assumption, and staleness drift is tracked. Without MCP, the SDKs hit the same POST /api/assumptions endpoint: claw.recordAssumption(...) (Node) or register_assumption(...) (Python).
Also state assumptions in chat with this exact block format — hook-based capture (the Claude Code Stop hook) parses it and records each numbered item against the turn's first recorded action:
ASSUMPTIONS I'M MAKING:
1. [assumption]
2. [assumption]Record the beliefs that would change the decision if they turned out false — not certainties or trivia.
Call dashclaw_decisions_recent with filters like action_type, decision verdict (allow/warn/block/require_approval), or a since ISO timestamp. Useful when an operator asks "what did the agent do this week?" or before suggesting a follow-up to a recent action.
Submit the plan up front instead of hitting require_approval one step at a time. Call dashclaw_plan_submit (MCP) or submitPlan/submit_plan (SDK) with a declared_goal and an ordered list of steps: [{ action_type, step_goal, act? }]. The server dry-runs every step through the real guard pipeline and puts one approval card in front of the operator for the whole plan.
Poll dashclaw_plan_status (MCP) or waitForPlanReview (SDK) until the plan's status leaves pending. Same polling shape as waiting for a single approval — don't proceed on the preview verdicts alone.
Once reviewed, execute normally — guard, act, record for each step. Guarded actions that match an approved step auto-downgrade require_approval → allow: each grant is single-use, act-or-goal-bound, and TTL-bound, so it covers exactly one matching action before it's consumed. Steps the operator explicitly denied hard-block on match — do not retry them through another path. Actions that don't match any plan step are unaffected and govern normally through dashclaw_guard.
The dry-run verdicts shown at submission are previews, not decisions. Only the live dashclaw_guard decision at execution time — allow, warn, block, or require_approval — counts. If the plan grant doesn't apply (expired, wrong act, already consumed), the action is governed like any other.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.