openclaw
diff --git a/‎.agents/skills/crabbox/SKILL.md‎
Lines changed: 36 additions & 3 deletions b/‎.agents/skills/crabbox/SKILL.md‎
Lines changed: 36 additions & 3 deletions
diff --git a/‎.agents/skills/openclaw-pr-maintainer/SKILL.md‎
Lines changed: 21 additions & 2 deletions b/‎.agents/skills/openclaw-pr-maintainer/SKILL.md‎
Lines changed: 21 additions & 2 deletions
diff --git a/‎.oxlintrc.json‎
Lines changed: 1 addition & 0 deletions b/‎.oxlintrc.json‎
Lines changed: 1 addition & 0 deletions
@@ -31,6 +31,13 @@ pnpm crabbox:run -- --help | sed -n '1,120p'
 - Check `.crabbox.yaml` for repo defaults, but override provider explicitly.
   Even if config still says AWS, maintainer validation should normally pass
   `--provider blacksmith-testbox`.
+- For live/provider bugs, check keys on the local Mac before downgrading to
+  mocks: source local `~/.profile` and test only presence/length. If Crabbox
+  does not already have the key, copy only the exact needed key into the remote
+  process environment for that one command. Do not print it, do not sync it as a
+  repo file, and do not leave it in remote shell history or logs. If no
+  secret-safe injection path is available, say true live provider auth is
+  blocked instead of silently using a fake key.
 - Prefer local targeted tests for tight edit loops. Broad gates belong remote.
 - Do not treat inherited shell env as operator intent. In particular,
   `OPENCLAW_LOCAL_CHECK_MODE=throttled` from the local shell is not permission
@@ -142,9 +149,11 @@ Pick the lane by symptom:
 - Docker/setup/install bug: build a package tarball and run the matching
   `scripts/e2e/*-docker.sh` or package script. This proves npm packaging,
   install paths, runtime deps, config writes, and container behavior.
-- Provider/model/auth bug: use a live lane when a `.profile`/Testbox profile key
-  is available; otherwise use the repo's mock provider lane and state clearly
-  that live provider auth was not exercised.
+- Provider/model/auth bug: prefer true live E2E. First source local Mac
+  `~/.profile`, then inject the single needed key into Crabbox if needed. Scrub
+  unrelated provider env vars in the child command so interactive defaults do
+  not drift to another provider. If only a dummy key is used, label the proof
+  narrowly, e.g. "UI/install path only; live provider auth not exercised."
 - Channel delivery bug: use the channel Docker/live lane when available; include
   setup, config, gateway start, send/receive or agent-turn proof, and redacted
   logs.
@@ -180,6 +189,30 @@ Keep it efficient:
 - Include `--timing-json` on broad or flaky runs when command duration or sync
   behavior matters.
 
+Interactive CLI/onboarding:
+
+- For full-screen or prompt-heavy CLI flows, run the target command inside tmux
+  on the Crabbox and drive it with `tmux send-keys`; capture proof with
+  `tmux capture-pane`, redacted through `sed`.
+- Prefer deterministic arrow navigation over search typing for Clack-style
+  searchable selects. Raw `send-keys -l openai` may not trigger filtering in a
+  tmux pane; inspect option order locally or on-box and send exact Down/Enter
+  sequences.
+- Isolate mutable state with `OPENCLAW_STATE_DIR=$(mktemp -d)`. Plugin npm
+  installs live under that state dir (`npm/node_modules/...`), not under
+  `OPENCLAW_CONFIG_DIR`. Verify downloads by checking the state dir, package
+  lock, and installed package metadata.
+- To test automatic setup installs against local package artifacts, use
+  `OPENCLAW_ALLOW_PLUGIN_INSTALL_OVERRIDES=1` plus
+  `OPENCLAW_PLUGIN_INSTALL_OVERRIDES='{"plugin-id":"npm-pack:/tmp/plugin.tgz"}'`.
+  Pack with `npm pack`, set an isolated `OPENCLAW_STATE_DIR`, and verify the
+  package under `npm/node_modules`. Overrides are test-only and must not be
+  treated as official/trusted-source installs.
+- For OpenAI/Codex onboarding proof, the useful markers are the UI line
+  `Installed Codex plugin`, `npm/node_modules/@openclaw/codex`, and the
+  package-lock entry showing the bundled `@openai/codex` dependency. A dummy
+  OpenAI-shaped key can prove only UI/install behavior; it is not live auth.
+
 ## Reuse And Keepalive
 
 For most Blacksmith-backed Crabbox calls, one-shot is enough. Use reuse only
 
