Truth first

Evidence-first verification for status, config, file contents, actions, connectivity, mounts, and model selection. Use before answering any such claim.

Security Scan

The skill's instructions are coherent with an evidence-first verification purpose, but there are mismatches and broad, under-constrained instructions that could let the agent read sensitive local files (e.g., .env, configs, logs) without the skill declaring required tools or clarifying scope.

Purpose & Capability

The name/description (evidence-first verification) matches the SKILL.md: it instructs the agent to list claims and gather local evidence (files, command outputs, service status). However, README and SKILL.md assume tools like ripgrep (`rg`) and `openclaw gateway status` are available while the registry metadata lists no required binaries — a minor incoherence in declared requirements.

Instruction Scope

The runtime instructions explicitly tell the agent to read files, run system commands (rg, ls, stat, ss, lsof, openclaw), and search .env and config paths. That is within the stated purpose but gives broad discretion to access potentially sensitive material (env files, logs, configs, mounts, open ports). The skill does not constrain which paths to search or limit queries, so an agent following it could collect secrets or wide system state unless tool permissions or policies prevent that.

Install Mechanism

Instruction-only skill with no install steps or archive downloads — low installation risk. Nothing is written to disk by an installer.

Credentials

The skill declares no required environment variables or credentials, which fits a read-only verification workflow. But SKILL.md and references explicitly instruct searching .env and configuration files for model/provider values; this is reasonable for verification but means the skill will probe files that commonly contain secrets. Also, the README lists ripgrep as a requirement even though the registry metadata doesn't—another small mismatch.

Persistence & Privilege

The skill does not request always:true and does not claim persistent system modifications. Normal autonomous invocation is allowed by platform defaults. Combined with the instruction scope (broad filesystem and runtime checks), autonomous invocation increases blast radius but by itself is not an incoherence.

What to consider before installing

This skill appears to do what it says (verify claims by checking files and runtime state), but be aware of two issues before installing: 1) The instructions expect tools like ripgrep and OpenClaw CLI commands (e.g., `openclaw gateway status`) even though the skill metadata does not declare required binaries — confirm whether your agent environment provides those tools. 2) The skill intentionally directs the agent to read local files and run system commands (including searches of .env, config files, logs, mounts, and network socket listings). If those files contain secrets or sensitive telemetry, the agent will see them when the skill runs. Recommended actions: (a) only enable this skill in environments where the agent is allowed to read these files; (b) apply strict tool/permission policies or run the agent in a sandbox if you have secrets on disk; (c) ask the skill author to update registry metadata to declare required binaries and to add configurable scope (allowed paths or deny-lists); (d) if you need higher assurance, request a signed provenance or an explanation of how the skill avoids exfiltration (e.g., read-only tooling, no external network calls). Additional information that would reduce concern: an explicit tool whitelist, declared required binaries in metadata, or a narrow, auditable set of paths the skill is permitted to inspect.

Core Rule

Require evidence before answering. Do not rely on memory or assumptions for claims about system state, files, configs, execution, connectivity, mounts, or model selection.

Response Framework (Strict)

1. List claims to verify.
2. For each claim, gather evidence using tools (read/status/rg/logs).
3. Classify each claim as Verified, Inferred, or Unknown.
4. For each Unknown, provide the next-step command(s) needed.
5. Always cite evidence (paths, key lines, or command outputs).

Workflow

1. Parse the user request and extract every factual claim that would change your response.
2. Decide the minimum set of checks needed to verify each claim.
3. Run evidence commands or open files. Prefer direct sources over indirect signals.
4. Summarize findings with classifications and evidence citations.
5. Only then provide the answer or recommended next steps.

Evidence Standards

• Prefer primary evidence: files, logs, command outputs, or tool responses.
• Use rg for targeted searches and ls/stat for existence and timestamps.
• When a claim could be true but is not verified, mark it Inferred and state why.
• Never upgrade an Unknown to Verified without direct evidence.
• If evidence cannot be gathered (missing tools, permissions, or files), state the limitation and stop short of a definitive answer.

Common Claim Types

• Status: service running, gateway connected, connectivity, mount status, disk usage.
• Configuration: values in config files or environment variables.
• File contents: presence, specific lines, or recent modifications.
• Actions: whether a command ran, tests passed, or a file was edited.
• Model selection: which model is configured or currently in use.

References

• Use references/patterns.md for reusable templates and evidence commands.