Native Soil
Guides

Save a project from a thread that is out of room

When a ChatGPT chat gets too long for `soil save` to run, have the model write out the project's working state and save that record as a handover with its own load code.

The problem

In a very long or old ChatGPT chat, ChatGPT can stop exposing the connector's tools to that specific chat. The model says the Soil tools are not available here, or that it cannot run soil save. This is a ChatGPT limitation in how it carries connectors across long chats, not a Soil outage. (See the same explanation under ChatGPT · if Soil's tools go missing.)

You cannot run a normal save from inside that thread. But you can still capture the project. Instead of Soil reaching into the chat, you ask the model to write out the project's working state as a structured record · the decisions, the constraints, the current task, the next steps. You paste that record into Soil, and it is stored as a normal handover with its own #NNN load code. What lands in Soil is the project state the model wrote out, produced at your request, not the conversation.

Save the project state

Copy the prompt

The Import page shows the prompt below and a copy button. It asks the model to write the project's working state out as one structured json record. This is rendered from the single source of truth, @soil/rescue-prompt (the same constant the Import page uses), so it can never drift from the live prompt:

Rescue prompt
Produce a SAVE of everything important in THIS conversation so it can be reloaded into a fresh AI session. Output ONE fenced ```json code block and nothing else (no text before or after).

The JSON object must have EXACTLY these top-level keys and no others:
- "projectId": a short stable slug for the project (lowercase, hyphens), e.g. "billing-rework"
- "title": a short human title for this save
- "extractionSections": an object containing ALL 17 of these keys, in this order:
    projectIdentity, decisions, workflow, architecture, constraints, rejectedPaths,
    executiveSummary, currentTask, latestUserIntent, sessionDelta, blockers, nextSteps, openQuestions,
    sessionActivity, restoreInstructions, provenanceMap, safetySummary

What each section holds (fill EVERY one from this conversation):
- projectIdentity: what the project is, its purpose, who it is for, the project's own working language (its named concepts and terms with their agreed meanings — enumerate them, do not sample), and how the user likes to work.
- decisions: ENUMERATE every settled decision with its reasoning, even ones decided long ago. List them all; do not summarise them away.
- workflow: how the work is run, the review/done rules, and the standing "always do X / never do Y" corrections.
- architecture: the durable shape of the system or work and how the parts fit (by name, never private absolute paths).
- constraints: the hard invariants this project must never violate, each with why it binds.
- rejectedPaths: what was tried or considered and deliberately discarded, and why.
- executiveSummary: one screen orienting a cold reader: what this is, where it stands, the single most important next thing.
- currentTask: the task in flight, the approach and why, how far along, what "done" looks like, plus the live current status.
- latestUserIntent: the last substantive direction the user gave, in their own words; it overrides any stale earlier plan.
- sessionDelta: what changed this session versus where it started (decided, built, reversed, learned, unblocked).
- blockers: what is blocking progress, what was tried, and the dependency it imposes.
- nextSteps: the concrete, ordered next actions, specific enough to start immediately.
- openQuestions: what is genuinely still undecided, so the next model does not assume.
- sessionActivity: the consequential actions taken this session and their outcomes (meaning only, never raw logs).
- restoreInstructions: ONE paste-ready, standalone boot prompt covering the WHOLE working state so a cold model can continue with the smallest practical loss of operationally important state; state known or suspected omissions instead of implying completeness.
- provenanceMap: where the load-bearing claims came from and how confident you are; never present a guess as verified.
- safetySummary: anything you withheld for safety; say that it exists and where it is configured, never its value. "none" if nothing.

Rules:
- Each section value is a single plain-prose string. If a section genuinely does not apply or you have nothing for it, set that key to the object {"status":"missing","summary":null} instead of a string.
- SELF-CONTAINED IS THE RULE: assume the reader has ONLY this block, no repo, no docs, no links, no earlier thread. INLINE the content in every section. Never point outward, no "see the repo", "in the docs", "refer to the file", or a bare link, in ANY section; if the reader would have to fetch something, paste it in instead.
- Write about the PROJECT, not about the act of saving. The save itself is not a decision, task, or next step.
- Do NOT include any secrets, API keys, tokens, passwords, or private absolute file paths. They will be rejected.
- Output ONLY the ```json block.

Paste it into the stuck thread

Paste the prompt as a new message in the stuck ChatGPT thread. The model reads what it still has and writes the project's state out as a single fenced json block · that block is the record you are saving, produced by the model at your request.

Copy the model's reply

Copy the whole json block the model produced, fences and all. That block is the project record · the decisions, constraints, and next steps the model wrote out, not the raw chat.

Paste it into Import

Back on the Import page, paste the block into the field and click Import. Soil runs the record through the same safe save path as a normal save, safety scan included, and stores that derived record. It lands as a real handover with its own #NNN load code · loadable in any client, exactly like one you saved with soil save.

This is still bounded by what the model can still read in that thread · if the thread has dropped earlier context, the record can only cover what the model can still see. Saving early under stable #names is always better than doing this late. And the receipt rule holds: a real save shows a #NNN; if it doesn't, it didn't save. The record is safety-scanned on the way in, and any secrets are rejected · don't paste them.

When to do this vs start a new chat

If you can recreate the context yourself, just start a new chat · the tools return immediately · and run soil save there. That's the simpler path.

Writing the state out is for the case where the thread holds a working state you can't easily recreate: a long debugging session, a sequence of decisions, a structure you worked out turn by turn. Then it's worth one round-trip to have the model write that state out and save it before the thread is gone for good.

On this page