--- name: nocap-context-transfer description: Generates a structured continuation block for carrying work state into a new conversation. Use when the user says "context transfer", "handoff", "generate transfer", "continuation block", or asks for something they can paste into a new chat to continue specific work. Not a summary. A continuation point that tells the new instance what state to be in. --- # Context Transfer Protocol Author: HyperWorX (https://github.com/HyperWorX) License: MIT This skill generates a structured block the user can paste into a new conversation to continue work at a specific point. It is not a summary. It is a continuation point. The difference: a summary tells you what happened. A continuation point tells the new instance what it needs to know to pick up at this exact step without re-deriving the state. --- ## When to Use Trigger phrases: "context transfer", "handoff", "generate transfer", "continuation block", "give me something to paste into a new chat", or any request to package current state for another conversation. "Summary" is not a trigger. If the user asks for a summary of the conversation, that is a different request. This skill triggers on continuation and transfer language specifically. --- ## What to Generate Produce a single copyable block with these sections. Use the exact headers below. The user will paste this as the first message of a new conversation. ``` CONTEXT TRANSFER Source: [chat title or topic identifier] Generated: [date] Transfer scope: [what specific work stream is being transferred] TASK [One paragraph. What is the work. What is its purpose. What is the user trying to achieve. Not the history of how we got here, just what the task is.] CURRENT STATE [Where we are right now. Specific step, phase, or milestone. What was the last thing completed. What is the next action.] KEY DECISIONS [Numbered list. Each entry: the decision, the reasoning, and what was rejected. These are load-bearing. If the new instance doesn't know these, it will re-derive them and may reach different conclusions.] CONSTRAINTS AND REQUIREMENTS [Anything the new instance must follow. File formats, naming conventions, style requirements, technical constraints, explicitly rejected approaches.] OPEN ITEMS [What remains to be done. Ordered by dependency if applicable.] FILE LOCATIONS [Any files, outputs, or artifacts produced. Include absolute paths so the new session can Read them directly. Claude Code operates on the local filesystem and files persist between sessions if not manually deleted. Portability caveat: absolute paths only resolve if both sessions share the same filesystem. For cross-machine handoffs, either inline the file contents in BACKGROUND REQUIRED or note that the files must be copied to the receiving machine at the same paths before use.] BACKGROUND REQUIRED [Files or documents the new instance should have in context to understand the decisions and continue the work. List each with a brief description of what it contains and why the new instance needs it. Include absolute paths so the new session can Read them directly. If the work is simple enough to be self-contained in this block, state "None, this block is self-contained."] DO NOT [Explicitly rejected approaches, dead ends, things that were tried and failed. The new instance needs to know what NOT to do as much as what to do.] PROTOCOL STATE Mode: [no cap / creative / default] Trace: [minimal / standard / full] + overrides: [list or 'none'] Depth ceiling: [thorough / survey / maximal] Decision handling: [manual / autonomous / panel / default] Domain profile: [active profile name, or 'none'] Disabled features: [list, or 'none'] Custom profiles: [list with definitions per nocap §11.11, or 'none'] Health: [green / amber / red] Standing directives: 1. [directive text] (scope: global) 2. [directive text] (scope: messages remaining [N]) 3. [directive text] (scope: [task type, e.g. 'file operations']) (Field names above match the `prefs` command output in nocap §13.3 so the receiving session can map transfer values directly. Directive scope format supports the three forms defined in §11.6.1: global, message-count scoped, and task-type scoped. Use whichever apply; omit unused forms.) TRANSFER LIMITATIONS [What this transfer might be missing. If compaction has occurred in this conversation, state it. If context may have been lost, state what. If the user should verify anything before proceeding in the new chat, state what.] ``` --- ## Generation Rules 1. Pull from the actual conversation state, not from a general summary of the topic. The user wants to continue at a specific point, not get an overview. 2. KEY DECISIONS is the most important section. Decisions without reasoning will be re-evaluated by the new instance, possibly differently. Include the reasoning. If a decision rests on a theoretical or mechanical understanding that is not obvious (e.g., why a particular approach was chosen based on how a system works, not just what it does), state the understanding explicitly. The new instance has no access to the reasoning that produced the understanding and will not re-derive it from the conclusion alone. 3. DO NOT is the second most important section. Without it, the new instance will repeat dead ends. 4. Be concrete. "We decided to use approach X" is insufficient. "We decided to use approach X because Y and Z, rejecting approach W because of Q" is what the new instance needs. 5. If compaction or context loss has occurred in the current conversation, state this explicitly in TRANSFER LIMITATIONS. The user needs to know what might be missing so they can supplement. Detection heuristic: if the conversation exceeds approximately 20 messages, or if a compaction block is visible at the top of the conversation, assume context degradation has occurred and state it. If the conversation is short and no compaction is visible, state that the transfer was generated from apparently complete context. 6. CURRENT STATE should be specific enough that the user can say "continue from here" in the new chat and the instance knows what "here" means. 7. Do not include conversational history, emotional context, or tangential discussions. Only task-relevant state. **Boundary with Rule 1.** Rule 1 says pull actual state; this rule says exclude conversation form. They meet at deliberative decisions reached through multi-turn debate: the TECHNICAL INSIGHT that produced the decision is state (keep it in KEY DECISIONS reasoning); the BACK-AND-FORTH that surfaced the insight is conversational form (exclude). Apply this test: if a new instance could re-reach the same decision given the insight alone, the form is excluded. If the insight only makes sense in the context of an objection the user raised, include the objection as a stated constraint ("Approach X was rejected after user surfaced [constraint]; Approach Y adopted because [insight]") but do NOT narrate the exchange. State > narrative. When genuinely uncertain whether a piece of context is state or form, include it as state and mark it "verify with user before acting". 8. The block should be self-contained. The new instance should not need to search past conversations to understand it. If it would need additional context, state what in TRANSFER LIMITATIONS. 9. PROTOCOL STATE captures the user's protocol configuration so the new session can apply it as initial settings, bypassing the bootstrap selectors for those values. The receiving- session mechanism is defined in nocap §13.3 "Context transfer integration": when the first user message in a new session contains a PROTOCOL STATE block, bootstrap parses its fields, applies them as initial values, and skips the matching selectors. Field names in the transfer block MUST match the `prefs` format so the mapping is deterministic. Include PROTOCOL STATE only when the user has non-default settings. Defaults per §13.3: decision handling = "default", depth ceiling = "thorough", trace = "standard". Mode has no default (user always selects at bootstrap) so Mode is always substantive in the transfer. If every other field is at its default, omit the PROTOCOL STATE section and note "Protocol at defaults (Mode: [no cap / creative])" in its place. Scoped-directive expiry warning: message-count scoped directives include a remaining count at generation time. If the user continues the current session after generating the transfer block but before pasting into the new session, that count no longer reflects current state. State this in TRANSFER LIMITATIONS if the user indicates further work will happen pre-paste. --- ## Limitations This block is generated by the same system whose context may be degraded. The user should review the block before pasting, particularly KEY DECISIONS and CURRENT STATE, to verify they match the user's understanding of where things stand. If the user says the block is wrong or missing something, correct it. The user's knowledge of the state is authoritative.