Critic Agent
PassAudited by ClawScan on May 1, 2026.
Overview
This appears to be a coherent critic/reviewer skill, with cautions around prompt-injection resistance, provider/API-key use, and persistent critique logging.
This skill is reasonable to use as a model-based reviewer, but do not rely on it as the sole security or quality gate for high-stakes outputs. Delimit untrusted outputs, configure fail-closed behavior for important workflows, avoid sending secrets to provider-backed critiques, and control retention of critique logs.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A bad or adversarial agent output could try to manipulate the critic into giving an undeserved score.
The content being evaluated is placed directly into the critic prompt. If an output under review contains instructions aimed at the critic, the model may be influenced unless callers add clear delimiters and untrusted-content handling.
Output to Review:
{{OUTPUT}}
Additional Context (requirements, constraints):
{{CONTEXT}}
Now provide your critique:Wrap reviewed outputs in clear data delimiters and add an explicit instruction that content under review must not override the critic's rubric or output format.
If used as a strict quality gate, a critic failure could still allow an output to proceed.
The documented default is fail-open on critic errors, which can let downstream workflows deliver an output without review if the critic fails.
| `onCriticError` | string | "pass" | Behavior on critic failure: `"pass"` (deliver anyway), `"reject"` (treat as fail), `"fail-safe"` (use heuristic fallback) |
For important or public-facing workflows, configure critic failures to reject, fail safe, or require human review rather than passing automatically.
The test script may fail or behave differently depending on local tools and paths.
The helper script expects openclaw, jq, and node, while the registry requirements list no required binaries. The script is user-directed, so this is an under-declared dependency note rather than an install-time concern.
if ! command -v openclaw &> /dev/null; then ... if ! command -v jq &> /dev/null; then ... ... echo "$CRITIQUE_JSON" | node /home/weq/.openclaw/workspace/skills/critic-agent/scripts/compute-score.js
Document helper-script prerequisites in metadata or setup instructions, and avoid hardcoded user-specific paths in shared examples.
Using the skill with provider-backed model calls may require granting access to an LLM API account.
The documentation references a provider API key even though registry metadata declares no required environment variables. This is expected for invoking an LLM-backed critic and there is no evidence of hardcoding, logging, or unrelated credential use.
| `OPENROUTER_API_KEY` | API key for LLM provider (required for --local agent calls) |
Use a minimally scoped provider key where possible and configure it only when you intend the critic to call that provider.
Private task details or agent outputs could be shared with the configured model/provider during critique.
The test workflow sends the full prompt, including task, output, and context, to another agent/model invocation. This is central to the critic purpose, but users should understand the data boundary.
CRITIQUE_JSON=$(echo "$FULL_PROMPT" | openclaw agent --local --json -m "$FULL_PROMPT" 2>/dev/null)
Avoid sending secrets or sensitive customer data to the critic unless the configured model/provider and retention settings are acceptable.
Critique history and task metadata may persist across runs and could reveal information about prior work.
The documentation recommends persistent critique logging. The sample log stores task metadata, scores, verdicts, and model information for future monitoring.
Every critique should be logged to `memory/critic-log.json`:
Set retention rules, avoid logging sensitive task content, and review who or what can read the memory log.