PatrickJS/0-sidechat-vs-mainchat-vs-forkchat-vs-newchat.md

Last active May 27, 2026 23:28

Star (0) You must be signed in to star a gist
Fork (0) You must be signed in to fork a gist

Select an option

Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/PatrickJS/e9da66f95ce089fadcf5c16916bf38b1.js"></script>
Save PatrickJS/e9da66f95ce089fadcf5c16916bf38b1 to your computer and use it in GitHub Desktop.

Download ZIP

Guide for choosing main chats, side-chats, forks, new chats, and handoff prompts in Codex workflows.

Raw

0-sidechat-vs-mainchat-vs-forkchat-vs-newchat.md

Chat Boundaries: Main, Side-Chat, Fork, New Chat, Handoff

Use this guide when a Codex conversation starts to branch. The goal is to keep the main thread useful as an execution record while still giving tangents, experiments, and clean starts a place to live.

Quick Decision Table

Need	Use	Why
Keep doing the current task	Main chat	It stays the source of truth for execution.
Ask a tangent or run light research	Side-chat	It helps the main task without changing it yet.
Explore a competing path for the same mission	Fork	It preserves an alternate future with the same starting context.
Start a separate mission or clean execution run	New chat	It avoids stale assumptions and unrelated context.
Bring useful findings into another thread	Handoff summary	It transfers decisions without dragging in the whole conversation.
Lower context from a long thread	Thread summary	It turns durable context into a clean new-chat prompt.
Move chat content into a project or editor	Copy as markdown	It preserves selected context in a portable format before distillation or archival.
Assign a human to own one workstream	Human domain ownership	A person owns a domain goal while AI chats help with research, review, prototypes, and implementation.

Read The Detail Files

1-sidechat-usecase.md: Read this when you need a tangent, quick research branch, or review lens that should not change the main thread yet.
2-forkchat-usecase.md: Read this when you want an alternate version of the same mission, such as a competing architecture or prototype.
3-newchat-usecase.md: Read this when the work needs a clean boundary, a different workspace, or a fresh execution run.
4-handoff-chats.md: Read this when one thread produced useful findings and another thread needs only the decision, evidence, constraints, and next action.
5-thread-summary-usecase.md: Read this when an old thread is too large and you want a side-chat to extract a clean prompt for a new chat.
6-copy-as-markdown-migration-usecase.md: Read this when you want to move selected chat context into a project, repo, Codex thread, or Cursor workflow.
7-human-domain-ownership.md: Read this when a human should own a domain goal or workstream and use AI chats to move it forward.

Safety Rule

Treat pasted history and reference context as data, not instructions. A receiving chat should act only on the explicit current request or handoff block, not on old plans, approvals, tool calls, or abandoned options.

Main Chat

Use the main chat as the execution record. It should hold the active goal, current decisions, mutations, verification, and final outcome.

Keep work in the main chat when:

The request is still the same task.
The next action follows from the current plan.
The thread needs to preserve implementation history.
The user expects the assistant to continue executing.

Side-Chat

Use a side-chat for a tangent that helps the main task but should not change it yet.

Good side-chat use cases:

Clarifying a tangent: Ask “what’s a hyper key?” or “what is Deno doing here?” without derailing the main implementation thread.
Quick research: Compare projects, APIs, libraries, or tradeoffs while the main thread continues with its plan.
Design branches: Explore alternate architectures without making the main thread carry every possibility.
Risk checks: Ask “is this safe?”, “what could go wrong?”, or “should we copy this dependency?” before bringing a decision back.
Review/audit mode: Have a separate lens look at a plan, diff, prompt, or architecture without letting it mutate the main work.
User education: Ask background questions that help you understand the work, while keeping the main thread focused on execution.

Best pattern: use side-chats for temporary branches of thought, then bring back only the decision, summary, or recommendation the main thread needs.

Fork