@@ -108,8 +108,8 @@ Issue triage is review/prove/patch-local by default:
 1. Review the issue body, comments, related threads, current code, and adjacent tests.
 2. Fix only issues that are easy, high-confidence, and narrowly owned by the implicated path.
 3. Add focused regression proof when practical.
-4. Stop with the dirty diff, touched files, and test/gate output for Peter's manual review.
-5. After Peter approves shipping, make one commit per accepted fix, with its own changelog entry when user-facing.
+4. Stop with the dirty diff, touched files, and test/gate output for maintainer review.
+5. After maintainer approval to ship, make one commit per accepted fix, with its own changelog entry when user-facing.
 6. Pull/rebase, push, then comment and close only the issues that were fixed or explicitly triaged closed.
 
 Do not batch unrelated issue fixes into one commit. Do not publish, comment, close, or label during the review/prove phase.
@@ -134,6 +134,22 @@ Loop:
 
 Output only qualifying candidates, with: ref, surface, proof, cause, fix sketch, why small, expected test/gate. If none qualify, say so; do not pad.
 
+## Structure PR review output
+
+- Start every PR review with 1-3 plain sentences explaining what the change does and why it matters. Put this before `Findings`.
+- Then list findings first. If none, say `No blocking findings` or `No findings`.
+- Always answer: bug/behavior being fixed, PR/issue URL and affected surface, and best-fix verdict.
+- Keep summaries compact, but include enough proof that the verdict is auditable without rereading the PR.
+
+## Read beyond the diff
+
+- Review the surrounding code path, not just changed lines. Open the caller, callee, data contracts, adjacent tests, and owner module.
+- For large-codebase PRs, sample enough related files to understand the runtime boundary before deciding. Default to more code reading when the change touches agents, gateway, plugins, auth, sessions, process, config, or provider/runtime seams.
+- Compare the PR against current `origin/main` behavior. Check whether recent main already changed the same surface.
+- Dependency-backed behavior: MUST read upstream docs/source/types before judging API use, defaults, output shapes, errors, timeouts, memory behavior, or compatibility. Do not assume dependency contracts from memory or PR text.
+- Judge solution quality, not only correctness. Ask whether the PR is the clean owner-boundary fix or a wart/workaround that should be replaced by a small refactor, moved seam, contract change, or deletion of duplicate logic.
+- Mention the main files read when the verdict depends on code-path evidence.
+
 ## Enforce the bug-fix evidence bar
 
 - Never merge a bug-fix PR based only on issue text, PR text, or AI rationale.
@@ -193,6 +209,9 @@ gh search issues --repo openclaw/openclaw --match title,body --limit 50 \
 
 ## Follow PR review and landing hygiene
 
+- Never mention merge conflicts that are relatively easy to resolve, such as
+  `CHANGELOG.md` entries, in review-only output. These are landing mechanics,
+  not correctness findings.
 - If bot review conversations exist on your PR, address them and resolve them yourself once fixed.
 - Leave a review conversation unresolved only when reviewer or maintainer judgment is still needed.
 - When landing or merging any PR, follow the global `/landpr` process.
 
@@ -30,6 +30,7 @@
     "eslint/no-useless-computed-key": "error",
     "eslint/no-useless-concat": "error",
     "eslint/no-useless-constructor": "error",
+    "eslint/no-unused-vars": "off",
     "eslint/no-warning-comments": "error",
     "eslint/no-unmodified-loop-condition": "error",
     "eslint/no-new-wrappers": "error",