The sessions / Prompts & Workflows

A prompt written for another model has two audiences: you and the model receiving it. Name the model and tool, separate the operating instructions from the execution prompt, test one handoff, and record what actually happened.

5 min read

Read as: HTML / Markdown

You can ask one AI to help you write a prompt for another.

I do this often. Sometimes the writer and recipient are related models, such as OpenAI GPT-5.6 Sol helping me brief GPT-5.6 Terra. Sometimes the handoff crosses companies, such as Codex helping me brief Claude Fable 5.

That can improve a brief. The writing model may spot a missing boundary, a vague success test or a conflict in the sources. A cross-family handoff can also expose assumptions that are invisible when everything happens inside one tool.

But there are two audiences in the handoff:

1. You, the operator, need to know which model, effort, conversation, permissions and timing to choose.
2. The receiving model needs the bounded assignment, sources, permitted actions, validation and stop condition.

If those instructions are mixed together, a sentence written to guide you can become an action for the model.

What is the difference between a model and a tool?

The model generates the response. The tool or interface around it provides the environment in which it can read files, edit work, create tasks or delegate.

A phrase such as fresh task may read to a person as setup advice: open a clean conversation. Inside an agentic interface, the same words may be interpreted as authority to create another task.

So record both:

• model and version;
• reasoning or effort level;
• interface or tool;
• prompt sent;
• conversation chosen;
• action observed.

Without that record, a comparison between models may really be a comparison between tools, settings or routing rules.

Use one brief launcher with a deletion boundary

Keep the operating instructions you need and the short start prompt the model needs in one launcher, but separate them visibly. Save the full governing prompt in the shared workspace so the receiving model can read it there instead of requiring you to copy and paste it.

# KISH INSTRUCTIONS - DELETE THIS SECTION BEFORE SENDING

- Destination: [new or existing conversation]
- Model: [model]
- Effort: [effort]
- Tool or interface: [environment]
- Working root: [project]
- Permissions: [read/write boundary]
- Timing: [preflight and concurrency]
- Before sending: delete this entire section and both divider lines

================ DELETE EVERYTHING ABOVE THIS LINE ================
================ ACTUAL PROMPT STARTS BELOW THIS LINE ==============

EXECUTE IN THIS CURRENT CONVERSATION ONLY - DO NOT CREATE ANOTHER TASK.
Do not create, fork, delegate, launch or message another task, thread,
conversation, subagent or workflow.

[one-sentence assignment summary]
Work in [project root].
Read [full governing-prompt path] completely, adopt it as governing and
execute only that assignment.
[critical source/write boundary and stop condition]

The upper region can tell you to open a new conversation. Delete it before sending. The lower region speaks only to the model already receiving the prompt, briefly identifies the work and points to the full governing prompt it must read in place.

Why not use two launcher files?

Splitting the brief handoff across two files can separate its audiences technically, but it introduces another operating choice: which file to open, review and copy.

If your normal workflow is to ask for a launcher, read it, adjust it and paste its start prompt, one launcher with a hard deletion boundary keeps the whole handoff visible. The long governing prompt is still a separate project file, but you do not copy it. The receiving model reads it directly from the shared workspace.

Test one before starting many

Concurrency magnifies a prompt defect. If you have four assignments, begin with one. The first response should show the model reading or executing the task in the conversation you selected. If it says it will create another task, stop the rollout.

Confirm four things before continuing:

1. It is working in the selected conversation.
2. It has the right model and effort.
3. It can write only to its own output directory.
4. It knows where to stop.

Then start the others, with one writer per directory.

Another conversation is not automatically another desk

The two-desk method depends on separate judgement, not the number of windows.

A child worker created by a parent is still part of the first desk’s execution chain. It becomes a second desk only when it has a genuinely separate review role, checks the first desk’s work against evidence and cannot promote its own conclusion.

The human remains at the gate: choosing what question is worth asking, stopping the work when its topology is unclear and deciding what may become accepted evidence or public output.

A practical handoff record

For each important handoff, keep a short record:

This turns prompt portability from an assumption into an observable result.

Exercise: run a safe cross-model handoff

Choose a bounded, reversible task that writes to no shared or important files.

1. Ask one model to prepare the handoff for another model.
2. Use the one-launcher structure above.
3. Name both models, efforts and tools.
4. Save the full governing prompt in the shared workspace, delete the launcher’s operator section and send only its short start prompt.
5. Stop after the first response.
6. Record whether the recipient worked directly, asked for clarification, delegated or attempted to create another task.
7. Correct the handoff if necessary, then run it once more.

Evidence of completion: the before-and-after prompts, the model-and-tool record, the two observed first responses and a one-paragraph rule derived from the comparison.

So, how do I hand a prompt to another AI?

Treat the handoff as an interface between three participants: the model writing the prompt, you operating it and the model receiving it.

Name the tools as well as the models. Keep your operating instructions above a deletion boundary. Send only the short start prompt below it, which directs the model to read the full governing prompt in the shared workspace. Test one conversation before scaling. Record what actually happened.

The words are not portable until the outcome shows that they are.