Global Repo Triage

OpenClaw Windows Node Global Triage

Run a complete maintainer triage of openclaw/openclaw-windows-node. Read every open issue and pull request, identify safe landing lanes, schedule OpenClaw's Windows proof pools, and produce the same evidence-backed Markdown report used for the August 27 and September 1 maintainer sweeps. Open the interactive OpenClaw triage canvas when the user requests it as an additional handoff.

This skill is repository-specific. If the current repository is not openclaw/openclaw-windows-node, stop and say that this skill applies only to the OpenClaw Windows Node repository.

Trigger

Use when the user asks for:

• global triage, backlog triage, or a full repository sweep
• today's OpenClaw landing queue
• low-hanging issues or PRs
• what Karen or another maintainer can do in parallel
• release-train contents or a correction-release decision
• a comparison with a prior OpenClaw triage report

Required output

Create these session artifacts:

global-triage-YYYY-MM-DD.md
triage-YYYY-MM-DD\issues-summary.csv
triage-YYYY-MM-DD\prs-summary.csv
triage-YYYY-MM-DD\pr-<number>.patch

Keep raw JSON when practical. Do not add triage artifacts to the repository. Use templates\global-triage-report.md as the report skeleton and examples\global-triage-2026-08-27.md plus examples\global-triage-2026-09-01.md as quality references. Use templates\triage-state.template.json only when producing the optional interactive dashboard.

Ground rules

1. Read-only unless explicitly authorized. Do not merge, close, label, comment, push, rerun CI, or create sessions from a triage request alone.
2. Cover the entire backlog. Fetch every open issue and PR. A report is not global if fetched and classified counts differ.
3. Read discussions and code. For every item that could be taken, closed, repaired, or assigned, inspect the body, comments, reviews, inline threads, timeline, checks, files, commits, and patch.
4. Use the 90% TAKE bar. Safe-looking is not enough. TAKE requires clear value, bounded scope, current-head validation, and no missing custom proof.
5. ClawSweeper is advisory. Read its durable review comment and labels, then independently verify each finding. Do not wait solely for bot wording when exact-head source review, proof, required validation, and branch protection establish safety.
6. Do not blame a PR for a baseline flake. Compare a failing test with the changed surface, the exact base commit, nearby main runs, and focused local reproduction. Rerun only after identifying the likely owner.
7. Never treat unavailable proof as passed. Report it as NEEDS_HUMAN_TEST or Not verified / blocked.
8. Do not revive stale architecture wholesale. Transplant the smallest useful fix onto current owners rather than rebasing obsolete god-object or pre-ledger branches.
9. Canvas actions are requests, not mutations. The dashboard may refresh read-only GitHub state and route a guarded action request to one dedicated child project session per item. Reuse that session for later actions on the same PR or issue. The dashboard must never merge, close, label, comment, push, rerun CI, or delete a session directly.

Decision vocabulary

Report both take confidence and recommendation confidence. A confident HOLD or DECLINE is not a high take-confidence item.

1. Start from the repository's own triage data

Read:

• AGENTS.md
• docs\REPOSITORY_TRIAGE.md
• docs\PROOF_POOLS.md
• docs\TEST_COVERAGE.md
• docs\ARCHITECTURE.md
• docs\RELEASING.md when a release is in scope

Confirm the deterministic triage implementation is healthy:

node --test .github\scripts\repository-triage.test.cjs .github\extensions\openclaw-triage-dashboard\triage-state.test.mjs

Prefer the latest successful scheduled Repository Triage Report artifact as the inventory baseline:

$repo = "openclaw/openclaw-windows-node"
gh run list --repo $repo --workflow repository-triage.yml --limit 10
gh run download <run-id> --repo $repo --name repository-triage-report `
  --dir <session-artifact-dir>\triage-YYYY-MM-DD\scheduled

If the artifact is missing, stale, or partial, fetch directly with gh. Preserve collection warnings. Never silently omit an item after an API failure.

2. Build complete summaries

Fetch all open work with pagination:

gh issue list --repo $repo --state open --limit 1000 `
  --json number,title,author,labels,assignees,createdAt,updatedAt,url,comments
