home / skills / yldgio / codereview-skills / github-actions
This skill helps you harden GitHub Actions by enforcing security, performance, and best-practice workflows across automation tasks.
npx playbooks add skill yldgio/codereview-skills --skill github-actionsReview the files below or copy the command above to add this skill to your agents.
---
name: github-actions
description: GitHub Actions workflow security, performance optimization, and best practices
---
## GitHub Actions Code Review Rules
### Security (Critical)
- Pin actions to full commit SHA (not `@v1` or `@main`)
- Use minimal `permissions` block (principle of least privilege)
- Never echo secrets or use them in URLs
- Use `secrets.GITHUB_TOKEN` instead of PATs when possible
- Audit third-party actions before use
- Review expressions (`${{ }}`) for injection risks; never interpolate untrusted user input
- Validate all inputs to reusable workflows and custom actions
### Permissions
```yaml
permissions:
contents: read # Minimal by default
# Add only what's needed:
# pull-requests: write
# issues: write
```
### Secrets
- Store secrets in repository/organization secrets
- Use environments for production secrets with approvals
- Don't pass secrets as command arguments (visible in logs)
- Mask sensitive output with `::add-mask::`
- **Never write secrets to files or artifacts** (can be exposed)
- Avoid passing secrets via environment variables unless absolutely required
- Secrets in env vars can be visible in process listings
### Performance
- Use caching for dependencies (`actions/cache` or built-in)
- Run independent jobs in parallel
- Use `concurrency` to cancel redundant runs
- Consider self-hosted runners for heavy workloads
### Workflow Structure
- Use reusable workflows for common patterns
- Use composite actions for shared steps
- Set appropriate `timeout-minutes` to prevent hung jobs
- Use `if:` conditions to skip unnecessary jobs
- Separate CI (testing), CD (deployments), and PR checks into distinct workflows
- Use environments to distinguish between dev, staging, and production
- Avoid mixing all concerns in a single monolithic workflow
### Triggers
- Be specific with `paths` and `branches` filters
- Use `workflow_dispatch` for manual triggers
- Consider `pull_request_target` security implications
### Common Anti-patterns
- Avoid `actions/checkout` with `persist-credentials: true` unless needed
- Avoid running on `push` to all branches
- Avoid hardcoding versions that need updates
### Action Updates and Maintenance
- Monitor pinned action SHAs for security fixes
- Subscribe to security advisories for actions you use
- Update actions regularly to get new features and fixes
- Document why specific SHAs are pinned (security, stability)
- Consider using Dependabot for action version updates
### Testing and Validation
- Lint workflows with tools like `actionlint`
- Test complex workflows in feature branches before merging
- Validate workflow syntax before committing
- Use workflow templates for consistency
- Add job-level tests for workflow logic validation
### Error Handling
- Use `continue-on-error: false` as default (explicit failure)
- Set `fail-fast: true` for matrix jobs to stop on first failure
- Only use `continue-on-error: true` when failure is acceptable
- Provide clear error messages in job outputs
- Use status checks to ensure critical jobs pass
### Documentation
- Add inline comments for complex workflow logic
- Document workflow purpose and triggers
- Maintain workflow README or documentation
- Explain environment variables and their usage
- Document required secret names and their purpose (never include actual secret values)
This skill provides actionable guidance to secure, optimize, and maintain GitHub Actions workflows. It focuses on concrete rules for secrets, permissions, performance, triggers, and maintainability. Use it to harden CI/CD pipelines, reduce runtime costs, and enforce reliable workflow design.
The skill inspects workflow definitions and provides recommendations based on best practices: pinning action SHAs, least-privilege permissions, secrets handling, caching, and job structuring. It highlights risky patterns like unpinned actions, exposed secrets, excessive permissions, and inefficient job layouts, and suggests concrete fixes and configuration options. It also recommends tools and processes for testing, linting, and ongoing maintenance.
Why pin actions to full SHAs instead of using tags?
Full SHAs ensure immutability and prevent unexpected behavior or supply-chain changes when an action maintainer updates a tag. Document the reason for each pin to balance security and maintenance.
Can I ever expose secrets in logs or artifacts?
Never. Secrets must not be printed, written to files, or stored in artifacts. Use add-mask and avoid passing secrets as plain CLI args or unmasked env vars; prefer in-process use where possible.