I. Skill Overview

1. Trigger the full-release-validation.yml workflow to execute full-matrix release validation
2. Spin up the openclaw-performance.yml performance test workflow in parallel to collect performance benchmark evidence
3. Monitor workflow runtime status and aggregate results from all child subtasks
4. Run targeted root-cause triage for failed jobs instead of blindly re-running entire pipelines
5. Log a complete immutable audit trail of release evidence (commit SHA, workflow run URL, subtask outcomes, provider preflight check results, etc.)

II. Core Functional Capabilities

1. Preflight Release Pre-Checks

• Provider secrets must be fully validated prior to scheduling expensive full release matrix jobs
• 1Password service account credentials are the primary trusted source for release provider preflight checks
• Inject the exact required API keys first, then execute the validation script
• Anthropic validation runs a minimal single-turn message completion test. Expired or non-billable credentials will fail fast during preflight, avoiding wasted CI resources on heavy release matrix runs
• The validator only prints provider connectivity status and HTTP response categories; raw token values are never printed to logs or output

2. Parallel Performance Evidence Collection

• Do not wait for full release validation to finish before launching performance benchmarking
• Compare Kova initialization, gateway startup, and CLI boot metrics against historical baseline release evidence
• Severe performance regressions are treated as hard release blockers until the regression is fixed, waived by an operator, or proven to stem from transient infrastructure noise

3. Full Release Validation Workflow Dispatch