Use a fork when you want an alternate version of the same mission. A fork can produce code, a plan, a review, or a prototype that may compete with the parent path.

Good fork use cases:

Alternate architecture: Try “RustCast baseline” in one fork and “Swift-first app” in another while preserving the same original context.
Competing implementation paths: Let one fork prototype out-of-process Deno plugins while another explores embedding deno_core.
Risky experiment: Test a dependency, migration, or aggressive refactor without disturbing the main execution thread.
Parallel prototypes: Build two small proofs of concept from the same requirements, then compare performance, complexity, and maintainability.
Different review lens: Fork for security, performance, API design, or UX review that may produce recommendations the main thread should not automatically adopt.

Best pattern: use forks for alternate versions of the same mission, then bring back only the winning decision, evidence, and next action.

New Chat

Use a new chat when the task deserves a clean boundary.

Good new-chat use cases:

New mission: Start a separate project, repo, bug, research task, or implementation goal that does not depend on the current thread.
Clean context: Begin fresh when the old thread has too many assumptions, tangents, or stale decisions.
Different workspace: Switch to another repo, app, machine area, account, or operational context.
Clean execution run: Move from messy exploration into a focused “implement this plan” session.
Sensitive boundary: Separate tasks with different trust, privacy, security, or credential concerns.
Role reset: Start fresh when you want a different stance, such as code review, security audit, planning, or product critique.

Best pattern: use new chats for new missions or clean execution boundaries, then keep the thread focused on that one task until it is done.

Handoff Summaries

Convert a chat when the useful output should influence another thread, but the full conversation would add noise.

Use this shape:

Context:
We explored native Raycast replacements and Deno plugin architecture.

Decision:
Use RustCast as the lightweight baseline, Sol as native macOS reference, SuperCmd as Raycast API reference, and Kunkun as the permission model.

Evidence:
RustCast fits the low-RAM/native direction. Sol has useful Swift/AppKit helpers. SuperCmd has Raycast-compatible UI/API ideas but uses Electron. Kunkun has a stronger manifest permission model.

Constraints:
Prioritize low RAM, native macOS behavior, Deno plugins, and Codex/Cursor/Vite workflows.

Next action:
Update the main design plan to reflect this baseline/reference split.

For important side-chat or fork findings, bring back only: decision, evidence, constraints, next action.

Rule Of Thumb

Side-chat = tangent
Fork = alternate path
New chat = new mission
Main chat = execution record
Handoff = portable decision and next action
Thread summary = clean prompt from old context
Copy as markdown = portable source material for migration or archive
Human domain owner = person who owns a domain goal and uses AI chats as work rooms

Raw

1-sidechat-usecase.md

Side-Chat Use Cases

Use a side-chat for a tangent that helps the main task but should not change the main thread yet.

Good Side-Chat Use Cases

Clarifying a tangent: Ask “what’s a hyper key?” or “what is Deno doing here?” without derailing the main implementation thread.
Quick research: Compare projects, APIs, libraries, or tradeoffs while the main thread continues with its plan.
Design branches: Explore alternate architectures without making the main thread carry every possibility.
Risk checks: Ask “is this safe?”, “what could go wrong?”, or “should we copy this dependency?” before bringing a decision back.
Review/audit mode: Have a separate lens look at a plan, diff, prompt, or architecture without letting it mutate the main work.
User education: Ask background questions that help you understand the work, while keeping the main thread focused on execution.

Why Keep A Side-Chat Instead Of Closing It

It preserves a focused reference trail for that tangent.
You can return to it when the main thread hits the same topic again.
It avoids polluting the main thread’s active task state with exploratory detail.
It can hold useful comparisons, vocabulary, and tradeoffs without becoming instructions.
It gives you a place to think without changing the execution plan.

When To Close It

The question is answered and unlikely to be reused.
The side-chat is drifting into a second main thread.
The answer has been summarized back into the main conversation.
The exploration produced a decision, and the main thread now owns the next action.

