Harness Control Layer
Use this skill to make large OpenClaw setups more deterministic. Harness should sit above existing OpenClaw surfaces as an operational control layer. It should route, classify, verify, and record. It should not replace memory, context, skills, or execution policy.
Core Boundary
Harness should not become:
- a second memory backend,
- a second context engine,
- an Obsidian/wiki clone,
- an exec-policy bypass,
- a hidden autonomous permission system.
Harness should decide which official layer should handle the task and how completion should be verified.
Routing Workflow
For each user task:
- Classify the task intent.
- Select the likely handling layer.
- Preselect the top 1-3 candidate skills or playbooks.
- Check whether the task includes risky operations.
- Define objective verification before execution.
- Execute through normal OpenClaw tools, permissions, and approvals.
- Record incidents and promote repeated workflows into playbooks or skills.
Use this high-level flow:
task intake
-> skill routing
-> memory/context routing
-> safety preflight
-> execution
-> evaluation
-> incident/lesson recording
-> skill/playbook promotion
Memory And Context Boundaries
Route by responsibility:
| Task type | Primary surface |
|---|---|
| Durable user preference or decision | memory-core / active memory |
| Long conversation recall or compaction recovery | lossless-claw / context engine |
| Human-readable knowledge note | memory-wiki or Obsidian |
| Operational incident, repair flow, or verification record | Harness |
| Reusable procedure | OpenClaw skill or playbook |
Do not store the same fact in every layer. Pick the layer that owns the responsibility.
Skill Routing
When many skills exist, avoid unrestricted scanning. Generate a short candidate list first:
user task -> harness skill router -> top 1-3 candidate skills -> model chooses/executes
Prefer skills whose description, tags, or registry metadata match:
- task intent,
- required tools,
- target system,
- risk level,
- verification needs,
- known failure mode.
If the match is weak, ask a focused clarification or fall back to a general workflow.
Safety Preflight
Run preflight thinking before actions such as:
- delete,
- overwrite,
- move,
- recursive cleanup,
- wildcard deletion,
- cross-drive operations,
- service restart,
- config mutation,
- credential or token handling.
For high-risk operations, require:
- exact target path or service,
- backup or rollback path when practical,
- expected blast radius,
- verification command,
- normal OpenClaw approval or sandbox enforcement.
Harness can classify and explain risk. It must not bypass official execution policy.
Verification
Treat "done" as "verified".
Before execution, define checks such as:
- command exits successfully,
- service health endpoint returns OK,
- port is listening,
- expected file exists,
- rendered artifact opens,
- test passes,
- UI state is visible,
- logs no longer show the known error.
After execution, run the checks. If verification is impossible, say that explicitly and describe the remaining risk.
Incident Learning
Record useful incidents in a compact structured form:
{
"task": "openclaw upgrade",
"symptom": "gateway restart failed",
"root_cause": "systemd service used stale node binary",
"fix": "point ExecStart to the active Node runtime",
"verification": "gateway status ok and expected port listening",
"reuse_rule": "check service ExecStart early after upgrades",
"should_update_playbook": true
}
Promote repeated incidents in this order:
incident note -> playbook -> skill -> registry metadata
ClawHub Metadata Suggestions
When publishing skills that should work with Harness routing, include concise metadata where supported:
- intents,
- keywords,
- negative keywords,
- preferred_when,
- avoid_when,
- risk level,
- sensitive actions,
- verification checks,
- playbook or incident support.
This helps routing layers select candidates without loading every skill into context.