• For immutable workflow provenance on an active moving main branch, use pnpm ci:full-release --sha <SHA>. Its standardized release-ci/* reference retains precise reusable evidence after validating the workflow commit originates from the trusted main branch.
• Use release_profile=stable unless the operator explicitly requests a broader advisory provider/media test matrix.
• Both stable and full profiles enforce mandatory release soak testing; the beta profile enables soak testing optionally via run_release_soak=true.
• Official production releases utilize openclaw-release-publish.yml with release_profile=from-validation; the publishing workflow reads the validated profile from the full release validation manifest.

4. Lightweight Watch & Result Summarization

• Monitor a single parent workflow run with compact aggregated child task summaries
• Avoid broad, high-frequency gh run view polling loops that rapidly deplete GitHub REST API quotas
• Only fetch detailed logs for failed or currently blocking jobs
• Halt all polling activity and wait for quota reset if API rate limits are exhausted

5. Failure Classification & Targeted Triage

Step 1: Enumerate all failed child jobs

Step 2: Pull full logs for one failed job. If rate-limited, record the quota reset timestamp and pause all additional REST API calls.

Step 3: Classify failures by root cause category with dedicated handling logic

1. Secret-related failures: Validate real-time model completions using the identical secret before modifying source code. Successful model-list API calls are insufficient proof of valid billing credentials. Claude CLI subscription authentication relies on a separate native auth pathway that must be verified via a clean isolated CLI probe and cannot substitute the mandatory Anthropic API-key validation lane.
2. Live-cache failures: Diagnose root cause as missing/invalid credentials, empty text payloads, provider-side rejection, request timeout, or baseline cache mismatch.
3. Transient live-provider flakiness: Handled separately from permanent code defects. Verify credential validity, provider HTTP status codes, retry evidence, and the exact failing test lane before modifying source code.
4. Full Release Validation parent workflow behavior: The parent cancels all remaining child matrix jobs once a mandatory subtask fails and outputs a summary of failed jobs. Investigate the first failed red job first, rather than waiting for unrelated trailing matrix entries to complete.

6. Source Sync & Testbox Lifecycle Governance

1. First validate the existence of package.json, pnpm-lock.yaml, and every source file path accessed by active validation checks. Missing files render the checkout incapable of verifying release dependency integrity or Docker build lanes. Halt execution and fall back to either remote repo changed gate checks or full complete task worktree cloning.
2. If the input contains a release patch modifying package.json or pnpm-lock.yaml, rebuild only the disposable task-owned Testbox instance. Run CI=true pnpm install --frozen-lockfile, then execute explicit require.resolve() probe validation.
3. The CI environment flag allows pnpm to recreate pre-warmed module directories without interactive prompts, but must not relax lockfile integrity rules or mark sparse checkout failures as production/Docker build failures.
4. If the release candidate undergoes rebasing or its base commit SHA changes after Testbox warmup, terminate the existing task-owned Testbox instance and provision a fresh pre-warmed environment before running validation tests.
5. Testbox reuse is strictly provenance-gated: Environments may be re-leased only for source-code-only edits. Any changes to base commits, dependencies, wrapper logic, or Testbox workflow drift require a brand-new fresh lease. Never set OPENCLAW_TESTBOX_ALLOW_STALE=1 for official release evidence collection.
6. For finalized committed release candidates, warm Testbox environments via blacksmith testbox warmup ... --ref .. Do not rely on automatic source sync to overwrite committed branch changes onto the workflow’s default reference.

7. Fallback Handling for Stalled PR CI Gates

• Do not cancel unrelated workflows or trigger generic manual workflow dispatches.
• Schedule an explicit exact-SHA fallback workflow from the PR’s head branch:

• Log both the stalled original Blacksmith workflow run and the fallback run in the release audit trail.
• If the only remaining mandatory gate is a Blacksmith Build Artifact Testbox stuck indefinitely in queue with no available runners, a fully completed exact-SHA fallback run may serve as a substitute. This substitution is prohibited if the artifact workflow has launched or failed to complete successfully.

III. Primary Use Cases

1. Full End-to-End Release Candidate Validation
    
   Trigger full matrix release validation workflows prior to every beta, stable, or reissued release, ensuring all mandatory CI checks, provider integrations, and performance benchmarks pass successfully.
2. Release CI Failure Triage & Recovery
    
   Systematically locate the first failed job, pull diagnostic logs, classify root causes (secret credential errors, live-provider flakiness, source sync failures, etc.), apply narrow targeted patches, and re-run validation pipelines.
3. Performance Regression Detection
    
   Launch performance benchmarking workflows in parallel early in the release pipeline, compare results against historical baselines, and flag severe performance regressions as hard release blockers.
4. Provider Secret Preflight Validation
    
   Validate all required LLM provider credentials (OpenAI, Anthropic, Fireworks, etc.) before dispatching resource-heavy release matrix jobs, eliminating wasted CI resources caused by credential failures.
5. GitHub API Quota Conservation
    
   Minimize REST API consumption via condensed summary monitoring, targeted log retrieval limited to failed jobs, and throttled polling frequency to avoid hitting GitHub rate limits.

IV. Cross-Skill Collaboration Matrix

V. Critical Governing Principles

1. No Unauthorized Release Execution: This skill never performs version bumping, tag creation, npm publishing, GitHub release creation, or release promotion. All production release actions require explicit operator approval.
2. Validate Secrets First, Schedule Matrix Second: Provider credential preflight checks are mandatory before dispatching expensive full release matrix workflows.
3. Preserve Valid Existing Secrets: If candidate credentials return 401/403 unauthorized errors, retain the original active secret intact and report the exact missing provider identity.
4. Prevent API Quota Exhaustion: Monitor a single parent workflow with compact aggregated child summaries; avoid broad high-frequency gh run view polling loops.
5. Prioritize First Failed Job: The Full Release Validation parent cancels remaining child matrix jobs after the first subtask failure; always triage the initial red failure first.
6. Strict Testbox Provenance Rules: OPENCLAW_TESTBOX_ALLOW_STALE=1 must never be enabled for official release evidence collection.
7. Model List API Responses Are Not Billing Proof: Successful model-list calls only verify basic authentication, not valid billing or inference entitlements. Mandatory live provider lanes must pass a real message completion probe before release workflow dispatch.

VI. Mandatory Release Evidence Logging Requirements

1. Target release commit SHA
2. Full parent validation workflow run URL
3. Child workflow run IDs and final conclusions: Core CI, Release Checks, Plugin Prerelease, NPM Telegram, Product Performance
4. Performance comparison results against historical baseline releases (if applicable)
5. Targeted local validation proof command outputs
6. Full provider-secret preflight check results
7. Documented known gaps or unrelated non-blocking failures

VII. Summary