Best PromptsCommit Message
Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.
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 LINES, OR DELETE THIS BLOCK]
"""
Rules:
- **Subject**: under 72 characters, imperative mood ("add", not "added"), no trailing period. With Conventional Commits, use type(scope): description and pick the type from what the diff does, not from what I say it does.
- **Body**: only when the change needs it. Explain why this change, and what the alternative was if a reader would wonder. The diff already shows what changed, so a body that restates the diff is noise.
- **Breaking changes**: if the diff changes a public signature, a schema, a config key, or a default, say so explicitly with BREAKING CHANGE and what callers must do.
- **Footer**: reference the issue if I gave one.
Before writing, check whether this diff is really one change. If it contains unrelated changes, do not write one message: list the separate commits it should be split into, with which files or hunks belong to each and the message for each. A commit that does three things cannot be reverted.
If the reason for a change is not visible in the diff and I did not tell you, ask rather than inventing a rationale. An invented "why" in a commit message is worse than no body, because it will be believed years later.How to use
The split check is the part that earns its place. Models will happily summarize a five-concern diff into one smooth sentence, and that commit is the one that blocks a clean revert eighteen months later during an incident. Pasting recent commit subjects is the cheapest way to match a repo's house style, since models copy the pattern in examples far more reliably than they follow a described convention.
More coding prompts
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.
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.
Infrastructure code to review: """ [PASTE THE TERRAFORM, CLOUDFORMATION, PULUMI, OR KUBERNETES MANIFESTS. INCLUDE THE PLAN OUTPUT IF YOU HAVE IT.] """ Review the infrastructure code above as the person who will be paged when it breaks. Environment: [PROD / STAGING / DEV] and what runs on it: [WORKLOAD] What this change is meant to do: [
Infrastructure as Code Review
Review Terraform, CloudFormation, or Kubernetes manifests for blast radius, security defaults, state risk, and what the plan will really do.