$ ~/registry/skill/openclaw-agents-skills-release-openclaw-ci

SKILL

release-openclaw-ci

Name: release-openclaw-ci
Author: openclaw

Run, debug, monitor, and summarize OpenClaw release CI workflows.

Stars

★ 382,582

Source

GitHub

Updated

2026-07-11

// securityCaution

Prompt only, no code
Open source
Community-trusted· 377.5k

Summary

Overall this appears to be an open-source, widely adopted, prompt-only skill with no required secrets or explicit external endpoints, so baseline risk is low. The main watchout is that it orchestrates GitHub Actions/gh commands and local validation steps, which are normal tool capabilities rather than a standalone high-risk red flag.

CredentialsLow risk

The material states no required secrets or environment variables; it only mentions reading/validating provider secrets, without requiring the skill itself to hold sensitive credentials, so credential risk is low.

Network egressCaution

No custom remote host is listed, but it does interact with GitHub via gh/workflows and may reach declared provider-check flows; this is normal network egress, with no unknown endpoint or unusual data exfiltration indicated.

Code executionCaution

The skill triggers local scripts, gh commands, and workflow dispatches, giving it ordinary local execution/process-calling ability; no extra system privileges beyond release validation are indicated.

Data accessCaution

It reads git status, commit hashes, and logs, and may inspect local/CI artifacts and provider status; this is typical release-audit data access, with no sign of excessive read/write scope.

Supply chainLow risk

The source is a GitHub open-source repository with extremely high community adoption (377k+ stars) and good visibility; although the license and maintenance status are unclear, there is no sign of closed-source opacity or suspicious prompt injection.

Recommendations

Only perform release/distribution actions with explicit authorization, especially GitHub release, tagging, and publishing.
Continue to follow least privilege and avoid writing unvalidated secrets into environment variables or 1Password.
Review the first failing CI/workflow and provider status before deciding whether code changes are needed.

Audited by: gpt-5.4 · 2026-06-17

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "release-openclaw-ci" skill from askskill:
1. Download https://raw.githubusercontent.com/openclaw/openclaw/main/.agents/skills/release-openclaw-ci/SKILL.md
2. Save it as ~/.claude/skills/release-openclaw-ci/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Run and monitor release CI

Prompt

Start the full OpenClaw release CI, monitor every stage continuously, and if anything fails, identify the failed step, summarize the error logs, and suggest likely causes.

Expected

A status report with CI progress, key stage updates, failed steps, and initial troubleshooting advice.

Check release preflight gates

Prompt

Run the OpenClaw release checks, including live provider gates, install/update proof verification, and release-secret preflights, then summarize all failed or blocked items.

Expected

Results for each release gate, pass/fail reasons, and a risk list of items that need action.

Generate a release issue summary

Prompt

Based on the OpenClaw release CI logs and check results, create a concise summary covering the overall outcome, major issues, impact scope, and recommended next steps.

Expected

A team-ready release summary that clearly communicates status and next actions.

// docs

OpenClaw Release CI

Use this with $release-openclaw-maintainer and $openclaw-testing when a release candidate needs full validation, install/update proof, live provider checks, or CI recovery.

Guardrails

No version bump, tag, npm publish, GitHub release, or release promotion without explicit operator approval.
Validate provider secrets before dispatching expensive full release matrices.
Do not set GitHub secrets from unvalidated 1Password candidates. If a candidate returns 401/403, leave the existing secret alone and report the exact missing provider.
Use $one-password for secret reads/writes: one persistent tmux session, targeted items only, no secret output.
Watch one parent run plus compact child summaries. Avoid broad gh run view polling loops; REST quota is easy to burn.
Fetch logs only for failed or currently-blocking jobs. If quota is low, stop polling and wait for reset.
Treat live-provider flakes separately from code failures: prove key validity, provider HTTP status, retry evidence, and exact failing lane before editing code.
Full Release Validation parent monitors fail fast: once a required child job fails, the parent cancels the remaining child matrix and prints the failed job summary. Inspect that first red job instead of waiting for unrelated matrix tails.

Preflight

Before full release validation:

node .agents/skills/release-openclaw-ci/scripts/verify-provider-secrets.mjs --required openai,anthropic,fireworks
gh api rate_limit --jq '.resources.core'
git status --short --branch
git rev-parse HEAD

1Password service-account values are the first source for release provider preflight. Inject those exact targeted keys first, then run the verifier; use ambient env only when it was already intentionally injected for this release. The script prints only provider status and HTTP class, never tokens.

Dispatch

Start product performance evidence as early as the release SHA exists, in parallel with other release work:

gh workflow run openclaw-performance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f target_ref=<release-sha> \
  -f profile=release \
  -f repeat=3 \
  -f deep_profile=false \
  -f live_openai_candidate=false \
  -f fail_on_regression=false

Do not wait for full release validation to start this early perf signal.
Compare available Kova, gateway startup, and CLI startup metrics with earlier release evidence or clawgrit reports before publish/closeout.
Call out any regression in the release proof. Treat a major regression as a release blocker until it is fixed, waived by the operator, or proven to be infrastructure noise.
Full Release Validation also records advisory product-performance evidence; the early standalone run is for overlap and faster regression discovery.

Prefer the trusted workflow on main, target the exact release SHA:

gh workflow run full-release-validation.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f ref=<release-sha> \
  -f provider=openai \
  -f mode=both \
  -f release_profile=full \
  -f rerun_group=all

Use release_profile=stable unless the operator explicitly asks for the broad advisory provider/media matrix. Use narrow rerun_group after focused fixes. Publish with openclaw-release-publish.yml using release_profile=from-validation unless a maintainer intentionally wants to cross-check a specific profile; the publish workflow reads the effective profile from the full-validation manifest.

Watch

Use the summary helper instead of repeated raw polling:

node .agents/skills/release-openclaw-ci/scripts/release-ci-summary.mjs <full-release-run-id>

Then watch only when useful:

gh run watch <full-release-run-id> --repo openclaw/openclaw --exit-status

Stop watchers before ending the turn or switching strategy.

Failure Triage

Confirm parent SHA and child run IDs.
List failed jobs only:

…

View full docs ↗

Run, inspect, debug, and extend OpenClaw QA scenarios and artifacts.

openclawGet→

$ loading_