Install
openclaw skills install github-actionsDesign, debug, and harden GitHub Actions workflows with reusable pipelines, safe permissions, and faster CI and release automation.
openclaw skills install github-actionsOn first activation, read setup.md to align auto-activation rules, repo shape, and mutation boundaries before editing workflows or triggering runs.
User needs GitHub Actions workflow design, debugging, hardening, release orchestration, runner strategy, matrix tuning, cache fixes, or reusable workflow architecture. Use this skill when the result depends on GitHub Actions semantics and GitHub delivery controls, not generic CI advice.
Memory lives in ~/github-actions/. See memory-template.md for the baseline structure.
~/github-actions/
|-- memory.md # Persistent repo context and activation boundaries
|-- repo-map.md # Repos, branches, package managers, and deploy targets
|-- workflow-defaults.md # Stable defaults for triggers, permissions, caches, and runners
|-- incidents.md # Failure signatures, root causes, and fixes
`-- release-rules.md # Promotion gates, approvals, and rollback notes
Load only the file needed for the current workflow problem.
| Topic | File |
|---|---|
| Setup and activation behavior | setup.md |
| Memory schema and status model | memory-template.md |
| Authoring patterns and reusable workflow shapes | workflow-patterns.md |
| Permissions, secrets, OIDC, and fork safety | security-model.md |
| Run failure triage and log-first debugging | debugging-playbook.md |
| Tag, release, and deployment orchestration | release-patterns.md |
| Caching, matrices, path filters, and runner efficiency | performance-tuning.md |
gh, jq, actNever ask the user to paste personal access tokens, cloud keys, or private signing material into chat.
YAML snippets in this skill are examples for repository workflow files.
References like ${{ github.* }}, ${{ inputs.* }}, ${{ vars.* }}, and ${{ secrets.* }} belong to GitHub Actions runtime, not to the agent runtime.
The agent should design around those placeholders but should not expect to read their values directly.
This skill covers GitHub Actions as an operating system for delivery:
push, pull_request, workflow_dispatch, schedule, and workflow_callLocal notes in ~/github-actions/ may include:
Before editing YAML, define:
Without that contract, workflows turn into step collections with unclear release behavior.
Declare permissions: at workflow or job level and grant only what that job needs.
Treat contents: write, packages: write, and id-token: write as exceptions that need a clear reason.
Keep pull request validation, artifact creation, release publishing, and production deployment as distinct responsibilities.
Use workflow_call or small reusable jobs instead of one oversized workflow that does everything.
Use concurrency for branch or environment scoped cancellation, add timeout-minutes, and filter noisy events with branch or path rules.
Minutes disappear quickly when redundant runs are left unbounded.
Cache package manager state, toolchains, and stable build outputs keyed by lockfiles or explicit versions. Use artifacts for job handoffs. Do not cache paths that depend on secrets, timestamps, or mutable deploy state.
Classify failures before rewriting workflows:
Fix the failure mode that exists, not the one that feels familiar.
Use GitHub environments, reviewer gates, and OIDC federation where possible.
Avoid long-lived cloud secrets, unreviewed workflow_dispatch deploys, and production writes from untrusted events.
ubuntu-latest quirks without version pinning -> sudden toolchain drift after runner image updates.| Endpoint | Data Sent | Purpose |
|---|---|---|
| https://github.com | repository metadata, git refs, workflow files, run pages, and artifact access | GitHub repository and Actions UI workflows |
| https://api.github.com | workflow, run, check, release, and repository API payloads | API-driven Actions inspection and control |
| Cloud or deployment endpoints explicitly configured by the workflow | deployment payloads, build artifacts, and short-lived auth tokens | Release and deploy steps after user approval |
No other data should be sent externally unless the workflow itself is configured to call additional services.
Data that leaves your machine:
Data that stays local:
~/github-actions/This skill does NOT:
SKILL.mdThis skill depends on GitHub and any deployment systems the user explicitly connects to their workflows. Only install and run it if you trust those systems with your repository and release data.
This skill ONLY:
This skill NEVER:
Install with clawhub install <slug> if user confirms:
ci-cd - Choose CI and deployment strategy before locking into one platform.git - Tighten branch, tag, and history handling around workflow events.workflow - Design multi-step execution systems with clearer ownership and gating.devops - Connect delivery pipelines to infrastructure and operational guardrails.docker - Improve container build, cache, and registry steps inside Actions workflows.clawhub star github-actionsclawhub sync