gh pr list --repo $repo --state open --limit 1000 `
  --json number,title,author,labels,createdAt,updatedAt,url,reviewDecision,mergeable,isDraft,baseRefName,headRefName,additions,deletions,changedFiles,statusCheckRollup

Write CSV summaries matching the proven artifacts.

PR columns:

N,Title,Author,Draft,Merge,Review,Files,Delta,Failed,Pending,Labels

Issue columns:

N,Title,Author,Labels,Comments,Updated

For every potentially actionable PR:

gh pr view <number> --repo $repo `
  --json number,title,author,body,url,state,isDraft,mergeable,mergeStateStatus,reviewDecision,baseRefName,headRefName,headRefOid,additions,deletions,changedFiles,files,commits,comments,reviews,statusCheckRollup,labels,createdAt,updatedAt
gh pr diff <number> --repo $repo --patch > <artifact-dir>\pr-<number>.patch

Also inspect unresolved inline threads and relevant timeline events. A ClawSweeper comment may be edited in place, so use its current updated_at and reviewed head SHA rather than assuming the oldest comment body is stale.

3. Classify OpenClaw-specific risk

Apply the repository's current owners and guardrails:

Bot, Copilot, repo-assist, and ClawSweeper-authored PRs are untrusted contributions. Do not lower the bar because automation produced them.

4. Map required proof pools

Select every applicable pool from .github\proof-pools.json:

PR bodies must contain:

• ## Required proof pools
• ## Validation
• ## Real behavior proof

Proof declarations schedule work. They do not prove it ran.

5. Apply the OpenClaw validation floor

Every code change needs:

$env:OPENCLAW_REPO_ROOT = (Get-Location).Path
.\build.ps1
dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj --no-restore
dotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj --no-restore

Fresh worktrees must restore or build a test project before trusting --no-restore.

Add the focused owner suite:

• connection: OpenClaw.Connection.Tests
• setup: OpenClaw.SetupEngine.Tests
• WinUI: focused Tray tests plus UI/accessibility proof
• node/MCP docs or output: OpenClaw.WinNode.Cli.Tests
• setup/connect/recovery: relevant OpenClaw.E2ETests shard
• MXC or system.run: .\scripts\validate-mxc-e2e.ps1

For non-trivial setup, pairing, UI, MCP, permission, security, or diagnostics work, require rubber-duck review and final autoreview.

6. Audit ownership and duplicate work

status: 🚢 actively landing means a maintainer or delegated agent is actively implementing, validating, or merging now.

In the report:

• name the owner or label actor
• identify linked open PRs
• warn against duplicate fixes
• flag ownership with no trusted human activity for 7 full days
• never suggest automatic removal for P0, security, no-stale, assigned, or provenance-incomplete items

Do not mutate labels during report-only triage. If the user authorizes cleanup, use the repository workflow's guarded remove-expired-active-ownership operation rather than ad hoc label removal.

7. Review likely landing candidates

Use direct review for small changes. Invoke hanselman-code-review for:

• more than 300 changed lines
• security, auth, setup, storage, release, signing, installer, shell, MXC, concurrency, or data-loss risk
• bot/repo-assist changes beyond a trivial dependency bump
• conflicting GitHub state or disputed findings
• any candidate below 95% recommendation confidence that might still be taken

Cross-reference both reviewers in the report, then verify each accepted finding against the code. Do not paste raw reviewer output as the decision.

8. Build the landing and release plan

Order work by dependency, not PR number:

1. release blockers and current user breakage
2. small green fixes with clear ownership
3. coordinated trains where one PR changes the next PR's base
4. repair/transplant lanes
5. custom proof lanes
6. closure and stale-label cleanup

Use one isolated worktree/session per PR. Keep dependent PRs serial. Parallelize independent implementation and human proof. Do not force-push contributor branches; use a current-main maintainer replacement when the original branch cannot be advanced safely.

For each active landing:

• apply status: 🚢 actively landing
• merge current origin/main when the base changed
• rerun exact-head validation and proof
• update the PR body
• resolve or explicitly disposition review findings
• verify GitHub state after merge
• remove the active label and archive the work session

If CI fails only in unchanged infrastructure:

1. inspect the exact failed test and log
2. compare with the exact base or nearby main run
3. run the focused test locally
4. check whether a fix has since landed on main
5. refresh the branch before rerunning stale-base CI

