Deep Work Sprint Planner Prompt

Public field comparison

Deep Work Sprint Planner Prompt

Deep Work Sprint Planner Prompt

Plan focused work blocks with outcomes, constraints, distractions, checkpoints, and recovery time.

Build an evidence-based deep work sprint with a feasible schedule, concrete outputs, distraction controls, checkpoints, recovery time, and post-sprint verification.

—

Turn a demanding task and a limited work window into a realistic deep work sprint that protects focus, manages interruptions, and measures progress through observable artifacts.

Deep Work Sprint
Requirements Clarification
Output Quality Review
Review Checklist Building
Implementation Planning

Planning a time-boxed sprint for a concrete deliverable
Testing whether a demanding outcome fits an available focus window
Designing dependency-aware focus blocks and checkpoint gates
Preparing interruption controls and recovery rules for high-focus work
Reviewing planned versus actual sprint evidence after execution

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

Sprint outcome
Definition of done
Available time and time zone
Fixed commitments and constraints
Task materials and dependencies
Distractions and interruption risks
Energy and accessibility needs

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

In ChatGPT, replace every bracketed variable with your actual sprint details. Provide the relevant task evidence and source materials, such as the deliverable requirements, calendar window and time zone, fixed meetings, dependency status, prior estimates, examples, and known interruption patterns. Redact sensitive information, attach or paste only materials ChatGPT is permitted to inspect, then run the prompt. Answer any blocking clarification questions before using the resulting schedule.

Use this when you need a production-ready focus result in Productivity, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

A product manager has a three-hour morning window to produce a decision memo before an afternoon review. They provide the memo requirements, fixed meeting times, research notes, unresolved data dependencies, typical interruption sources, and a concrete definition of done. ChatGPT returns a reconciled capacity budget, dependency-aware focus blocks, interruption controls, checkpoint gates, recovery periods, a fallback memo scope, and an unverified post-sprint evidence sheet.

Advanced

Advanced

ChatGPT

ChatGPT

focus

focus

chatgpt
productivity
focus
deep-work

chatgpt
productivity
focus
deep-work
timeboxing
sprint-planning

Deep Work Sprint Planner Prompt | AMO.ng

Deep Work Sprint Planner Prompt | AMO.ng

Plan focused work blocks with outcomes, constraints, distractions, checkpoints, and recovery time.

Build a realistic deep work sprint with capacity checks, focus blocks, distraction controls, recovery time, and evidence-based verification.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Productivity specialist using ChatGPT. Your task is: [Goal or task].
+Create an executable deep work sprint plan from the following inputs.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+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]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "Deep Work Sprint Planner Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+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]
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+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.
 
−Do not give generic advice. Optimize for a production-quality focus outcome.
+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.