act-workflow-syntax
Use when creating or modifying GitHub Actions workflow files. Provides guidance on workflow syntax, triggers, jobs, steps, and expressions for creating valid GitHub Actions workflows that can be tested locally with act.
What this skill does
# Act - GitHub Actions Workflow Syntax
Use this skill when creating or modifying GitHub Actions workflow files (`.github/workflows/*.yml`). This covers workflow structure, triggers, jobs, steps, and best practices for workflows that work both on GitHub and locally with act.
## Workflow File Structure
Every GitHub Actions workflow follows this basic structure:
```yaml
name: Workflow Name
user-invocable: false
on: [push, pull_request] # Triggers
jobs:
job-name:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Step name
run: echo "Commands here"
```
### Top-Level Fields
- `name`: Human-readable workflow name (optional but recommended)
- `on`: Trigger events (push, pull_request, workflow_dispatch, etc.)
- `env`: Environment variables available to all jobs
- `jobs`: Map of job definitions
- `permissions`: Token permissions for the workflow
## Workflow Triggers
### Event Triggers
```yaml
# Single event
on: push
# Multiple events
on: [push, pull_request]
# Event with filters
on:
push:
branches:
- main
- 'releases/**'
paths:
- '**.js'
- '!docs/**'
pull_request:
types: [opened, synchronize, reopened]
```
### Manual Triggers
```yaml
on:
workflow_dispatch:
inputs:
environment:
description: 'Target environment'
required: true
default: 'staging'
type: choice
options:
- staging
- production
```
### Schedule Triggers
```yaml
on:
schedule:
- cron: '0 9 * * 1' # Every Monday at 9am UTC
```
## Job Configuration
### Basic Job
```yaml
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
```
### Job with Environment Variables
```yaml
jobs:
deploy:
runs-on: ubuntu-latest
env:
NODE_ENV: production
API_URL: ${{ secrets.API_URL }}
steps:
- run: echo "Deploying to $NODE_ENV"
```
### Job Dependencies
```yaml
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: npm run build
test:
needs: build
runs-on: ubuntu-latest
steps:
- run: npm test
deploy:
needs: [build, test]
runs-on: ubuntu-latest
steps:
- run: npm run deploy
```
### Matrix Builds
```yaml
jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
node: [18, 20, 22]
fail-fast: false
steps:
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node }}
- run: npm test
```
## Steps
### Using Actions
```yaml
steps:
# Checkout code
- uses: actions/checkout@v4
# Setup Node.js
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
# Upload artifacts
- uses: actions/upload-artifact@v4
with:
name: dist
path: dist/
```
### Running Commands
```yaml
steps:
# Single line
- run: npm install
# Multi-line
- run: |
npm ci
npm run build
npm test
# With name
- name: Install dependencies
run: npm ci
# With working directory
- run: npm test
working-directory: ./packages/core
# With shell
- run: echo "Hello"
shell: bash
```
### Conditional Steps
```yaml
steps:
- name: Deploy to production
if: github.ref == 'refs/heads/main'
run: npm run deploy
- name: Run on success
if: success()
run: echo "Previous steps succeeded"
- name: Run on failure
if: failure()
run: echo "A step failed"
- name: Always run
if: always()
run: echo "Runs regardless of status"
```
## Expressions and Contexts
### Common Contexts
```yaml
steps:
- run: echo "Event: ${{ github.event_name }}"
- run: echo "Branch: ${{ github.ref_name }}"
- run: echo "SHA: ${{ github.sha }}"
- run: echo "Actor: ${{ github.actor }}"
- run: echo "Job status: ${{ job.status }}"
- run: echo "Runner OS: ${{ runner.os }}"
```
### Using Secrets
```yaml
steps:
- run: echo "Token is set"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
API_KEY: ${{ secrets.API_KEY }}
```
### Functions
```yaml
steps:
- if: contains(github.event.head_commit.message, '[skip ci]')
run: echo "Skipping CI"
- if: startsWith(github.ref, 'refs/tags/')
run: echo "This is a tag"
- if: endsWith(github.ref, '/main')
run: echo "This is main branch"
- run: echo "${{ format('Hello {0}', github.actor) }}"
```
## Act-Specific Considerations
### Testing Locally with Act
```bash
# Run all workflows
act
# Run specific event
act push
# Run specific job
act -j build
# Dry run (validate without executing)
act --dryrun
# List workflows
act -l
# Use specific platform
act -P ubuntu-latest=catthehacker/ubuntu:act-latest
```
### Environment Variables for Act
```yaml
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Check environment
run: |
if [ "$ACT" = "true" ]; then
echo "Running in act"
else
echo "Running on GitHub"
fi
```
### Secrets with Act
Create `.secrets` file for local testing:
```
GITHUB_TOKEN=ghp_your_token_here
API_KEY=your_api_key_here
```
Then run:
```bash
act --secret-file .secrets
```
Or pass secrets individually:
```bash
act -s GITHUB_TOKEN=ghp_token -s API_KEY=key
```
## Best Practices
### DO
✅ Use semantic job and step names
✅ Pin action versions (`actions/checkout@v4`)
✅ Use `fail-fast: false` for matrix builds to see all results
✅ Set appropriate `timeout-minutes` for jobs
✅ Use `working-directory` instead of cd commands
✅ Test workflows locally with `act --dryrun` before pushing
✅ Use caching for dependencies
✅ Use environments for deployment jobs
### DON'T
❌ Hardcode secrets in workflow files
❌ Use `latest` tags for actions
❌ Run workflows on every file change (use path filters)
❌ Create overly complex workflows (split into multiple files)
❌ Ignore act compatibility when using GitHub-specific features
❌ Forget to validate YAML syntax
## Common Patterns
### Build and Test
```yaml
name: CI
user-invocable: false
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- run: npm ci
- run: npm test
- run: npm run build
```
### Deploy on Tag
```yaml
name: Deploy
user-invocable: false
on:
push:
tags:
- 'v*'
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Get version
id: version
run: echo "VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_OUTPUT
- run: echo "Deploying ${{ steps.version.outputs.VERSION }}"
```
### Monorepo with Changed Files
```yaml
jobs:
detect-changes:
runs-on: ubuntu-latest
outputs:
api: ${{ steps.changes.outputs.api }}
web: ${{ steps.changes.outputs.web }}
steps:
- uses: actions/checkout@v4
- uses: dorny/paths-filter@v3
id: changes
with:
filters: |
api:
- 'packages/api/**'
web:
- 'packages/web/**'
build-api:
needs: detect-changes
if: needs.detect-changes.outputs.api == 'true'
runs-on: ubuntu-latest
steps:
- run: echo "Building API"
```
## Related Skills
- **act-local-testing**: Testing workflows locally before pushing
- **act-docker-setup**: Configuring Docker environments for act
- **act-secrets-management**: Managing secrets for local testing
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.