Handing Off an In-Progress Project: Transferring Prompts, Prompts Config and Key Context to a Teammate

Why Handoff Is a Project Problem, Not a Chat Problem

Most LLM work lives in ad-hoc chats, notebooks and half-remembered settings. When someone else takes over, the model does not need to be explained — the project around the model does. A good handoff packages four things so the successor can run the project without asking you questions:

• The prompts themselves (full text, not summaries)
• The configuration each prompt expects (model, parameters, system instructions)
• Credentials and spend context for the API account
• Notes on what has been tried, what worked, and what is still open

Treat the handoff as a small internal deliverable with a version and a date, not a chat message.

Build a Prompt Inventory

Start by listing every prompt that matters. For each one, capture:

• A short ID or name and its purpose in one sentence
• The complete prompt text, including system and user parts
• Template variables and an example of filled-in values
• Expected output shape (plain text, JSON schema, list of items)
• Known failure modes you have already observed

Store prompts as individual files (for example, one markdown or text file per prompt, or a single structured file with an entry per prompt) rather than pasting them into a document inline. Files can be diffed, copied and loaded directly by the successor's scripts.

If a prompt has variants (A/B tests, per-language versions, short and long forms), keep them together and label which one is the current default.

Record Model Choices and Call Settings

A prompt is only half the artifact. The other half is how it is called. For each prompt or workflow step, record:

• The model family and specific model used, and why (cost, latency, quality on your task)
• Temperature and other sampling settings
• Max output length and any stop conditions
• System-level instructions or persona text, which often live outside the prompt body
• Retry and fallback behavior, if any
• Which provider or endpoint was used

Where a project routes across several models, describe the routing rule instead of listing every call: for example, a stronger model for drafting and a cheaper one for classification or extraction. Include a note on which steps are quality-critical and which are cost-sensitive, so the successor knows where swapping models is safe.

Separate Settings From Code

Settings buried in scripts are the most common cause of handoff breakage. Move model names, temperatures and prompt paths into a config file or environment variables, with a checked-in example file showing every key. The successor should be able to change a model or a parameter by editing configuration, not by hunting through code.

Keep a short changelog of settings decisions: what was changed, when, and what effect it had. Even a few lines per entry prevents the successor from repeating experiments you already ran.

Hand Off Credentials Carefully

Do not put API keys in the project archive, the repository, or a shared document. Use a separate, revocable transfer:

• Issue a fresh key for the successor where the provider supports multiple keys, rather than sharing yours
• Document how the key is supplied (environment variable name, secret manager entry)
• Note any account-level context they need: which account funds the project, how billing works, and any spend limits configured
• Record the platform's pricing model in plain terms so the successor can forecast spend

On this platform, usage is paid with USDC on Base with no KYC, and a single key can call many models. Billed cost is the official price multiplied by 1.3, and contributors are credited official price × 1.1 (× 1.2 for premium) in USDC. Note that this is a payment model, not a guarantee of net savings — include it so the successor can budget realistically and know where credits come from.

If the project has accumulated contributor credit, say so explicitly and explain how it is tracked, rather than assuming the successor will discover it.

Write the Context Note

A short context note saves the most time of anything in the package. Cover:

• What the project is supposed to do and who uses its output
• The current state: working, partially working, experimental
• What has been tried and rejected, and why
• Open questions and known bugs
• The next three things you would do if you kept working on it
• Where data lives, how it is refreshed, and any privacy constraints on it

Keep it factual. Link to prompt IDs and config keys rather than duplicating their contents.

Assemble and Verify the Package

Put the pieces in one place with a simple structure, for example a prompts directory, a config directory with an example env file, a context note, and a changelog. Then verify it the way the successor will use it:

• Follow your own setup instructions from a clean environment
• Run one representative prompt end to end using only the packaged files
• Confirm every prompt reference resolves and every config key is documented
• Check that no secrets are present in the archive

Note the exact versions of relevant libraries and the date of the handoff, so later drift is easy to attribute.

Make the Handoff Walkthrough Short but Real

Finish with a brief walkthrough, live or recorded, in which the successor runs one call themselves while you watch. Cover how to read the config, how to change a model, and where spend and credit information is visible. Ask them to write down the first thing they did not understand, and add it to the context note. That single feedback loop turns a one-time transfer into documentation the next handoff can reuse.

Handoff Checklist

• Prompt inventory with full text, variables, examples and failure notes
• Per-prompt model, parameters, system instructions and fallback rules
• Settings externalized to config, with a documented example file
• Changelog of settings and prompt changes
• Fresh, revocable API key transferred out of band; no secrets in the package
• Spend and credit context, including the ×1.3 billing and ×1.1/×1.2 contributor credit model
• Context note: current state, dead ends, open questions, next steps
• Clean-environment test of the package and a short live walkthrough