Review And Validation

Maintainer review is judgment plus evidence. CI is useful, but it is not a substitute for understanding the change.

Default Review Bar

  • Understand the problem before accepting the fix.
  • Treat PRs as reports first and code second. If submitted code is poor, implement the best solution while preserving contributor attribution when landing through the PR.
  • Keep changes scoped to the behavior under review.
  • Fix root causes instead of local symptoms.
  • Validate external-input boundaries, tool output, network payloads, and config surfaces.
  • Use human-readable copy for CLI, onboarding, slash commands, and channel text.

Agent Review Flow

  • Use review-pr for review-only work.
  • Use prepare-pr to resolve blocker and important findings, gate the branch, and push maintainer fixes to the PR branch when possible.
  • Use merge-pr for deterministic squash merge, head-SHA pinning, attribution, verification, and cleanup.
  • Pause between skills to evaluate direction. Skills execute workflow; maintainers provide judgment.
  • Run /review on staged PR work until actionable issues stop appearing.

Gate Policy

  • Prefer scoped tests for narrow changes.
  • Broaden validation when the change touches shared runtime behavior, plugin contracts, release paths, security paths, package management, onboarding, or cross-platform behavior.
  • Use Crabbox or Blacksmith Testbox for broad, slow, Docker, E2E, release, and CI-parity validation.
  • For normal OpenClaw source changes, run the repo's changed gate before handoff unless the task explicitly calls for a wider gate.
  • Do not start duplicate heavy checks when another session is likely already running them.
  • If a gate failure reproduces on current main and is clearly unrelated to the PR, document it as baseline noise and keep the decision anchored on scoped proof.

CI And ClawSweeper

  • Do not rely on CI to find issues you could have caught with a focused review.
  • Do not rely on ClawSweeper to make maintainer judgment.
  • Use ClawSweeper automerge only for trusted, bounded PRs where asynchronous gate-driven automation is acceptable.
  • Prefer a steerable agent session or GitHub's squash merge button for release-critical, ambiguous, or actively changing work.

Handoff Quality

  • Include what changed, why it matters, what was tested, and what remains risky.
  • Include exact command names for validation, not generic "tests pass" claims.
  • Include unrelated baseline failures only when they affected the decision.
  • Keep final PR comments factual and short.