GitHub Actions Workflow

Generate a CI workflow with the practices AI usually skips: SHA-pinned actions, least-privilege permissions, caching, timeouts, and concurrency.

Write a GitHub Actions workflow for my project.

What it should do: [e.g. "typecheck + test + lint on every PR, build and deploy on merge to main"]
Stack: [LANGUAGE/RUNTIME + VERSION, PACKAGE MANAGER, TEST/BUILD COMMANDS]
Deploy target, if any: [WHERE + AUTH METHOD: OIDC preferred over long-lived secrets]
Repo facts: [MONOREPO? / TYPICAL CI TIME TODAY / PUBLIC OR PRIVATE]

Non-negotiable requirements. Annotate each in a YAML comment so future editors don't "clean them up":
1. **Pin third-party actions to full commit SHAs** (with the version as a comment: uses: some/action@<sha> # v4.1.2). Tag references can be moved by a compromised maintainer. SHA-pinning is the supply-chain defense. First-party actions/* may use major version tags.
2. **Least-privilege permissions:** top-level "permissions: contents: read", escalated per-job only where needed (id-token: write for OIDC deploys, pull-requests: write for comment steps), never a blanket write.
3. **timeout-minutes on every job**: a hung job without a timeout burns the runner budget for 6 hours.
4. **Concurrency group** with cancel-in-progress for PR workflows, so force-pushes don't stack runs.
5. **Caching via the setup actions' built-in cache** (setup-node/setup-python cache option) over hand-rolled actions/cache where possible; cache keyed on the lockfile.
6. **No pull_request_target** unless I explicitly need it, and if I do, explain the untrusted-checkout risk and gate it properly.
7. **Secrets discipline:** no secrets in run: echo, no secrets passed to untrusted code paths; prefer OIDC federation for cloud auth over stored keys.
8. **Fail fast and clearly:** steps ordered cheapest-first (lint → typecheck → test → build), matrix only where I actually need multiple versions.

Structure the output:
- The complete workflow YAML, commented.
- A jobs summary table: job | trigger | permissions | time budget.
- The verification steps: how to test this safely (act locally or a draft PR), and what the first green run should show.
- Anything my request implied that's risky (deploy on every push, tests skipped on main). Flag it with the safer alternative instead of silently complying.

Rules: current major versions of standard actions (checkout, setup-*). If unsure of the latest, say [VERIFY LATEST] rather than guessing an old one, since outdated action versions are the #1 AI-generated-workflow defect.

How to use

AI-generated workflows have a documented failure signature: stale action versions, missing permissions blocks, no timeouts, no concurrency. This prompt encodes each fix as a requirement with the reasoning attached so reviewers keep them. SHA-pinning matters most on public repos (supply-chain attacks via retagged actions are real incidents, not theory). After the first green run, check the Actions tab for the billable minutes and tighten timeouts to ~2x observed.

More coding prompts

Write the commit message for this change.

Diff:
"""
[PASTE THE STAGED DIFF]
"""

Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"]
Convention: [Conventional Commits / this repo's existing style, pasted below / plain]
Recent commits from this repo, to match style:
"""
[PASTE 5-10 RECENT COMMIT SUBJECT LIN

Commit Message

Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.

Codingbeginner

Help me recover from a git mistake without making it worse.

What I was trying to do: [THE GOAL]
What I ran: [THE EXACT COMMANDS, IN ORDER]
What happened instead: [THE OUTPUT OR THE STATE NOW]
Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled]
Uncommitted work I cannot lose: [WHAT AND WHERE, o

Undo a Git Mistake

Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.

Codingintermediate

Handler code, routes, and models:
"""
[PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE]
"""

Generate an OpenAPI 3.1 specification from the code above.

API name, version, and base URL: [DETAILS]
Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced]
Con

OpenAPI Spec From Code

Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.