Handoff

Handoff Prompt Generator

Generate a prompt that another agent can execute without guessing.

Choose the handoff mode

• Use a shared-workspace handoff when the receiving agent can access the same repo, files, and artifacts.
• Use a fresh-context handoff when the receiving agent starts cold, in another session, or on another platform.
• Ask for the target model family if it is not implied by the user's request. If it still is not known, draft a vendor-neutral base prompt and mark any missing model-specific adjustments.

Read one model reference

Read only the reference that matches the receiving model:

If the requested model version is newer than the reference, verify the latest official docs before drafting the handoff.

Gather only execution-critical context

Collect the minimum information that removes ambiguity:

• objective
• success criteria
• scope boundaries
• relevant files, commands, URLs, or artifacts
• current state and known blockers
• verification steps
• output location or return format
• coordination notes for parallel work

Do not pad the handoff with background that does not change the receiver's next action.

Build the base handoff

Use flat labeled sections. Prefer direct operational language over narrative explanation.

Shared-Workspace Handoff

Target model: [family/version]
Handoff type: shared-workspace sub-task

Objective
[One concrete outcome]

Success criteria
- [Observable completion condition]
- [Verification condition]

Context
- [Only facts needed for this slice of work]

Inputs and artifacts
- [file paths, branches, logs, docs, prior outputs]

Ownership
- [files or directories to modify]
- [areas to avoid]

Constraints
- [technical limits]
- [things the agent must not do]

Verification
- [commands, tests, or review checks to run]

Output
- [exact return format]
- [where to write or save artifacts]

Coordination
- [how this work fits with parallel tasks]

Fresh-Context Handoff

Target model: [family/version]
Handoff type: fresh context

Project
- name: [project name]
- overview: [1-2 sentences]
- entry points: [first files or docs to read]

Current state
- completed: [what is already done]
- remaining: [what still needs to be done]
- blockers/baseline: [known failures, risks, or assumptions]

Task
- objective: [single outcome]
- success criteria:
  - [observable condition]
  - [verification condition]

Constraints
- [scope limits]
- [things not to change]
- [environment or policy constraints]

Verification
- [commands, tests, or manual checks]

Output
- [exact deliverable shape]
- [how to report open questions or TODOs]

Use placeholders like [TODO: exact path] instead of inventing repository facts.

Apply model-specific tuning

After drafting the base handoff:

• add only the adjustments from the matching reference file
• prefer external runtime settings when the receiving harness exposes them
• avoid inventing API-only controls inside plain chat prompts
• generate one prompt per target model if the user wants multiple versions

Hold the quality bar

• Keep the task atomic.
• Define what "done" means.
• Name files and commands whenever possible.
• Reference shared artifacts by path instead of pasting large logs.
• State explicit stop rules for destructive or broad changes.
• Ask for findings first for review tasks.
• Require source boundaries and citation expectations for research tasks.

Return format

When the user asks for a handoff prompt:

1. Return the ready-to-send prompt in a fenced code block. 2. List assumptions or placeholders after the prompt. 3. Generate separate prompts when the user wants handoffs for multiple models.

Anthropic Claude 4.x Handoff Patterns

Source snapshot: refreshed 2026-03-12 from official Anthropic docs

• Prompting best practices

Start here

• Be clear and direct. Claude 4.x follows what you ask for, not what you imply.
• State the desired depth, quality bar, and output format explicitly.
• Explain why unusual constraints matter when behavior depends on them.
• Use examples when format or tone must match closely.
• Use XML tags or clearly labeled sections to separate instructions, context, examples, and inputs.

Handoff emphasis

• Tell Claude whether the task is to implement, suggest, review, or investigate.
• Say whether independent tool calls should be run in parallel.
• Use numbered steps when order matters.
• Point to the files, logs, or state artifacts Claude should read first.
• Keep shared state in files or git artifacts for long-running or multi-session work.

Good shape

<context>
[Project slice, current state, relevant files]
</context>

<task>
[Single explicit objective]
</task>

<tool_use>
[Tools to prefer, whether to parallelize]
</tool_use>

<constraints>
[Scope limits and prohibitions]
</constraints>

<verification>
[Checks to run before reporting back]
</verification>

<output>
[Exact return format]
</output>

Examples

• Provide 3 to 5 short examples when you need tight output consistency.
• Keep examples relevant to the actual task.
• Wrap examples in their own section so they do not blur into the instructions.

Avoid

• vague requests like "be thorough" without defining the deliverable
• burying critical constraints in long prose
• assuming local repo norms are obvious
• mixing stable instructions with mutable project state in the same block

Google Gemini 3.x Handoff Patterns

Source snapshot: refreshed 2026-03-12 from official Google docs

• Prompt design strategies
• Gemini 3 prompting guide
• Overview of prompting strategies