For release planning:

• compare the latest tag with main
• list which candidate PRs are already shipped
• prefer a narrow correction for a bounded user-facing fix
• exclude broad localization, feature, refactor, conflicted, or unproven work
• tag only exact origin/main
• never move or reuse a published tag
• require x64/ARM64 signed installer and portable ZIP verification

9. Write the proven report format

The Markdown report must use this order:

1. # OpenClaw Windows Node global triage
2. Snapshot sentence with exact open issue and PR counts plus collection scope
3. ## Change since <prior date>
4. ## Executive queue
5. ## Pull requests
6. ## Issues
7. ## Active ownership audit
8. ## Adversarial review for selected risky candidates
9. ## Day plan
10. ## Automation and testability

The PR table columns are:

Item | Type / signal | Decision | Take confidence |
Recommendation confidence | Effort | Risk | Owner / required validation

The issue table columns are:

Item | Signal | Decision | Take confidence |
Recommendation confidence | Effort | Risk | Owner / next action

Every row needs a concrete owner and next action. Cover all open items, including low-priority and declined work.

10. Optionally publish the interactive dashboard

Only produce the interactive canvas when the user requests it in addition to the static Markdown report. Create global-triage-YYYY-MM-DD.json as its session state artifact.

Write global-triage-YYYY-MM-DD.json using templates\triage-state.template.json. Every item needs:

• its PR or issue number, title, URL, decision, both confidence values, effort, risk, owner, and concrete next action
• exact reviewed head SHA for PRs
• expected required check names for PRs; issues must use an empty expectedChecks array
• review status and proof status
• every applicable proof-pool ID, validated against .github\proof-pools.json
• dependencies on other items in the same triage

Populate report so the dashboard tabs preserve the report template's decision context:

• changes
• ownership
• reviews
• automation

Use plan as the single ordered execution plan. Set each step's optional horizon to today or later; omitted values default to today. A plan step may declare dependsOn with other plan-step IDs and gates that point to an item's inventory, review, checks, proof, or landing stage. Dependencies must form an acyclic graph. The landing stage applies only to pull requests. The canvas derives each gated step's live status whenever GitHub checks change. It renders connected steps as dependency lanes and independent steps as parallel work. Plan order breaks ties within a lane. Do not repeat plan steps in report.

Then:

1. Call list_canvas_capabilities for openclaw-triage-dashboard.
2. Open openclaw-triage-dashboard with the JSON object as input and use a stable instance ID such as global-triage-YYYY-MM-DD.
3. Reopen that same instance ID whenever triage decisions, proof status, review status, expected checks, or plan steps change.
4. Leave the canvas open. It refreshes GitHub PR and issue state at the declared 30-to-300-second interval and pushes updates to the panel.

The canvas exposes:

• search and readiness filters
• live check totals and missing expected jobs
• item stages and plan-gate status
• proof, review, exact-head, draft, and mergeability gates
• Request next step, which creates or reuses the item's child project session and sends a read-only-by-default request there
• Prepare merge, enabled only for an exact-head TAKE at 90% or higher with complete review and proof, clean merge state, and all expected checks present and passing

Prepare merge must only ask the item's child session to re-fetch evidence and request explicit confirmation. Every item action uses the same routing rule: find the exact Triage PR #<number> or Triage Issue #<number> session and append to it, or create it once when absent. The extension never calls a GitHub mutation command.

Completion bar

Do not call the triage complete until:

• open issue and PR counts match the report rows
• actionable discussions, reviews, checks, and patches were inspected
• current-head versus stale-head evidence is distinguished
• issue-to-PR ownership and duplicate risks are mapped
• active ownership is audited
• proof pools and human hosts are scheduled explicitly
• a numbered day plan identifies safe parallelism and dependency order
• release contents and exclusions are explicit when a release is discussed
• the Markdown report, CSV summaries, and reviewed PR patches are saved

When the optional dashboard was requested, also require:

• the versioned triage-state JSON is saved
• the dashboard opens successfully and its fetched item count matches the state artifact
• every plan gate references an item and stage in the state artifact
• item actions remain child-session-routed and merge requests stay confirmation-gated