| name | ocm-review |
| description | Review OpenClaw Machines changes by tracing behavior beyond the diff, checking ownership boundaries, and requiring focused proof for bug fixes. |
OCM Review
Use this skill for PR review, review-comment resolution, post-fix review, or
any request asking whether a change is correct, safe, or the best fix.
Review Posture
Review behavior, not prose. A convincing PR description is not proof. Read the
real code path, adjacent tests, docs, and deployment assumptions before giving a
verdict.
Required Pass
- State what the change does and why the surface matters.
- Read the changed files plus enough surrounding code to identify:
- runtime entry point
- owner module
- one caller
- one callee
- sibling surfaces that should share the invariant
- adjacent tests
- relevant config/docs
- Compare with current
origin/main behavior when regression or compatibility
matters.
- For dependency-backed behavior, read official docs/source/types instead of
relying on memory.
- Decide whether the patch is the best owner-boundary fix or only a plausible
mitigation.
- Require focused proof for bug fixes: reproduction/log/failing test when
practical, root cause in code, fix touching the implicated path, and a
regression test or explicit reason no test was added.
OCM-Specific Checks
- Local/operator paths must not depend on hosted-only Cloudflare, GCP, Firebase,
or private-domain defaults.
- Every VM path must preserve the gateway/proxy token and signing-key contract.
- Worker origins must not point back at hostnames served by the same Worker
route.
- User-facing machine access must go through the configured data-plane
protection model; do not expose KVM worker hosts directly.
- Host enrollment must keep workers authenticated as infrastructure, not human
users.
- Runtime/rootfs changes need guest-init and agent-client compatibility checks.
- Public-core changes must not add billing, commercial plan enforcement, or
private hosted overlay assumptions.
Output Shape
Use this compact structure:
Findings: ordered by severity with file/line references.Best-fix verdict: best / acceptable mitigation / wrong layer / too narrow /
too broad.Alternatives considered: one to three concrete alternatives and why they
were rejected.Code read: main files/contracts inspected.Proof: tests, logs, or commands checked.Remaining uncertainty: what was not proven.
If there are no findings, say that clearly and still include proof and remaining
risk.
