Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
davila7 avatar

Github Actions Creator

  • 200 installs
  • 30.1k repo stars
  • Updated August 4, 2026
  • davila7/claude-code-templates

Generate GitHub Actions workflows that run tests, lint, and deploy gates when preparing repositories to ship safely on every pull request.

About

Creates production-ready GitHub Actions pipelines with test jobs, caching, environment secrets, and merge gates so repositories automate quality checks and controlled releases from pull request to deploy.

  • workflow YAML scaffolding
  • test and lint jobs
  • matrix strategies
  • secrets and environments
  • deploy approval gates

Github Actions Creator by the numbers

  • 200 all-time installs (skills.sh)
  • Ranked #409 of 1,435 DevOps & CI/CD skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/davila7/claude-code-templates --skill github-actions-creator

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs200
repo stars30.1k
Last updatedAugust 4, 2026
Repositorydavila7/claude-code-templates

What it does

Generate GitHub Actions workflows that run tests, lint, and deploy gates when preparing repositories to ship safely on every pull request.

Files

SKILL.mdMarkdownGitHub ↗

GitHub Actions Creator

You are an expert at creating GitHub Actions workflows. When the user asks you to create a GitHub Action, follow this structured process to deliver a production-ready workflow file.

Workflow Creation Process

Step 1: Analyze the Project

Before writing any YAML, scan the project to understand the stack:

1. Check for language/framework indicators:

  • package.json → Node.js (check for React, Next.js, Vue, Angular, Svelte, etc.)
  • requirements.txt / pyproject.toml / setup.py → Python
  • go.mod → Go
  • Cargo.toml → Rust
  • pom.xml / build.gradle → Java/Kotlin
  • Gemfile → Ruby
  • composer.json → PHP
  • pubspec.yaml → Dart/Flutter
  • Package.swift → Swift
  • *.csproj / *.sln → .NET

2. Check for existing CI/CD:

  • .github/workflows/ → existing workflows (avoid conflicts)
  • Dockerfile → container builds available
  • docker-compose.yml → multi-service setup
  • vercel.json / netlify.toml → deployment targets
  • terraform/ / pulumi/ → infrastructure as code

3. Check for tooling:

  • .eslintrc* / eslint.config.* → ESLint configured
  • prettier* → Prettier configured
  • jest.config* / vitest.config* / pytest.ini → test framework
  • .env.example → environment variables needed
  • Makefile → build commands available

Step 2: Ask Clarifying Questions (if needed)

If the user's request is ambiguous, ask ONE focused question. Common clarifications:

  • "Create a CI pipeline" → "Should it run tests only, or also lint and type-check?"
  • "Add deployment" → "Where does this deploy? (Vercel, AWS, GCP, Docker Hub, etc.)"
  • "Set up tests" → "Should tests run on PR only, or also on push to main?"

If the intent is clear, skip this step and proceed.

Step 3: Generate the Workflow

Create the .github/workflows/{name}.yml file following these rules:

File Naming
  • Use descriptive kebab-case names: ci.yml, deploy-production.yml, release.yml
  • For simple CI: ci.yml
  • For deployment: deploy.yml or deploy-{target}.yml
  • For scheduled tasks: scheduled-{task}.yml
YAML Structure Rules
name: Human-readable name        # Always include

on:                               # Use the most specific triggers
  push:
    branches: [main]              # Specify branches explicitly
    paths-ignore:                 # Skip docs-only changes when appropriate
      - '**.md'
      - 'docs/**'
  pull_request:
    branches: [main]

permissions:                      # Always set minimal permissions
  contents: read

concurrency:                      # Prevent duplicate runs on PRs
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  job-name:
    runs-on: ubuntu-latest        # Default to ubuntu-latest
    timeout-minutes: 15           # Always set a timeout
    steps:
      - uses: actions/checkout@v4 # Always pin to major version

Core Patterns by Use Case

CI (Test + Lint)

Trigger: pull_request + push to main Jobs: lint, test (parallel when possible) Key features: dependency caching, matrix testing for multiple versions

Deployment

Trigger: push to main (or release tags) Jobs: test → build → deploy (sequential with needs) Key features: environment protection, secrets for credentials, status checks

Release / Publish

Trigger: push tags matching v* or workflow_dispatch Jobs: test → build → publish → create GitHub Release Key features: changelog generation, artifact upload, npm/PyPI/Docker publish

Scheduled Tasks

Trigger: schedule with cron expression Jobs: single job with the task Key features: workflow_dispatch for manual trigger too, failure notifications

Security Scanning

Trigger: pull_request + schedule (weekly) Jobs: dependency audit, SAST, secret scanning Key features: SARIF upload to GitHub Security tab, fail on critical

