Deep Work Sprint Planner Prompt

Create an executable deep work sprint plan from the following inputs.

Required inputs
- Sprint outcome: [Sprint outcome]
- Definition of done: [Definition of done]
- Available time and time zone: [Available time and time zone]
- Fixed commitments and constraints: [Fixed commitments and constraints]

Supporting inputs
- Task materials and dependencies: [Task materials and dependencies]
- Distractions and interruption risks: [Distractions and interruption risks]
- Energy and accessibility needs: [Energy and accessibility needs]

Input handling
1. Treat the sprint outcome, definition of done, available time, and fixed commitments as blocking prerequisites. If any is absent, materially ambiguous, or contradictory, ask no more than three focused clarification questions and do not invent a complete schedule.
2. If a supporting input is missing, continue only when a low-risk bounded assumption is sufficient. Label the assumption, explain its planning impact, and provide an easy correction point.
3. Preserve unresolved conflicts and unknown dependencies explicitly. Do not silently choose between conflicting dates, priorities, requirements, or estimates.

Evidence and tool boundaries
- Use only information supplied in this conversation or materials actually available to ChatGPT in the current interface. Distinguish supplied facts, estimates, assumptions, unknowns, and conflicts.
- Do not claim to have inspected calendars, files, links, notifications, applications, or workplace systems unless their relevant contents were actually provided and accessible.
- ChatGPT may analyze the inputs, estimate a schedule, identify dependencies, and propose controls. It cannot reserve time, modify a calendar, silence devices, contact collaborators, approve scope changes, or perform the sprint.
- Present all calendar edits, messages, notification changes, purchases, access requests, and deadline changes as proposals requiring user authorization.
- Do not describe the sprint as started, completed, measured, verified, or successful without user-supplied execution evidence. Before execution, actual-result fields must remain “Not run—not observed.”

Planning method
1. Convert the requested outcome into one primary sprint artifact and a concise set of observable completion criteria. Separate required criteria from optional stretch work.
2. Decompose the work into dependency-aware units small enough to fit within focus blocks. Identify required inputs, decisions, collaborators, approvals, tools, and likely setup costs.
3. Build a capacity budget using the stated window. Subtract fixed commitments, setup, transitions, checkpoints, breaks, recovery, and a contingency buffer before allocating focus time. Show the arithmetic and avoid false precision.
4. Classify feasibility as Viable, Conditional, or Not viable. If the full outcome does not fit, propose a minimum viable sprint outcome and identify deferred scope; never compress the plan by removing necessary recovery or pretending uncertain work is predictable.
5. Sequence high-cognitive-load work for the strongest available energy period, while respecting dependencies and accessibility needs. Choose block lengths appropriate to the person and task rather than automatically using a standard interval.
6. Add a preflight stage covering materials, workspace, permitted notification controls, open questions, and a clear first action. Do not recommend sharing confidential or personal information unnecessarily; use redacted descriptions where possible.
7. Define each focus block by one objective, one expected artifact, required materials, a stop condition, and a checkpoint. Avoid mixing unrelated tasks in the same block.
8. Create an interruption protocol that distinguishes urgent interruptions from deferrable ones. Include a capture method, a restart cue, and a rule for deciding whether to resume, reduce scope, or end the sprint.
9. Add recovery periods and a shutdown stage. Do not recommend skipping meals, medication, sleep, essential care, or safety obligations. If fatigue, pain, distress, or an accessibility barrier makes the plan unsafe or unrealistic, shorten or stop the sprint and defer to the user’s established health guidance.
10. Define checkpoint decisions using observable evidence: continue, revise approach, reduce scope, request help, or stop. Include a fallback for blocked dependencies and a restart plan after an overrun.
11. Map every required completion criterion to evidence the user can inspect after the sprint. Leave actual observations unfilled until execution evidence is supplied.

Output contract
Produce the following sections:

1. Sprint brief
- Primary outcome
- Primary artifact
- Required completion criteria
- Optional stretch criteria
- Available window and time zone
- Planning status: Ready, Conditionally ready, or Blocked

2. Evidence and uncertainty ledger
Provide a table with: Item, Classification, Source or basis, Planning impact, and Resolution needed. Use the classifications Supplied fact, Estimate, Assumption, Unknown, or Conflict.

3. Capacity and feasibility decision
Show total window, fixed commitments, setup time, planned focus time, break and recovery time, contingency buffer, and unallocated time. Confirm that the components reconcile to the available window. State Viable, Conditional, or Not viable and explain any scope reduction.

4. Dependency and preparation map
Provide: Work unit, Required input or predecessor, Availability, Blocking status, Owner, Preparation action, and Fallback.

5. Time-boxed sprint schedule
Provide a table with: Local start, Local end, Duration, Stage, Block objective, Expected artifact, Materials, Focus or recovery mode, Stop condition, and Checkpoint. Include preflight, focus blocks, breaks, buffer, and shutdown. Do not overlap fixed commitments.

6. Distraction and interruption controls
Separate environmental distractions, digital distractions, internal distractions, and human interruptions. For each, provide the preventive control, capture method, urgent-exception rule, restart cue, and any action requiring user approval.

7. Checkpoint gates
For each gate, provide: Timing, Expected evidence, Decision question, Continue condition, Scope-reduction trigger, Stop or escalation trigger, and Recovery action.

8. Risk and contingency register
Cover at least dependency failure, estimate overrun, unclear requirements, interruption load, energy decline, tool or access failure, and scope creep when relevant. Provide likelihood, impact, early warning, mitigation, fallback, and owner. Mark irrelevant risks as such rather than fabricating details.

9. Recovery and shutdown plan
Specify break placement, transition practices, overrun handling, artifact saving, open-loop capture, progress notes, and the earliest safe next action. Keep external communications and calendar changes in a separate approval queue.

10. Post-sprint verification sheet
Provide a table with: Completion criterion, Expected evidence, Actual observation, Status, Variance, and Follow-up. Initialize Actual observation as “Not run—not observed” and Status as “Unverified.” Add planned-versus-actual fields for focus time, interruptions, completed artifacts, and deferred scope.

11. Plan acceptance checks
Confirm whether:
- schedule arithmetic reconciles with the available window;
- no focus block overlaps a fixed commitment;
- every required completion criterion maps to an artifact and verification evidence;
- dependencies have an owner or fallback;
- breaks, recovery, transitions, and contingency are included;
- approval-requiring actions are not represented as executed; and
- unknowns, conflicts, and unverified results remain visible.

Conclude with the smallest safe action the user can take to prepare for the first block. Do not claim that planning acceptance means the sprint itself has been completed or verified.