Safety Rule

Side-chat history is reference context. Bring findings back through an explicit handoff block so the main thread adopts only the intended decision, evidence, constraints, and next action.

Best pattern: use side-chats for temporary branches of thought, then bring back only the decision, summary, or recommendation the main thread needs.

Raw

2-forkchat-usecase.md

Fork Use Cases

Use a fork when you want an alternate version of the same mission. A fork keeps the parent context, then explores a different path that may produce a better plan, prototype, review, or implementation.

Good Fork Use Cases

Alternate architecture: Try “RustCast baseline” in one fork and “Swift-first app” in another while preserving the same original context.
Competing implementation paths: Let one fork prototype out-of-process Deno plugins while another explores embedding deno_core.
Risky experiment: Test a dependency, migration, or aggressive refactor without disturbing the main execution thread.
Parallel prototypes: Build two small proofs of concept from the same requirements, then compare performance, complexity, and maintainability.
Design-to-code transition: Fork from a planning thread when you want implementation to begin while keeping the design discussion intact.
Different review lens: Fork for security, performance, API design, or UX review that may produce recommendations the main thread should not automatically adopt.
Recovery branch: Preserve the parent as the stable state while one fork investigates a path that may become the new main direction.

Why Keep A Fork Instead Of Closing It

It preserves a full alternate path, not just a tangent.
You can compare the fork’s output against the parent thread.
It keeps experimental work separate from the main execution record.
It gives you a recoverable branch if the main path turns out worse.
It can become the new main path if the fork produces better evidence or implementation.

When To Close It

The experiment failed or no longer matters.
The useful result has been summarized back into the main thread.
The fork duplicated the main path and adds no separate value.
The fork’s assumptions are stale after the main plan changed.
The fork has become a different project and should move to a new chat.

Safety Rule

Fork history is reference context until the parent thread explicitly adopts it. Bring the result back as a handoff block with the winning decision, evidence, constraints, and next action.

Best pattern: use forks for alternate versions of the same mission, then bring back only the winning decision, evidence, and next action.

Raw

3-newchat-usecase.md

New-Chat Use Cases

Use a new chat when the work deserves a clean boundary. A new chat should own one mission, one workspace, or one execution run without inheriting stale assumptions from older threads.

Good New-Chat Use Cases

New mission: Start a separate project, repo, bug, research task, or implementation goal that does not depend on the current thread.
Clean context: Begin fresh when the old thread has too many assumptions, tangents, or stale decisions.
Different workspace: Switch to another repo, app, machine area, account, or operational context.
Clean execution run: Move from messy exploration into a focused “implement this plan” session.
Sensitive boundary: Separate tasks with different trust, privacy, security, or credential concerns.
Role reset: Start fresh when you want a different stance, such as code review, security audit, planning, or product critique.
Long-running replacement: Open a new thread when the current one has become too broad to remain an effective execution record.

Why Keep A New Chat Instead Of Returning To The Old One

It gives the task a clean source of truth.
It avoids inherited assumptions from unrelated work.
It makes the execution history easier to audit later.
It reduces accidental carryover from old plans or decisions.
It lets the new task develop its own focused context.

When To Close It

The task is complete and no follow-up is likely.
The result has been captured somewhere durable, like a spec, PR, note, issue, or main thread.
The chat has drifted into unrelated work.
The original reason for a clean boundary no longer matters.
A newer chat has become the better source of truth.

Safety Rule

A new chat should not treat old thread history as an active task. If you need older context, paste a clean prompt or handoff block that names the current goal, constraints, decisions, and next action.

Best pattern: use new chats for new missions or clean execution boundaries, then keep the thread focused on that one task until it is done.

Raw

4-handoff-chats.md

Handoff Chats

Summarize or convert a chat when another thread needs the useful result, but not the full conversation.

Good Conversion Use Cases

