docs: keep maintainer leads hands-on (#121225)

.agents/skills/openclaw-pr-maintainer/SKILL.md

@@ -7,21 +7,21 @@ description: Use immediately for any pasted OpenClaw GitHub issue or PR URL/numb
 
 Use this skill for maintainer-facing GitHub workflows and the code changes needed to finish an authorized issue/PR repair; do not invoke it for unrelated ordinary code changes.
 
-## Parent orchestrates; collaboration subagents do all substantive work
+## The lead owns the outcome; collaboration workers extend it
 
-The original, user-facing root conversation is the orchestrator only. Delegate every substantive maintainer operation exclusively to bounded collaboration worker subagents; do not create separate Codex app/project threads or perform implementation work in the parent. A subagent assigned an execution role is the hands-on worker: it performs its scoped operations itself, retains personal inspection/verdict duties, and must not reinterpret this skill as requiring it to become another orchestrator or recursively delegate away ownership. Do not spawn nested helpers unless the root explicitly delegates and tracks them.
+The original, user-facing root conversation is the authoritative lead. It may personally inspect, implement, test, operate Git/GitHub, and land, or delegate bounded independent lanes when parallelism, isolation, specialist judgment, or independent challenge creates concrete value. Repository guidance to use collaboration workers does not make delegation mandatory or turn the lead into an orchestrator-only shell. Do not create separate Codex app/project threads. A subagent assigned an execution role performs its scoped operations itself, retains personal inspection/verdict duties, and must not recursively delegate away ownership unless the root explicitly authorizes and tracks that nested lane.
 
-- **Parent only:** decompose and prioritize the request; assign disjoint issue/root-cause/file ownership and explicit handoffs; enforce authorization, owner, security, source-trust, proof, and publication gates; coordinate resources and shared-checkout safety; collect and compare worker-reported evidence; dispatch independent verification; resolve routine decisions from existing authority and worker evidence; and communicate outcomes. Remain engaged until the requested close/fix/landing is verified complete or report the exact blocker.
-- **Workers only:** discover issues/PRs; inspect live GitHub state, complete affected source/owner/caller/sibling modules, tests, history, and dependency contracts; reproduce failures and establish root causes; edit, clean up, refactor, and write tests; run authorized tests, checks, CI, and live proof; execute Git/GitHub operations; post proof comments; close items; commit, push, prepare PRs, land fixes, and verify terminal remote state. Require a separate, independent worker to verify closure or landing whenever the active workflow mandates one; otherwise assign one to challenge consequential evidence, including already-fixed closures, when practical.
+- **Lead:** own the critical path and complete maintainer outcome; decompose and prioritize the request; personally perform serial, tightly coupled, or readily lead-owned work; assign disjoint independent lanes when useful; enforce authorization, owner, security, source-trust, proof, and publication gates; coordinate resources and shared-checkout safety; inspect actual repository/runtime effects; redirect, stop, replace, or correct weak work; dispatch independent verification; resolve routine decisions from existing authority and evidence; and communicate outcomes.
+- **Workers:** perform bounded hands-on investigation, implementation, proof, review, or delivery assignments when delegation creates concrete value. Their output remains provisional until the lead verifies the actual effect. Require a separate independent worker only when the active workflow mandates independent verification or consequential evidence genuinely benefits from challenge.
 - Bound worker count by available slots, including the parent's occupied slot, and safe host/proof capacity. Assign every worker a bounded scope and existing authorization; never infer broader permissions from delegation. Serialize shared fetch/ref/branch/checkout mutations, pushes, merges, and competing GitHub writes; never switch a shared checkout while siblings work or edit it while its Vitest run is in flight. Preserve unfinished worker state during reassignment. Existing untrusted-source isolation, remote-proof routing, owner approval, and landing requirements remain mandatory. These collaboration workers are not ClawSweeper's secretless internal review workers; ClawSweeper's deterministic GitHub App mutation and credential gates still apply.
 - Each acting or verdict-bearing worker personally inspects relevant dependency contracts. For Codex-backed behavior, that worker must personally inspect and cite the exact sibling `../codex` source before its own verdict, code change, public comment, approval, merge recommendation, or proof-sufficiency claim. The parent may relay evidenced worker conclusions but must not render an independent Codex verdict from worker reports.
-- Slow, stalled, or unavailable workers never authorize the parent to implement, investigate source, run proof, or mutate Git/GitHub. Coordinate, wait, safely reassign, or report the exact capacity, evidence, access, or authorization blocker.
+- Supervise workers through actual effects: shared-checkout diffs, processes, tests, runtime behavior, explicit checkpoints, terminal results, and liveness. Do not reduce supervision to repeated status reads or messages that reveal no new evidence. A slow, stalled, or unavailable worker may be redirected, replaced, or have its bounded lane taken over by the lead when shared-state and source-trust rules permit.
 
 ## Execute explicit full-authority work unattended
 
-When the user explicitly requests unattended or autonomous execution with full authority, that instruction is standing approval for evidence-backed operations within the requested task scope. The user is unavailable: never ask routine clarification, owner, approval, worktree, publication, CI, or landing questions. The parent remains orchestration-only; assigned hands-on workers resolve ordinary decisions and complete the work.
+When the user explicitly requests unattended or autonomous execution with full authority, that instruction is standing approval for evidence-backed operations within the requested task scope. The user is unavailable: never ask routine clarification, owner, approval, worktree, publication, CI, or landing questions. The lead resolves ordinary decisions and completes the work directly or through bounded workers.
 
-- Workers may investigate, repair/refactor, test, rewrite editable contributor PRs while preserving credit, create credited replacements when necessary, commit/push task-owned changes, update PRs, post proof, close items proven fixed on current `main`, diagnose/repair/rerun exact-head CI, create repo-managed PR worktrees or necessary task-owned isolated worktrees, run native review/prepare/merge, and verify terminal remote state.
+- The lead or bounded workers may investigate, repair/refactor, test, rewrite editable contributor PRs while preserving credit, create credited replacements when necessary, commit/push task-owned changes, update PRs, post proof, close items proven fixed on current `main`, diagnose/repair/rerun exact-head CI, create repo-managed PR worktrees or necessary task-owned isolated worktrees, run native review/prepare/merge, and verify terminal remote state.
 - Preserve unrelated dirty work. Use an isolated task-owned/native-managed worktree or nondestructive scoped publication; never stage, commit, stash, discard, overwrite, or synchronize unrelated files.
 - Continue through recoverable failures, stale guards, locks, and transient infrastructure problems with bounded safe retry and repository-approved lock recovery. Finish only after terminal verification; report a genuine missing capability, credential, or explicit safety gate without waiting for the unavailable user.
 - When optional live-provider/channel proof is unavailable **and the user explicitly relaxes that proof**, a bounded deterministic owner defect may instead use failing/passing owner-boundary regression tests, direct producer/caller/sibling and dependency/source inspection, independent review, and green required CI on the exact head. Record the missing live/rank-up proof; never describe substitutes as live. Mandatory live proof for external API work, security-sensitive behavior, explicitly requested live verification, or risk that requires authenticated execution is never waived.
@@ -60,7 +60,7 @@ gitcrawl cluster-detail openclaw/openclaw --id <cluster-id> --member-limit 20 --
 
 ## Inspect specific targets; claim only when authorized
 
-When a maintainer asks Codex to review, triage, fix, or land a specific OpenClaw issue/PR, have the assigned collaboration worker inspect live assignment before deep work. Assignment itself is a public GitHub write.
+When a maintainer asks Codex to review, triage, fix, or land a specific OpenClaw issue/PR, have the lead or assigned collaboration worker inspect live assignment before deep work. Assignment itself is a public GitHub write.
 
 - Identify the requesting maintainer's GitHub login. In this environment, default Peter to `steipete`; if another maintainer is clearly the requester, use that maintainer's bare login.
 - Read current assignees with live `gh issue view` / `gh pr view`; `gitcrawl` is not enough for assignment state.
@@ -172,7 +172,7 @@ Exceptions:
 
 When explicitly asked for `X` small, easy, or narrowly scoped issues or PRs to triage, `X` means qualified candidates, not sampled threads. These shortlist filters do not apply to a confirmed issue/PR selected for end-to-end repair; do not reject its correct root-cause fix merely because a coherent owner-boundary refactor is required.
 
-Plain review, triage, listing, and shortlist requests are read-only: workers inspect and report candidates without editing files or mutating GitHub. Only an explicit scoped fix request authorizes this patch-local/proof flow; shipping and public writes still require separate approval:
+Plain review, triage, listing, and shortlist requests are read-only: the lead or workers inspect and report candidates without editing files or mutating GitHub. Only an explicit scoped fix request authorizes this patch-local/proof flow; shipping and public writes still require separate approval:
 
 1. Review the issue body, comments, related threads, current code, and adjacent tests.
 2. Fix only shortlisted issues whose root cause and owning architectural neighborhood are high-confidence.