Prompts for implementation and AI tool handoff
Give Claude Code or Codex a bounded change, then hand the result to the next tool with its requirements, revision, and verification evidence.
015 · Implement an approved change
Use when: the brief, design, and acceptance criteria are ready. Claude Code is Nicholas’s usual implementation starting point; Codex can also own the task.
Bring: the relevant repository, approved design, requirements, and allowed actions. Check: the implementation reaches affected callers and the verification tests behavior rather than repeating the implementation.
Implement the approved change in this repository.
Outcome and acceptance criteria: [approved requirements]
Design reference and required states: [approved design]
Known relevant files: [starting points, not an exhaustive scope]
Out of scope: [exclusions]
Allowed actions: [local edits and checks, or other explicitly approved actions]
Read the relevant code and callers first. Reuse the existing components, stack, validation, and error handling. Make the smallest complete change, including affected callers, fixtures, and configuration. Do not add an abstraction or dependency without a concrete need.
Verify the behavior with checks appropriate to its risk, including important failure paths. Do not deploy, delete data, change production access, or run a destructive migration without explicit authorization.
Report changed behavior, checks actually run, failures or gaps, and any human decision still required.026 · Hand work from Claude Code to Codex, or back
Use when: implementation is ready for review, a different tool may help investigate a concrete failure, or another session must continue the work.
Bring: the actual revision and evidence. Check: the receiving tool can locate the work and distinguish decisions from unverified assumptions. Shared requirements should live with the project, not only in a chat.
Prepare a concise handoff for the next engineering session. Do not make further changes.
Goal and approved scope: [brief or source path]
Design reference: [approved source]
Work revision: [commit or precise diff]
Receiving task: [review / investigate a named failure / continue a named step]
Include:
- Files and connected behavior changed.
- Acceptance criteria and business rules to preserve.
- Checks actually run and their results.
- Exact reproduction steps for remaining failures.
- Assumptions, unresolved questions, and accepted design decisions.
- Findings already resolved or explicitly accepted, with evidence.
- Allowed next actions and actions requiring human authorization.
Point to repository evidence. Do not claim the change is correct because another model accepted it. Do not include credentials, private customer data, or unnecessary chat history.03Give the reviewer enough context to disagree
The review should start with the requirement and code, not just the implementer’s summary. Use the next prompts to examine the change and prepare an explicit release decision.