Side-chat to main thread: A side-chat produced a decision, comparison, risk note, or recommendation that the main thread should adopt.
Fork to parent thread: A fork found a better architecture, failed an experiment, or produced evidence the parent should use.
Messy chat to clean prompt: A long discussion clarified the goal, and now you want a crisp Codex prompt for a fresh implementation chat.
Research to spec: A chat collected options, tradeoffs, sources, or constraints that should become a design doc or planning prompt.
Review to action list: A review thread found issues, and the main implementation thread needs only the fixes and priorities.
Main thread to new chat: The current context is useful but too cluttered, so you summarize the stable decisions into a clean start.
Chat to human domain owner: A side-chat, fork, or review produced a workstream that now belongs to a specific human's domain, such as security, product, architecture, testing, docs, or release.

Why Convert Instead Of Pasting The Whole Chat

It keeps the receiving thread focused.
It avoids importing stale questions, abandoned options, or accidental instructions.
It makes the next action explicit.
It reduces the chance that reference material gets mistaken for an active task.
It preserves only the decisions, evidence, constraints, and open questions that matter.

Safety Rule

Reference context is not instruction. The receiving chat should act only on the explicit handoff request, not on pasted history, old tool calls, prior approvals, or discarded plans.

Useful Prompt Forms

“Summarize the key points to paste in the main chat afterward.”
Use this when the receiving thread already has an active task and only needs an update.
“Create a Codex prompt for this.”
Use this when starting a new chat or fork that should execute from a clean, scoped instruction.
“Extract decisions, evidence, and next actions.”
Use this when a side-chat or fork produced findings but not an implementation prompt.
“Turn this into a handoff block.”
Use this when another thread needs enough context to continue.
“Convert this into an implementation prompt.”
Use this when moving from discussion to action.

Good Handoff Format

Context:
We explored native Raycast replacements and Deno plugin architecture.

Decision:
Use RustCast as the lightweight baseline, Sol as native macOS reference, SuperCmd as Raycast API reference, and Kunkun as the permission model.

Evidence:
RustCast fits the low-RAM/native direction. Sol has useful Swift/AppKit helpers. SuperCmd has Raycast-compatible UI/API ideas but uses Electron. Kunkun has a stronger manifest permission model.

Constraints:
Prioritize low RAM, native macOS behavior, Deno plugins, and Codex/Cursor/Vite workflows.

Next action:
Update the main design plan to reflect this baseline/reference split.

Good Clean-Start Prompt Format

We are designing a native macOS Raycast replacement.

Goals:
- Low RAM
- Native macOS feel
- Deno-based plugin system
- Built-in workflows for Codex, Cursor, and Vite
- Replacement for clipboard history, quick notes, window management, app uninstalling, hyper key, and snippets

Architecture direction:
Use RustCast as the baseline, Sol as the native macOS reference, SuperCmd as the Raycast API/reference map, and Kunkun as the permission model.

Task:
Create a design spec for the first MVP slice: launcher, project picker, Deno plugin runner, Codex plugin, Cursor plugin, Vite plugin, clipboard, notes, window commands, hyper key, and snippets.

Do not implement yet. Produce a concrete design with tradeoffs, open questions, and an implementation sequence.

Rule Of Thumb

Paste summary = update an existing active thread
Create prompt = start a clean thread or fork
Handoff block = transfer decisions without dragging in noise
Spec/action list = turn exploration into durable work

Best pattern: after any useful side-chat or fork, ask for decision, evidence, constraints, next action.

Ownership Handoff

Hand off ownership when another human should own the goal, judgment, and acceptance for a domain. Do not hand them the whole messy thread as the task. Convert the thread first, then give them the workstream they own.

Use this shape:

New owner:
Security lead

Domain:
Authentication and token handling

Goal:
Decide the acceptable credential storage model before implementation continues.

Context:
A fork explored two auth designs and found that local token storage is the highest-risk part of the plan.

Why this is moving:
The next step needs security acceptance, not more prototype output.

