Github actions

GitHub Actions Skill

Skill, CI/CD, GitHub Actions, Automation

Context

Use this skill when you need to design or debug GitHub Actions workflows. This covers building CI pipelines, CD release pipelines, matrix build strategies, reusable workflows, and secure secrets management via OIDC. The AI will act as a specialist who understands GitHub Actions-specific idioms, runner environments, and the Actions marketplace ecosystem.

Variables

• {{workflow_trigger}}: What triggers the workflow (e.g., push to main, pull_request, workflow_dispatch, schedule).
• {{pipeline_goal}}: What the workflow should accomplish (e.g., run tests, build and push Docker image, deploy to AWS).
• {{tech_stack}}: The language/framework/tooling used (e.g., Node.js 20, Docker, AWS ECR, Terraform).
• {{environment}}: Target deployment environment (e.g., production on AWS EKS, staging on Vercel).

Prompt

Adopt the persona of a Senior GitHub Actions Engineer. I need to build the following workflow:

Goal: {{pipeline_goal}}

Trigger: {{workflow_trigger}}

Tech Stack: {{tech_stack}}

Target Environment: {{environment}}

Design this GitHub Actions workflow adhering to these standards:

1. **Workflow Structure:** Use proper `jobs` with clear `needs` dependencies. Group steps logically (setup, build, test, deploy). Use `environment:` protection rules for production deployments.
2. **Security:** Use OIDC (`permissions: id-token: write`) instead of long-lived credentials wherever possible. Store all secrets in GitHub Secrets — never hardcode them. Pin all third-party actions to a full commit SHA, not a tag.
3. **Efficiency:** Use `actions/cache` for dependency caching (npm, pip, Go modules, etc.). Use matrix builds (`strategy.matrix`) only when genuinely needed. Set appropriate `timeout-minutes` on jobs.
4. **Reusability:** If the workflow is complex, break it into a reusable workflow (`workflow_call`) or composite action.
5. **Observability:** Add `if: failure()` steps to report failures (e.g., post to Slack or create a GitHub issue). Use `::notice::`, `::warning::`, and `::error::` annotations where helpful.

Provide the full `.github/workflows/<name>.yml` file with inline comments explaining every non-obvious decision, especially around security and caching choices.

Example Usage

Input:

Adopt the persona of a Senior GitHub Actions Engineer. I need to build the following workflow:

Goal: Run unit tests, build a Docker image, push to AWS ECR, and deploy to EKS on merge to main.

Trigger: push to main branch

Tech Stack: Node.js 20, Docker, AWS ECR, Helm, Kubernetes (EKS)

Target Environment: Production on AWS EKS (us-east-1)

Design this GitHub Actions workflow adhering to these standards:
[...rest of prompt...]

Expected Output: A complete .github/workflows/deploy.yml with:

• Separate test, build, and deploy jobs with needs chaining
• OIDC-based AWS authentication via aws-actions/configure-aws-credentials
• Docker layer caching via actions/cache or cache-from
• Helm deploy step gated behind a production environment requiring manual approval
• All third-party actions pinned to commit SHAs