Start here

• Give clear and specific instructions.
• Use prefixes or XML-style delimiters for complex prompts.
• Keep persona light so task instructions stay dominant.
• Anchor the task to the provided repo state, files, or source material when external knowledge should not be used.
• Keep temperature at the default 1.0 for Gemini 3 models unless you have measured evidence that another setting helps.

Reasoning controls

If the receiving harness exposes Gemini reasoning settings:

• use thinking_level=LOW for low-latency, straightforward work
• use thinking_level=MEDIUM for standard coding and analysis
• use thinking_level=HIGH for harder multi-step tasks
• add "think silently" only when you need lower-latency reasoning with a terse final answer

Grounding rules

• Prefer explicit grounding instructions such as "Use only the repository state and notes below for deductions."
• Avoid broad negatives like "do not infer." They can suppress normal calculations and synthesis.
• Tell Gemini when search grounding or other retrieval is allowed if current information matters.

Good shape

Context
[Essential background and artifacts]

Task
[Direct objective]

Grounding rules
- [What sources may be used]
- [What deductions are allowed]

Constraints
- [Scope limits]
- [Things to avoid]

Output
- [Exact structure]
- [Verification or citations required]

Avoid

• lowering temperature by default
• broad negatives instead of specific grounding rules
• over-styled personas that compete with the task
• hiding the required format inside long context paragraphs

OpenAI GPT-5.x / Codex Handoff Patterns

Source snapshot: refreshed 2026-03-12 from official OpenAI docs

• Prompt guidance for GPT-5.4
• Using GPT-5.4
• GPT-5 prompting guide
• GPT-5.2 prompting guide

Start here

• Prefer the Responses API or an agent wrapper that preserves tool state across turns.
• State the objective, tool-use rules, completion criteria, verification plan, and output contract explicitly.
• Use labeled blocks or clearly separated sections so the model can keep context, constraints, and deliverables distinct.
• Ask for structured outputs or strict schemas when another system will parse the result.
• Tell the agent whether to act proactively or stop after analysis.

Handoff emphasis

• Name the tools or files the agent should use first.
• Separate scope boundaries from background context.
• Give concrete stop rules for destructive, broad, or expensive actions.
• Include exact verification commands when correctness matters.
• Prefer direct operational language over conversational setup.

Runtime knobs

If the receiving harness exposes model settings, prefer these there instead of spelling them out in prose:

• reasoning.effort: use none or low for extraction, classification, and formatting; use medium or high for debugging, coding, and multi-step planning.
• text.verbosity: use low, medium, or high to control response length without rewriting the whole prompt.
• structured outputs or strict tool schemas: use them whenever machine-readable output is required.

Good shape

Context
[Only facts the agent needs]

Task
[Single concrete outcome]

Tool use
- [Which tools/files to use]
- [Whether to act proactively]

Constraints
- [Scope limits]
- [What not to change]

Verification
- [Checks to run]

Output contract
- [Exact format to return]
- [Artifacts to write]

Avoid

• vague goals like "improve this"
• hidden completion criteria
• mixing examples, constraints, and background in one paragraph
• relying only on broad negative instructions when a positive target behavior can be stated
• asking for internal reasoning when a final answer, checklist, or evidence summary is enough

xAI Grok 4.x / Grok Code Handoff Patterns

Source snapshot: refreshed 2026-03-12 from official xAI docs

• Prompt Engineering for Grok Code
• Tools overview
• Structured outputs
• Reasoning

Start here

• Provide precise local context such as relevant files, dependencies, and the concrete goal.
• Phrase the task as a clear requirement, not a vague improvement request.
• Keep the scope tight and iterate with follow-up prompts when needed.
• Use structured outputs or tool schemas when the result must be machine-readable.
• Explicitly say when web search, X search, code execution, or function calling is expected.

Handoff emphasis

• Prefer file-targeted prompts over repo-wide "fix everything" requests.
• Name the exact files or components the model should use as references.
• Ask for concrete output and verification, not general suggestions.
• Remove irrelevant background so the model does not diffuse attention.

Reasoning and tool notes

• Do not ask for reasoning_effort on Grok 4 family models. That control is documented for grok-3-mini, not Grok 4.
• Grok supports OpenAI-compatible Responses API patterns plus built-in tools such as web search and code execution.
• Smaller, concrete prompts tend to outperform broad umbrella prompts in coding workflows.

Good shape

Context
- [Relevant files and constraints]

Objective
[One concrete deliverable]

Required references
- [Files, APIs, or docs to use]

Constraints
- [Scope limits]
- [What not to touch]

Verification
- [Checks to run]

Output
- [Exact return format]

Avoid

• prompts like "make this better"
• irrelevant repository background
• unsupported parameter guidance for Grok 4
• relying on free-form output when a schema is required