Current decision:
Do not ship persistent tokens until storage and revocation behavior are reviewed.

Evidence:
The prototype stores long-lived credentials locally. The implementation path works, but the failure mode needs security ownership.

Constraints:
Avoid printing secrets. Avoid copying raw logs. Keep the review in a clean thread with sanitized examples.

Open questions:
- Should tokens be short-lived?
- Should credentials live in Keychain?
- What revocation behavior is required?

Authority transferred:
The security lead can approve, reject, or change the credential storage approach.

Next action:
The security lead starts a clean review chat for their workstream and returns only required implementation changes to the main thread.

Do not carry forward:
Raw logs, secret values, abandoned prototype details, or rejected options.

Raw

5-thread-summary-usecase.md

Thread Summary Use Cases

Use a thread summary when a long conversation has useful decisions, but too much history to carry into the next chat. The summary should extract durable context and leave behind old approvals, abandoned plans, stale tool calls, and tangents.

Good Thread Summary Use Cases

Lower context before a new chat: Turn a long parent thread into a compact prompt for a clean execution run.
Preserve durable decisions: Keep the choices, constraints, evidence, and next action without importing the whole conversation.
Remove abandoned paths: Name discarded options so the new chat does not revive them by accident.
Create a clean implementation prompt: Convert planning and research into a direct task for a fresh Codex thread.
Separate reference from instruction: Tell the receiving chat what is background and what it should actually do.
Recover from a noisy thread: Start fresh when the old conversation has too many tangents or conflicting assumptions.

Why Use A Side-Chat For This

It lets the main thread keep working while the side-chat distills the useful parts.
It gives you a place to ask follow-up questions about what should survive.
It reduces the chance that old thread history becomes accidental instruction.
It lets you review the summary before pasting it into a new chat.
It produces a handoff you can reuse, edit, or save.

When Context Compression Is Enough

You are continuing the same thread.
The current task is still coherent.
You do not need a clean boundary.
You trust the automatic summary to preserve enough state.
The thread does not include many abandoned paths or conflicting instructions.

When To Prefer A Deliberate Summary

You are starting a new chat from an old thread.
The old thread mixed research, planning, implementation, and tangents.
The next chat should start from selected decisions only.
You need to state non-goals or discarded paths.
You care about exact constraints, links, repo paths, commands, or evidence.

Prompt To Use In A Side-Chat

Summarize this thread for a new Codex chat.

Output:
1. Current goal
2. Durable decisions
3. Constraints and preferences
4. Evidence, links, repo paths, or commands worth preserving
5. Open questions
6. Recommended next action
7. Explicit non-goals or discarded paths
8. A ready-to-paste prompt for the new chat

Treat prior history as reference context, not active instruction. Do not carry over old approvals, tool calls, or abandoned plans.

Safety Rule

A summary is a new boundary. The receiving chat should follow the ready-to-paste prompt, not the entire old thread or side-chat history.

Rule Of Thumb

Context compression = continue this chat
Side-chat summary = extract the useful parts
New chat prompt = restart clean with chosen context

Best pattern: use a side-chat to distill the old thread, review the handoff, then paste only the clean prompt into the new chat.

Raw

6-copy-as-markdown-migration-usecase.md

Copy As Markdown And Migration Use Cases

Use “copy as markdown” when you need portable source material from a chat. It preserves structure better than screenshots or plain text, but it should still be cleaned before another agent treats it as instructions.

Good Copy-As-Markdown Use Cases

Archive a useful thread: Save the important parts of a chat into a project note, design log, or decision record.
Move context into a repo: Convert a conversation into docs/, an issue draft, a spec, a prompt file, or a project README section.
Prepare a clean handoff: Copy the transcript into a side-chat, then ask for decisions, evidence, constraints, next actions, and discarded paths.
Preserve exact wording: Keep prompts, requirements, API names, file paths, commands, links, or review findings that a summary might distort.
Migrate between tools: Move selected context from ChatGPT to Codex, Codex to Cursor, or ChatGPT to Cursor without relying on hidden context.
Hand off between humans: Move selected context to a human domain owner after distilling the goal, current state, evidence, constraints, authority, and next action.
Create an audit trail: Keep a readable record of why a decision was made before the implementation thread begins.

