github-actions-setuplisted

# GitHub Actions Setup This skill takes a project from no automation to "push to main and it tests + deploys itself." It bundles a one-command script, ready-made workflow templates for three common deploy targets, and a best-practices reference — use whichever combination fits what the user actually needs, rather than dumping everything on them at once. ## When this triggers, figure out two things first 1. **What language/stack is the project?** Look for `package.json`, `requirements.txt`/`pyproject.toml`, or `go.mod` in the project directory. If none of those are present, ask. 2. **Where does it deploy?** AWS, Vercel, Cloudflare Pages/Workers, Railway, Render, a generic server (anything reachable over SSH), or nothing yet (tests only). If the user hasn't said, ask — don't guess, since the secrets and deploy steps are completely different per target. If they mention a specific host they SSH into, that's "server"; if they mention S3/CloudFront/ECS, that's "aws"; if they mention Vercel or a framework Vercel is known for (Next.js, etc.) and don't correct you, "vercel" is a safe assumption to confirm; Cloudflare Pages/Workers, Railway, and Render map directly if named. Only AWS authenticates via GitHub OIDC (no stored long-lived credentials). Cloudflare, Railway, and Render don't support OIDC federation from GitHub yet, so those three use a static API token or deploy hook URL stored as a repo secret instead — mention this when walking through secrets for one of those targe