What this prompt does
This prompt hands Claude Code a fixed, six-step pipeline that runs from a ticket ID to an open pull request, instead of letting it improvise. You fill in four variables — [ticket_id], [language], [framework], and [base_branch] — and the agent restates the acceptance criteria in its own words, explores the repo with Grep and Read, writes a failing test, implements the smallest change that turns it green, runs the full suite, then opens a PR with a sub-50-character conventional commit subject and a body that explains the why.
It works because the ordering is deliberately test-first. Forcing the agent to restate acceptance criteria before touching code surfaces a misread ticket while it's still cheap to fix. Demanding a failing test before the implementation is the single instruction that stops Claude from writing plausible-but-wrong code and declaring victory — the red test is the contract the green one has to satisfy. "Smallest change that makes the test pass" and the closing "Never skip verification" are guardrails against scope creep and the classic LLM habit of claiming done without running anything.
When to use it
- A well-scoped ticket with clear acceptance criteria — a bug fix, a small endpoint, a validation rule — not an open-ended "redesign the auth system."
- Repos that already have a runnable test suite the agent can extend and execute.
- Teams that enforce conventional commits and want the subject/body formatted right on the first try.
- Onboarding into an unfamiliar codebase, where the Grep/Read exploration step earns its keep.
- Any time you've watched an agent skip the test and ship a confident regression.
Example output
Ticket PROJ-482 — restated: "Reject signup when email already exists; return 422, not 500."
Explored: app/Http/Requests/RegisterRequest.php, RegistrationTest.php
RED: test_duplicate_email_returns_422 → fails (got 500)
Implemented: added `unique:users,email` rule to RegisterRequest
GREEN: full suite 214 passed, 0 failed
PR → main
feat: reject duplicate-email signups with 422
Body: existing rule set let duplicates hit the DB layer and 500.
Validation now fails fast with a clear field error. Closes PROJ-482.
Pro tips
- Set
[base_branch]to your real integration branch (develop,staging) — left asmain, the PR can target the wrong place and force a re-open. - Be specific with
[language]and[framework], including version (Laravel 11,React 19): together they dictate which test runner and assertion style Claude reaches for, and a vague value yields generic scaffolding. - The prompt assumes a green baseline. If the suite is already failing, say so first — otherwise the agent can't tell its new red test from pre-existing breakage.
- Pair it with a
CLAUDE.mdthat names your exact test command (php artisan test --filter=) and lint step; the workflow says "run the full test suite" but won't guess your tooling. - For multi-file tickets, ask it to restate criteria as a checklist and confirm with you before step 3 — cheap insurance against a wrong-direction implementation.