Codex's Four-Gate Kickoff: Define the Task → Review the Plan → Check the Diff → Nothing Counts as Done Without Verification
Turns a vague requirement into a full Codex workflow: first force it to nail down a 'definition of done,' use plan mode to produce a plan for your approval, then implement in small steps, run its own tests, and finally produce a reviewable diff with verification evidence.
Act as a disciplined pair-programmer working in this repo. We are going to run a single task through four explicit gates. Do NOT skip ahead — finish each gate and wait for my go-ahead before the next.
TASK (raw, possibly fuzzy): {{TASK}}
RELEVANT FILES / AREAS (optional, @-mention or paths): {{CONTEXT_FILES}}
HARD CONSTRAINTS (must respect): {{CONSTRAINTS}}
--- GATE 1: FRAME THE TASK ---
Before touching code, restate the task in your own words and produce:
- **Goal** — what changes and why, in 1-2 sentences.
- **Done when** — concrete, verifiable acceptance criteria (which command/test must pass, what behavior must be observable). If I gave none, propose them.
- **Open questions** — anything ambiguous that would change your approach. Ask me only the questions that actually block you. If there are none, say "no blockers".
Then STOP and let me confirm or correct.
--- GATE 2: PLAN (use plan mode) ---
Enter plan mode. Read the relevant code first, then present a step-by-step plan:
- the files you will create/modify and what changes in each
- the order of changes and why
- the test(s) you will add or rely on
- risks, edge cases, and anything that could break existing behavior
Do not write implementation code yet. Present the plan, then STOP for my approval. If I push back, revise the plan — don't start coding until I say go.
--- GATE 3: IMPLEMENT IN SMALL STEPS ---
Once I approve the plan, implement it. Rules:
- Work in coherent small steps; keep changes scoped to the plan. If you discover the plan was wrong, pause and tell me before diverging.
- Match existing code style and patterns in this repo — read a neighboring file if unsure.
- Respect all HARD CONSTRAINTS above and anything in AGENTS.md.
- Do not introduce TODOs, placeholder functions, or stubbed logic. Either implement it or explain why it's out of scope.
--- GATE 4: VERIFY & REPORT ---
Before you claim it's done, actually verify:
1. Run the project's test / build / typecheck / lint commands and paste the real output. Do not say "should pass" — run it.
2. Confirm each "Done when" criterion from Gate 1 is met; map criterion → evidence.
3. Show me the final diff summary (files touched + a one-line reason each).
4. List anything you did NOT do, known limitations, or follow-ups.
If verification fails, fix it and re-run — do not hand me red output and call it done.
Throughout: if at any gate you're uncertain, say so plainly rather than guessing. A flagged unknown beats a confident wrong answer.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/task-intake-plan-diff-verify.md then invoke it with /task-intake-plan-diff-verify.
mkdir -p ~/.codex/prompts && mv ~/Downloads/task-intake-plan-diff-verify.md ~/.codex/prompts/task-intake-plan-diff-verify.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.codex\prompts" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\task-intake-plan-diff-verify.md" "$env:USERPROFILE\.codex\prompts\task-intake-plan-diff-verify.md"When to use it: any non-trivial Codex task (adding a feature, fixing a bug, changing architecture) — especially when you don't want to babysit every step but also don't want it running wild. Why it works: OpenAI's own Codex best practice is to treat a task like 'a teammate with clear context and a definition of done' — this prompt turns that into four mandatory gates. Gate 1 forces out a verifiable 'Done when,' Gate 2 uses the real, existing plan mode (/plan or Shift+Tab) so it reads the code first and gives you a plan to approve before diving in and going the wrong direction; Gate 3 requires small steps and bans placeholders; Gate 4 requires it to 'actually run the tests and paste the output' rather than 'it should probably pass.' Technique: designing checkpoints that require your nod before proceeding effectively trades an approval mechanism for a sense of control; referencing specific files with @ in CONTEXT_FILES substantially improves plan quality.
GATE 1 — FRAME Goal: After login, redirect the user back to the page they came from instead of always /dashboard. Done when: visiting /watchlist while logged out, logging in, lands back on /watchlist; existing /dashboard default still works when there's no return path; `npx tsc --noEmit` passes. Open questions: Should the return_to be validated against an allowlist to avoid open-redirect? (recommend yes) — no other blockers. [STOP — awaiting your confirmation] GATE 2 — PLAN 1. middleware.ts: capture original path into a signed `return_to` cookie on the redirect-to-login. 2. app/login/route.ts: after successful auth, read return_to, validate it's a same-origin relative path, else fall back to /dashboard. 3. Add test in __tests__/login-redirect.test.ts covering: valid return, missing return, open-redirect attempt. Risks: open-redirect if return_to isn't validated; cookie must be httpOnly + same-site. [STOP — awaiting plan approval]
[TASK]你要 Codex 做的事，可以是很口語的一句話，例如『把登入後的轉址改成回到原本頁面』
[CONTEXT_FILES]相關檔案或目錄（可選），用 @ 提及或貼路徑，例如 @app/login/route.ts、middleware.ts；不確定就留空讓它自己找
[CONSTRAINTS]硬限制，例如『不准動 D1 migration』『不可改動點數扣款邏輯』『維持現有 API 介面』；沒有就寫 none
填下面的欄位，上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
Act as a disciplined pair-programmer working in this repo. We are going to run a single task through four explicit gates. Do NOT skip ahead — finish each gate and wait for my go-ahead before the next.
TASK (raw, possibly fuzzy): {{TASK}}
RELEVANT FILES / AREAS (optional, @-mention or paths): {{CONTEXT_FILES}}
HARD CONSTRAINTS (must respect): {{CONSTRAINTS}}
--- GATE 1: FRAME THE TASK ---
Before touching code, restate the task in your own words and produce:
- **Goal** — what changes and why, in 1-2 sentences.
- **Done when** — concrete, verifiable acceptance criteria (which command/test must pass, what behavior must be observable). If I gave none, propose them.
- **Open questions** — anything ambiguous that would change your approach. Ask me only the questions that actually block you. If there are none, say "no blockers".
Then STOP and let me confirm or correct.
--- GATE 2: PLAN (use plan mode) ---
Enter plan mode. Read the relevant code first, then present a step-by-step plan:
- the files you will create/modify and what changes in each
- the order of changes and why
- the test(s) you will add or rely on
- risks, edge cases, and anything that could break existing behavior
Do not write implementation code yet. Present the plan, then STOP for my approval. If I push back, revise the plan — don't start coding until I say go.
--- GATE 3: IMPLEMENT IN SMALL STEPS ---
Once I approve the plan, implement it. Rules:
- Work in coherent small steps; keep changes scoped to the plan. If you discover the plan was wrong, pause and tell me before diverging.
- Match existing code style and patterns in this repo — read a neighboring file if unsure.
- Respect all HARD CONSTRAINTS above and anything in AGENTS.md.
- Do not introduce TODOs, placeholder functions, or stubbed logic. Either implement it or explain why it's out of scope.
--- GATE 4: VERIFY & REPORT ---
Before you claim it's done, actually verify:
1. Run the project's test / build / typecheck / lint commands and paste the real output. Do not say "should pass" — run it.
2. Confirm each "Done when" criterion from Gate 1 is met; map criterion → evidence.
3. Show me the final diff summary (files touched + a one-line reason each).
4. List anything you did NOT do, known limitations, or follow-ups.
If verification fails, fix it and re-run — do not hand me red output and call it done.
Throughout: if at any gate you're uncertain, say so plainly rather than guessing. A flagged unknown beats a confident wrong answer.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.