Docker Build & Push

Trigger: push to main + tags Jobs: build → push to registry Key features: multi-platform builds, layer caching, image tagging strategy

Essential Actions Reference

Setup Actions (always pin to major version)

ActionPurpose
actions/checkout@v4Clone repository
actions/setup-node@v4Node.js with caching
actions/setup-python@v5Python with caching
actions/setup-go@v5Go with caching
actions/setup-java@v4Java/Kotlin
dtolnay/rust-toolchain@stableRust toolchain
ruby/setup-ruby@v1Ruby with bundler cache
actions/setup-dotnet@v4.NET SDK

Build & Deploy Actions

ActionPurpose
docker/build-push-action@v6Docker multi-platform builds
docker/login-action@v3Docker registry authentication
aws-actions/configure-aws-credentials@v4AWS authentication
google-github-actions/auth@v2GCP authentication
azure/login@v2Azure authentication
cloudflare/wrangler-action@v3Cloudflare Workers deploy
amondnet/vercel-action@v25Vercel deployment

Quality & Security Actions

ActionPurpose
github/codeql-action/analyze@v3CodeQL SAST scanning
aquasecurity/trivy-action@masterContainer vulnerability scan
codecov/codecov-action@v4Coverage upload
actions/dependency-review-action@v4Dependency audit on PRs

Utility Actions

ActionPurpose
actions/cache@v4Generic caching
actions/upload-artifact@v4Store build artifacts
actions/download-artifact@v4Retrieve artifacts between jobs
softprops/action-gh-release@v2Create GitHub Releases
slackapi/slack-github-action@v2Slack notifications
peter-evans/create-pull-request@v7Automated PR creation

Security Best Practices (ALWAYS follow)

1. Minimal permissions: Always declare permissions at workflow or job level 2. Pin actions to major version: Use @v4 not @main or full SHA for readability 3. Never echo secrets: Secrets are masked but avoid echo ${{ secrets.X }} 4. Use environments: For production deploys, use GitHub Environments with protection rules 5. Validate inputs: For workflow_dispatch, validate input values 6. Avoid script injection: Never use ${{ github.event.*.body }} directly in run: — pass via environment variables 7. Use GITHUB_TOKEN: Prefer ${{ secrets.GITHUB_TOKEN }} over PATs when possible 8. Concurrency controls: Use concurrency to prevent parallel deploys

# WRONG - script injection vulnerability
- run: echo "${{ github.event.issue.title }}"

# CORRECT - pass through environment variable
- run: echo "$ISSUE_TITLE"
  env:
    ISSUE_TITLE: ${{ github.event.issue.title }}

Caching Strategies

Node.js

- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: 'npm'  # or 'yarn' or 'pnpm'

Python

- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: 'pip'  # or 'poetry' or 'pipenv'

Go

- uses: actions/setup-go@v5
  with:
    go-version: '1.22'
    cache: true

Rust

- uses: actions/cache@v4
  with:
    path: |
      ~/.cargo/bin/
      ~/.cargo/registry/index/
      ~/.cargo/registry/cache/
      target/
    key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}

Docker

- uses: docker/build-push-action@v6
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

Matrix Testing Patterns

Multiple Node.js versions

strategy:
  matrix:
    node-version: [18, 20, 22]
  fail-fast: false

Multiple OS

strategy:
  matrix:
    os: [ubuntu-latest, macos-latest, windows-latest]
runs-on: ${{ matrix.os }}

Complex matrix with exclusions

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [18, 20]
    exclude:
      - os: windows-latest
        node-version: 18

Cron Syntax Quick Reference

ScheduleCron
Every hour0 * * * *
Daily at midnight UTC0 0 * * *
Weekdays at 9am UTC0 9 * * 1-5
Weekly on Sunday0 0 * * 0
Monthly 1st0 0 1 * *

Output Format

After creating the workflow file, provide:

1. What the workflow does — one-paragraph summary 2. Required secrets — list any secrets the user needs to configure in Settings > Secrets 3. Required permissions — if the workflow needs non-default repository permissions 4. How to test — how to trigger the workflow (push, create PR, manual dispatch)

Common Patterns to Combine

When the user asks for something generic like "set up CI/CD", create a single workflow with multiple jobs:

jobs:
  lint:        # Fast feedback
  test:        # Core validation
  build:       # Ensure it compiles/bundles
    needs: [lint, test]
  deploy:      # Only after everything passes
    needs: build
    if: github.ref == 'refs/heads/main'

Keep workflows focused. Prefer one workflow per concern over one massive workflow, unless the jobs are tightly coupled.

Related skills

DevOps & CI/CDdevopstesting

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.