Codex Wrap-Up Officer: Turn Finished Changes into a Semantic Commit + a PR That Passes Review
Once your code changes are done, have Codex read the staged diff, produce a Conventional Commits message, and write a PR description covering background, what changed, why, how it was verified, and risks — without bundling in unrelated changes, exaggerating, or fabricating tests.
You are finishing a change in this git repo by producing a clean commit and a reviewable pull request. Base everything on the ACTUAL diff — never on assumptions about what I intended.
Follow any commit/PR conventions defined in AGENTS.md. If none are specified there, default to Conventional Commits.
STEP 1 — Inspect reality.
- Run `git status` and `git diff --staged` (and `git diff` for unstaged) and read the changes.
- If nothing is staged, tell me, and propose a sensible staging grouping rather than blindly `git add -A`. Do NOT stage unrelated changes (build artifacts, unrelated files, debug prints) into the same commit — flag them.
- Identify whether this is logically ONE change or several. If it should be multiple commits, tell me how you'd split it and ask before combining.
STEP 2 — Write the commit message.
Format: {{COMMIT_CONVENTION}}.
- Subject line: imperative mood, <= ~72 chars, correct type + scope (e.g. `fix(auth): ...`). The type must match what the diff actually does (a refactor is not a `feat`).
- Body (only if the change isn't trivial): explain the WHY and any non-obvious decisions, wrapped sensibly. Reference the issue/ticket {{ISSUE_REF}} if provided.
- Do not claim tests were added/passing unless the diff actually contains them or you actually ran them.
Show me the proposed message and let me approve before committing.
STEP 3 — Open the PR.
Target base branch: {{BASE_BRANCH}}.
Before writing the description, optionally run a self-review of the diff for obvious bugs, security issues, or leftovers (secrets, console logs, commented-out code) and surface them to me first.
Then draft a PR description with these sections:
- **What** — what this PR changes, in plain language.
- **Why** — the motivation / problem being solved (link {{ISSUE_REF}} if any).
- **How** — key implementation decisions and anything a reviewer should look at closely.
- **Testing** — exactly how it was verified (commands run + result). If you did not run them, say "not yet verified" — do not fabricate green checks.
- **Risk / rollback** — what could break and how to revert.
- **Out of scope** — explicitly what this PR does NOT do.
Keep it scannable: short paragraphs and bullets, no filler.
STEP 4 — Create it.
If the GitHub CLI (`gh`) is available, create the PR against {{BASE_BRANCH}} using the message and description above and return the PR URL. If `gh` is not available or not authenticated, instead output the final commit command and a ready-to-paste PR title + body so I can open it manually. Confirm before pushing to any remote.
Guardrails: never force-push, never push to {{BASE_BRANCH}} directly, and never invent ticket numbers, reviewers, or test results.See what this prompt actually produces without leaving the site (live AI run, 1 credit).
Don't just copy-paste — download and drop it at ~/.codex/prompts/semantic-commit-and-pr.md then invoke it with /semantic-commit-and-pr.
mkdir -p ~/.codex/prompts && mv ~/Downloads/semantic-commit-and-pr.md ~/.codex/prompts/semantic-commit-and-pr.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.codex\prompts" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\semantic-commit-and-pr.md" "$env:USERPROFILE\.codex\prompts\semantic-commit-and-pr.md"When to use it: once the code is finished and you need to turn it into a clean commit and a PR that reviewers will actually want to look at. Why it works: Codex has no built-in one-click commit/PR slash command — this kind of work relies on the prompt driving it to run git — so the instructions must explicitly require it to 'read the real diff before writing anything.' Key safeguards: (1) it must follow AGENTS.md's commit conventions, or fall back to Conventional Commits (OpenAI itself says this is the single most effective way to get an agent to produce professional commits); (2) it's forbidden from adding unrelated changes into the same commit, and forbidden from mismatching the type against the actual diff (a refactor can't be labeled feat); (3) it's forbidden from fabricating 'tests passed' — if it hasn't run them, it must mark them as not yet verified, in line with the honesty protocol; (4) it opens a PR via gh, or if that's unavailable, outputs a pastable title and body, and it must confirm with you before pushing — never force-pushing or pushing directly to the base branch. Technique: having it do a self-review pass on the diff first (leftover secrets / console.log / commented-out code) before writing the description noticeably improves PR quality.
STEP 2 — Proposed commit fix(login): return user to original page after auth instead of /dashboard Logged-out users hitting a protected page were always bounced to /dashboard after login, losing their place. Capture the original path in a signed, httpOnly return_to cookie and restore it post-auth, validating it's a same-origin relative path to avoid open redirects. Refs #482 [awaiting approval before committing] STEP 3 — PR description (base: main) ## What Redirect users back to the page they originally requested after logging in. ## Why Protected-page visitors lost context (#482); always landing on /dashboard hurt the watchlist/portfolio flows. ## How Signed return_to cookie set in middleware.ts; validated + consumed in app/login/route.ts. Falls back to /dashboard when absent or invalid. ## Testing `npx tsc --noEmit` passed; added __tests__/login-redirect.test.ts (3 cases incl. open-redirect attempt) — `npm test` green. ## Risk / rollback Low; revert this commit to restore prior behavior. Open-redirect guarded by same-origin check. ## Out of scope Does not change the OAuth provider flow or session expiry.
[COMMIT_CONVENTION]commit 訊息格式，例如 Conventional Commits（feat/fix/chore/refactor…）或團隊自訂；想沿用 repo 設定就寫『follow AGENTS.md』
[ISSUE_REF]關聯的 issue／ticket 編號（可選），例如 #482 或 JIRA-1234；沒有就留空，並要求它不要編造
[BASE_BRANCH]PR 要併入的目標分支，例如 main 或 develop
填下面的欄位，上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
You are finishing a change in this git repo by producing a clean commit and a reviewable pull request. Base everything on the ACTUAL diff — never on assumptions about what I intended.
Follow any commit/PR conventions defined in AGENTS.md. If none are specified there, default to Conventional Commits.
STEP 1 — Inspect reality.
- Run `git status` and `git diff --staged` (and `git diff` for unstaged) and read the changes.
- If nothing is staged, tell me, and propose a sensible staging grouping rather than blindly `git add -A`. Do NOT stage unrelated changes (build artifacts, unrelated files, debug prints) into the same commit — flag them.
- Identify whether this is logically ONE change or several. If it should be multiple commits, tell me how you'd split it and ask before combining.
STEP 2 — Write the commit message.
Format: {{COMMIT_CONVENTION}}.
- Subject line: imperative mood, <= ~72 chars, correct type + scope (e.g. `fix(auth): ...`). The type must match what the diff actually does (a refactor is not a `feat`).
- Body (only if the change isn't trivial): explain the WHY and any non-obvious decisions, wrapped sensibly. Reference the issue/ticket {{ISSUE_REF}} if provided.
- Do not claim tests were added/passing unless the diff actually contains them or you actually ran them.
Show me the proposed message and let me approve before committing.
STEP 3 — Open the PR.
Target base branch: {{BASE_BRANCH}}.
Before writing the description, optionally run a self-review of the diff for obvious bugs, security issues, or leftovers (secrets, console logs, commented-out code) and surface them to me first.
Then draft a PR description with these sections:
- **What** — what this PR changes, in plain language.
- **Why** — the motivation / problem being solved (link {{ISSUE_REF}} if any).
- **How** — key implementation decisions and anything a reviewer should look at closely.
- **Testing** — exactly how it was verified (commands run + result). If you did not run them, say "not yet verified" — do not fabricate green checks.
- **Risk / rollback** — what could break and how to revert.
- **Out of scope** — explicitly what this PR does NOT do.
Keep it scannable: short paragraphs and bullets, no filler.
STEP 4 — Create it.
If the GitHub CLI (`gh`) is available, create the PR against {{BASE_BRANCH}} using the message and description above and return the PR URL. If `gh` is not available or not authenticated, instead output the final commit command and a ready-to-paste PR title + body so I can open it manually. Confirm before pushing to any remote.
Guardrails: never force-push, never push to {{BASE_BRANCH}} directly, and never invent ticket numbers, reviewers, or test results.Suno Engineer's Mindset: 4 Steps to a Song That Doesn't Sound Like AI
A studio engineer's breakdown of Suno's fatal weaknesses (fried vocals, high-frequency artifacts), plus a 4-step DAW workflow and a Suno Studio cleanup prompt.
5 Claude Weekly Workflows That Stuck After 6 Months
Proposal generator / meeting processor / content repurposer / Friday review / shutdown reset — out of 40 I tried, only these 5 survived, each saving 30+ minutes per run.