gha-stylelisted

# GitHub Actions Coding Conventions Claude already knows the basic structure of GitHub Actions (events, workflows, jobs, steps). Focus on the following patterns that are easy to overlook but important for security and reliability. ## 1. Permissions — Whitelist Approach The default `GITHUB_TOKEN` has read/write access to the repo, which is broader than most jobs need. Declare `permissions: {}` at the workflow level (deny-all), then grant only what each job actually requires. ```yaml permissions: {} # workflow level: deny-all jobs: build: permissions: contents: read # checkout pull-requests: write # post comments ``` Common permission keys: `contents`, `issues`, `pull-requests`, `packages`, `id-token` (OIDC), `checks`, `statuses`. ## 2. Version Pinning Tags like `@v4` can be moved or deleted by the action author — the same tag may point to different code over time. Pin to an exact version tag or commit SHA. ```yaml # Avoid — tag can move - uses: actions/checkout@v4 # Recommended — exact version tag - uses: actions/checkout@v4.2.1 # High security — immutable SHA (add the tag as a comment for readability) - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.1 ``` ## 3. Script Injection Prevention GitHub context values like PR titles, issue bodies, and branch names come from untrusted external sources. Interpolating them directly into `run:` allows an attacker to inject arbitrary shell commands. Always pass them