// Use when creating, modifying, or reviewing GitHub Actions workflow files. Covers workflow syntax, action selection, dependabot configuration, and CI/CD best practices.
| name | github-actions |
| description | Use when creating, modifying, or reviewing GitHub Actions workflow files. Covers workflow syntax, action selection, dependabot configuration, and CI/CD best practices. |
| license | MIT |
| metadata | {"author":"Robert Hafner","source":"https://github.com/tedivm/opencode-config"} |
All GitHub Actions workflows must follow these rules. Apply them every time a workflow file is created or modified.
Always set fail-fast: false. Add fail-fast: false to every strategy block so a failure in one matrix job does not cancel the others. All jobs should run to completion regardless of failures.
Always use the latest versions of actions. Before referencing any action, look up its latest release tag and resolve it to a commit SHA using gh. Run both commands for each action:
# Step 1: Get the latest release tag
gh api repos/{owner}/{repo}/releases/latest --jq '.tag_name'
# Example: gh api repos/actions/checkout/releases/latest --jq '.tag_name'
# Output: v6.0.2
# Step 2: Resolve the tag to a commit SHA
gh api repos/{owner}/{repo}/git/ref/tags/{tag} --jq '.object.sha'
# Example: gh api repos/actions/checkout/git/ref/tags/v6.0.2 --jq '.object.sha'
# Output: de0fac2e4500dabe0009e67214ff5f5447ce83dd
Pin to a full commit SHA, never a branch or mutable tag like v3 or main.
Do not skip this step. Action versions change frequently. Using outdated versions introduces security and compatibility risks.
Always add Dependabot for GitHub Actions. If .github/dependabot.yml does not exist or lacks a GitHub Actions ecosystem entry, create or update it:
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "monthly"
This ensures action versions stay current automatically.
Only use trusted actions. Restrict third-party actions to:
actions/checkout, actions/upload-artifact, etc.)docker/, google-github-actions/, aws-actions/)Always use language setup actions. Never assume a runner has the required language runtime or tooling installed. Use the official setup actions before any build, test, or install steps. Look up the latest version of each action using gh before referencing it:
actions/setup-nodeastral-sh/setup-uv (preferred) or actions/setup-pythonactions/setup-goactions/setup-rubyactions/setup-javaactions-rs/toolchainshivammathur/setup-phpPin the version explicitly using the project's version file (.node-version, .python-version, go.mod, Gemfile, etc.) or a hardcoded version.
Never use obscure personal repositories, unmaintained forks, or actions without clear ownership and active maintenance.
Use this structure for new workflows:
name: Test
on:
push:
branches: [main]
pull_request:
branches: [main]
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
python-version: ["3.11", "3.12", "3.13"]
steps:
- uses: actions/checkout@<sha>
- uses: astral-sh/setup-uv@<sha>
with:
python-version: ${{ matrix.python-version }}
enable-cache: true
- run: uv sync
- run: uv run pytest
permissions at the workflow level, not per-jobubuntu-latest as the default runner unless a specific OS is requiredactions/cache or actions/setup-* built-in cachingconcurrency groups to prevent duplicate runs on the same branch when needed::group:: and ::endgroup:: annotations| Action | Purpose |
|---|---|
actions/checkout | Check out repository code |
actions/setup-node / setup-python / setup-go / setup-ruby / setup-java | Language runtime setup |
actions-rs/toolchain | Rust toolchain setup |
shivammathur/setup-php | PHP setup |
actions/upload-artifact / download-artifact | Job artifact sharing |
actions/cache | Dependency caching |
docker/build-push-action | Docker image builds |
docker/login-action | Container registry authentication |
ghfail-fast: false on matrix jobs.github/dependabot.yml — add a GitHub Actions ecosystem entry if missingactionlint or yq eval '.' .github/workflows/<file>.yamlUse when bootstrapping the design of a brand new project — producing a plan.md through iterative exploration. Don't use for modifying existing plans, implementing features, or working with established codebases.
Use when creating or modifying custom opencode commands in the `commands/` directory. Covers markdown command files, frontmatter options (description, agent, model, subtask), prompt templates with $ARGUMENTS, shell output injection, and file references.
Use when creating a new Python project from Rob's Awesome Python Template (cookiecutter). Don't use for adding Python to existing projects, installing packages, or working with established codebases.
Use when asked to create, generate, or scaffold a new Agent Skill. Don't use for modifying existing skills or writing general documentation.
Use when doing a thorough exploration of an existing codebase. Guides a subagent through reading documentation, reviewing tests, analyzing architecture, and producing a comprehensive overview. Don't use for quick lookups or single-file questions.
All actions on GitHub must use this skill. Covers pull requests, issues, repositories, releases, GitHub Actions, searches, and API requests via the `gh` CLI.