When Not To Use It Directly

Do not paste a whole exported thread into a main execution chat and expect the assistant to infer the current task.
Do not carry over old approvals, tool calls, failed plans, or abandoned branches as active instructions.
Do not include secrets, tokens, private keys, raw auth output, or sensitive customer data.
Do not use raw chat export as a substitute for a scoped prompt.

Chat To Project

Use this when a conversation produced durable project knowledge.

Good targets:

docs/decisions/YYYY-MM-DD-topic.md
docs/specs/topic.md
docs/context/topic.md
issue or PR description drafts
project README notes
local prompt files for repeatable workflows

Recommended shape:

Context:
What problem this thread covered.

Decision:
What the project should now treat as true.

Evidence:
Links, files, commands, examples, or results worth preserving.

Constraints:
Rules the implementation should follow.

Next action:
What someone should do next in the repo.

ChatGPT To Code

Use this when ChatGPT helped with product thinking, research, or requirements and Codex needs to implement in the repo.

Workflow:

Copy the useful ChatGPT section as markdown.
Ask for a clean Codex prompt with goal, repo path, constraints, evidence, non-goals, and verification commands.
Start Codex in the repo.
Tell Codex to inspect the local files before changing anything.
Treat copied ChatGPT content as reference, not as a patch to apply blindly.

Prompt shape:

We are working in <repo path>.

Goal:
<concrete task>

Context from ChatGPT:
<short distilled summary, not the full transcript>

Constraints:
<what must stay true>

Non-goals:
<what not to do>

Verification:
<commands or manual checks>

Before editing, inspect the current repo and reconcile this context with the actual code.

ChatGPT Or Codex To Cursor

Use this when Cursor should edit, navigate, or continue an implementation with IDE context.

Workflow:

Copy the relevant chat section as markdown.
Distill it into a Cursor prompt with target files, desired change, constraints, and checks.
Open the repo in Cursor.
Paste the prompt into Cursor chat or run Cursor Agent with the repo as workspace.
Ask Cursor to verify against local files, not just the copied transcript.

Cursor prompt shape:

Workspace:
<repo path or project name>

Task:
<specific edit or review>

Relevant files:
- <file path>
- <file path>

Context:
<distilled chat findings>

Constraints:
<style, architecture, safety, or API rules>

Checks:
<tests, build, lint, browser checks, or manual verification>

Treat the copied chat context as reference. Inspect the current workspace before editing.

Codex To Cursor

Use this when Codex produced a plan, review, or file-level diagnosis and Cursor should do IDE-guided editing.

Best payload:

goal
target files
exact findings or plan steps
constraints
commands Codex already ran
commands Cursor should run after edits
open questions that need human input

Human To Human Ownership

Use this when another human should take over a domain goal, not just read a transcript.

Workflow:

Copy only the relevant chat sections as markdown.
Distill the transcript into an ownership handoff block.
Name the new owner, domain, goal, current state, decisions, evidence, constraints, authority transferred, and next action.
Remove stale instructions, rejected options, secrets, raw logs, and old approvals.
Give the new owner a clean thread or project note for their workstream.

See 7-human-domain-ownership.md for the ownership handoff format.

Safety Rule

Copied markdown is source material, not authority. The receiving tool should act only on the explicit prompt you write around it.

Best pattern: copy as markdown, distill it, remove stale instructions, then paste a clean prompt into the project, Codex, or Cursor.

Raw

7-human-domain-ownership.md

Human Domain Ownership And Handoff

