| name | ci-infrastructure-failure-diagnosis |
| description | Use when GitHub Actions sandbox/deploy checks fail across multiple PRs/branches — diagnose whether the failure is code-specific or repo-wide infrastructure. Triggers on "deploy check red", "sandbox failing", "all my PRs failing at deploy", "check-tokens failure", or when troubleshooting CI red flags that affect unrelated branches. |
CI Infrastructure Failure Diagnosis
When GitHub Actions checks fail red, especially the deploy (sandbox) job, determine whether the failure is caused by:
- Code in the PR (fix in code)
- Repo-wide infrastructure (escalate to ops)
This skill covers the deploy job in .github/workflows/sandbox-creating.yml (the sandbox workflow), which historically retrieved the PR number via a GitHub API call using a token stored in AWS Secrets Manager — not github.token. (sandbox-deleting.yml mirrored the same token retrieval.)
Resolved in code (#375). The sandbox deploy job no longer looks up the PR number via that token — it now reads PR_NUMBER straight from ${{ github.event.pull_request.number }}, so an expired github-token-* secret can no longer make this check fail. The timeline + cross-branch methodology below still applies to any other shared-infrastructure CI failure.
Quick diagnostic: timeline + consistency
Step 1: Check the timeline
Look at the GitHub Actions run history (repo > Actions > All workflows > deploy).
- When was the last successful sandbox run?
- Did every run since then fail at the same step?
If the last successful run is 3+ days old and every run since then fails at the same step, the failure is , not your code.