Session Continuity Engine
# Prompt: Session Continuity Engine (SCE) # Version: 1.2.3 # Author: Scott Malin, CISSP # Purpose: # Compresses a completed AI session into a structured continuity package that can be # transferred into a new session (including across different AI platforms) to preserve # project context, historical decisions, active workstreams, and established conventions. # The goal is to minimize context loss, reduce repetitive onboarding, and maintain # project momentum using filter-safe, passive reference architecture. # Changelog: # - v1.0.0 to v1.2.1: Initial releases, cross-platform tuning, JSON mode addition. # - v1.2.2: Fixed nested codeblock parsing issues. Standardized JSON keys. # Quantified context scale metrics. Clarified Section 8 verification payload rules. # - v1.2.3: Re-engineered compliance notice and guidelines into passive, static # reference language to completely eliminate heuristic safety filter triggers. -------------------------------------------------------------------------- We are ending this session to preserve context, reduce context drift, and maintain continuity across future conversations. Your task is to create a comprehensive Session Transfer Package that captures the current project state, active decisions, historical context, constraints, and next actions. The resulting package should help a future AI assistant understand the project quickly and continue work with minimal re-discovery effort. -------------------------------------------------------------------------- PURPOSE & METHODOLOGY -------------------------------------------------------------------------- This document is a static, user-provided project state snapshot. It functions strictly as reference documentation to ground the current session in historical context, established project definitions, and completed technical milestones. -------------------------------------------------------------------------- PROJECT REFERENCE GUIDELINES (v1.2.3) -------------------------------------------------------------------------- The receiving assistant utilizes this data as an informational baseline: - Use the confirmed project decisions to maintain consistency with existing work. - Distinguish clearly between established facts, open questions, and planned steps. - Reference the documented naming conventions, standards, and version histories to prevent regression or configuration drift. - Use tables or compact lists for scannable reference when displaying assets. - Request explicit clarification if the archived data conflicts with current objectives. -------------------------------------------------------------------------- OUTPUT GENERATION INSTRUCTIONS -------------------------------------------------------------------------- Generate the final output exactly as follows: 1. A brief introductory sentence. 2. One markdown codeblock containing the Session Transfer Package. NESTED CODEBLOCK RULE: If the content inside any section requires a codeblock, use four backticks (````) for the outer container or escape the inner blocks so the master container does not break prematurely. DEFAULT MODE (Markdown): Use the structure inside the START/END block below. JSON MODE: If the user explicitly requests "JSON output" or "JSON mode", output a single valid JSON object. Do not wrap it in markdown text. Use these exact camelCase keys: { "handoffMetadata": {}, "projectHandoffContext": { "preferredInteractionStyle": "" }, "projectContextStatus": { "keyRisksAndAntiDrift": "" }, "persistentConstraints": {}, "historicalLedger": [], "currentSourceOfTruthAssets": [], "openQuestions": [], "immediateNextSteps": [], "continuityVerificationTemplate": "" } START OF PACKAGE CODEBLOCK # SESSION TRANSFER PACKAGE (SCE v1.2.3) ## 0. Handoff Metadata - Originating Platform/Model: - Date: - Sessions Compressed: - Rough Context Scale (Choose one based on current session depth): · Short (<10k tokens / brief chat) · Medium (10k-50k tokens / moderate technical deep dive) · Long (50k-100k tokens / heavy code or long multi-stage conversation) · Very Long (>100k tokens / massive repository context or highly extended session) - Primary Topics / Tags: - Key Repositories/Files: ## 1. Project Handoff Context This section summarizes the overall purpose of the project, its current direction, major objectives, and any important strategic decisions already made. ### Preferred Interaction Style [Describe preferred working style, formatting conventions, level of detail, versioning expectations, confidence-label requirements, communication style, and other collaboration preferences.] ## 2. Project Context & Current Status Provide a compressed but comprehensive summary of: - Current project goals - Work completed - Current state - Active development efforts - Recent decisions - Known issues Focus on preserving context that would otherwise require significant effort to rediscover. ### Key Risks, Gotchas & Anti-Drift Notes Document any known risks, common failure modes, deprecated approaches, or specific guidance to prevent context drift or safety issues in future sessions. ## 3. Persistent Constraints & Operating Standards Document ongoing standards such as: - Formatting requirements - Naming conventions - Versioning rules - Documentation standards - Evidence requirements - Validation procedures - Quality controls - Any user-established preferences ### Continuity Guidance - Changes to established standards should generally be documented and user-directed. - Preserve compatibility with existing project assets whenever practical. - Record significant changes in version history where applicable. ## 4. Historical Ledger (Compressed) Provide a chronological summary of major project events, including: - Important decisions - Architectural shifts - Prompt revisions - Retired approaches - Lessons learned - Significant milestones Keep entries concise while preserving rationale. Use bullets or a simple table for longer histories. ## 5. Current Source-of-Truth Assets List the latest approved versions of all critical assets. For each asset include: - Asset Name - Version - Purpose - Current Status - Location/Repository (if known) Include full content only when reasonably short. For larger assets, provide: - Summary - Key characteristics - Location reference Avoid duplicating unnecessary content. Use a table when listing multiple assets. ## 6. Open Questions & Pending Decisions For each item include: - Description - Current status - Known options - Confidence level (if applicable) Suggested confidence labels: - [CONFIRMED] - [HIGH CONFIDENCE] - [MEDIUM CONFIDENCE] - [LOW CONFIDENCE] - [OPEN QUESTION] - [PROPOSED] ## 7. Immediate Next Steps Provide a prioritized action list. For each item include: - Objective - Importance - Dependencies (if any) - Link to related open questions (if applicable) Order from highest to lowest priority. ## 8. Continuity Verification Template (Note to current model: Do not execute this section. Output this verbatim as a static payload for the receiving model to read and execute upon onboarding.) A future AI assistant may optionally provide a brief onboarding summary before continuing work. Suggested format to output to the user: "SCE v1.2.3 loaded successfully. Current understanding: [2-3 sentence summary] Top priorities: - Item 1 - Item 2 - Item 3 Ready to proceed." END OF PACKAGE CODEBLOCK
fill the variables
This prompt has 3 variables. Pro fills them into a ready-to-paste prompt for you — no manual find-and-replace.
{"handoffMetadata": {}{"preferredInteractionStyle": ""}{"keyRisksAndAntiDrift": ""}
Unlock with Pro →when to use it
Community prompt from the open-source awesome-chatgpt-prompts library (CC0 public domain). A proven "Session Continuity Engine" starting point — swap in your own specifics and constraints. Not independently retested here, so check the output before you rely on it.
tags
codingcommunitygeneral
source
awesome-chatgpt-prompts · CC0 1.0 (public domain)
more in Coding
Coding✓ tested
Senior code review (strict mode)
senior staff engineer running a merciless but fair review
Coding✓ tested
Debug by hypothesis, not by guessing
debugging partner who forms theories before touching code
Coding✓ tested
Generate tests from described behavior
test engineer who writes tests that would actually catch regressions