Use human domain ownership when one project has several goals that need different judgment. A human owns a domain goal or workstream. AI chats are the work rooms that human uses for research, review, prototypes, and implementation.

Core Model

Project = shared outcome
Human domain owner = person who owns a goal or workstream inside the project
AI chats = work rooms for research, review, prototypes, and implementation
Main chat = accepted project record
Human handoff = transfer of ownership, authority, and next action

The human does not receive a chat as the job. The human receives a goal, a domain boundary, and authority to decide what happens inside that boundary.

Good Ownership Domains

Product and UX
Architecture
Data model
Security and privacy
Agent workflows
Testing and release
Docs and onboarding

The owner decides what good means for that domain, chooses which AI findings matter, and returns accepted decisions to the main project thread.

Chat Type Vs Human Ownership

Chat type says where AI work happens. Human ownership says who drives the workstream.

Side-chat = tangent or focused research
Fork = alternate path
New chat = clean mission
Main chat = accepted execution record
Human domain owner = person who owns judgment and acceptance

A domain owner can use side-chats for research, forks for competing solutions, and new chats for clean execution. The main chat should receive only accepted decisions, evidence, constraints, and next actions.

When To Convert A Chat

Convert a chat when the useful output should move, but the same human still owns the workstream.

Good conversion cases:

A side-chat produced a recommendation.
A fork produced evidence for or against an implementation path.
A review found issues the main thread should fix.
Research should become a spec, action list, or implementation prompt.
A long thread needs a clean summary before the next execution run.

Conversion output should include:

Decision
Evidence
Constraints
Open questions
Next action

When To Hand Off To Another Human

Hand off to another human when the next useful step requires their ownership, not more AI output.

Good handoff triggers:

The work crossed into their domain.
They need to accept or reject the result.
The current human has become the bottleneck.
A side-chat or fork produced a real workstream.
The project split into separate goals that one person should not hold alone.
The next phase needs a different judgment lens.
The work has risk that belongs to a specific owner.

Do not hand off just because a chat is long. Convert the chat first. Then decide whether ownership should move.

Ownership Handoff Format

Use this when moving responsibility to another human.

Human owner:
<person or role>

Domain:
<area they own>

Goal:
<outcome this human is responsible for>

Why this is moving:
<why this now belongs to them>

Current state:
<what has happened so far>

Decisions already made:
- <decision>

Evidence:
- <fact, file, result, link, or finding>

Constraints:
- <rule they should preserve>

AI chats they may need:
- Side-chat for research
- Fork for alternate solution
- New chat for clean implementation

Authority transferred:
<what this human can decide, approve, reject, or send back>

Return to main thread with:
- decision
- evidence
- constraints
- next action

Do not carry forward:
<stale context, rejected options, raw logs, secrets, old approvals>

Example

Human owner:
Security lead

Domain:
Authentication and token handling

Goal:
Decide the acceptable credential storage model before implementation continues.

Why this is moving:
The next step needs security acceptance, not more prototype output.

Current state:
A fork explored two auth designs and found that local token storage is the highest-risk part of the plan.

Decisions already made:
- Do not ship persistent tokens until storage and revocation behavior are reviewed.

Evidence:
- The prototype stores long-lived credentials locally.
- The implementation path works.
- The failure mode needs security ownership.

Constraints:
- Avoid printing secrets.
- Avoid copying raw logs.
- Use sanitized examples in the review thread.

AI chats they may need:
- Side-chat to compare token lifetimes and revocation behavior.
- Fork to test Keychain-backed storage.
- New chat for a clean implementation prompt after the decision is made.

Authority transferred:
The security lead can approve, reject, or change the credential storage approach.

Return to main thread with:
- credential storage decision
- evidence for the decision
- implementation constraints
- required code changes

Do not carry forward:
Raw logs, secret values, abandoned prototype details, or rejected options.

Rule Of Thumb

Convert when context should move.
Hand off when ownership should move.
Do both when another human should drive the goal with their own AI chats.