Deadline Scope Tradeoff Brief

SKILL.md

---
name: Deadline Scope Tradeoff Brief
description: Create a one-page decision brief that clarifies what must ship by a deadline, what can be cut or simplified, and how to communicate the tradeoff.
version: "1.0.0"
type: prompt-flow
tags:
  - decision-framework
  - project-management
  - prioritization
  - deadline
  - scope
author: OpenClaw Skill Library
---

# Deadline Scope Tradeoff Brief

## Overview

Deadline Scope Tradeoff Brief helps a user make a clear, honest plan when time is limited and scope must change. It identifies the real success outcome, separates must-ship work from negotiable work, scores tradeoffs, names risks, drafts a stakeholder message, and recommends a practical action plan.

This is decision support only. It does not encourage deception, hiding risks, breaching contracts, or making commitments the user cannot keep.

## When to Use

Use this skill when the user needs to:

- Hit a deadline with too much remaining scope
- Decide what to cut, defer, simplify, or protect
- Prepare a stakeholder update about scope tradeoffs
- Rescue a project, launch, deliverable, proposal, event, or content plan
- Choose between quality, speed, completeness, and risk

**Trigger phrases:** "I cannot finish everything by the deadline", "What should I cut?", "Help me scope this down", "Make a deadline tradeoff brief", "I need to tell stakeholders about scope changes"

## Required Inputs

Ask for the minimum useful details:

- Deadline and whether it is fixed or flexible
- Current scope and expected deliverables
- Stakeholders and decision-makers
- Progress so far
- Non-negotiable outcomes
- Quality bar, risks, dependencies, and blockers
- Contractual, legal, compliance, safety, or trust constraints
- Available people, time, and budget
- Consequences of missing the deadline or reducing scope

If details are missing, use assumptions but label them clearly.

## Workflow

### Step 1 - Define Deadline, Scope, Stakeholders, and Progress

Summarize the current situation:

- Deadline date and time
- Whether the deadline is external, internal, contractual, public, or self-imposed
- Original scope
- Work completed, in progress, and not started
- Stakeholders affected
- Known blockers, dependencies, and constraints

### Step 2 - Clarify the Real Success Outcome

Identify what must be true for the effort to count as successful. Ask:

- What decision, launch, promise, or outcome does the deadline support?
- What user, customer, manager, audience, or team need must be met?
- What minimum proof of value or readiness is required?
- What would make the delivery unacceptable even if it is on time?

Convert this into one or two must-ship outcomes.

### Step 3 - Sort Scope Into Must, Should, Could, and Remove

Classify each scope item:

- Must: required for the real success outcome, safety, trust, contract, or core function
- Should: valuable but can be reduced if needed
- Could: nice-to-have or polish
- Remove: low-value, risky, duplicate, or no longer aligned

Be direct about false must-haves. If everything is marked must, challenge the classification.

### Step 4 - Score Items by Value, Risk, and Dependency

For each important item, score or label:

- Value: high, medium, low
- Risk if cut: high, medium, low
- Effort remaining: high, medium, low
- Dependencies: none, internal, external, blocked
- Reversibility: easy to add later or hard to recover

Use the scores to reveal cuts, deferrals, or simplifications.

### Step 5 - Identify Simplifications

For each should or could item, propose a simpler version:

- Reduce depth or coverage
- Ship manual process before automation
- Use a template or existing asset
- Narrow the audience or use case
- Replace custom work with a standard option
- Split into deadline version and later version
- Convert polish into a known follow-up

Keep simplifications honest and visible.

### Step 6 - Map the Tradeoffs and Quality Risks

Name the consequences of each option:

- What improves by cutting or simplifying
- What gets worse or delayed
- Quality, trust, operational, stakeholder, and user risks
- Mitigation steps
- What must be communicated before delivery

Do not hide risk to make the plan look better.

### Step 7 - Draft the Stakeholder Update

Write a concise, truthful message that includes:

- Current status
- Deadline reality
- Recommended scope change
- What will still be delivered
- What will be cut, deferred, or simplified
- Risks and mitigations
- Decision or approval needed
- Next checkpoint

Tone should be accountable, calm, and specific.

### Step 8 - Produce the Recommended Action Plan

Provide a one-page brief and immediate next steps:

- Recommended plan
- Items to protect
- Items to cut, defer, or simplify
- Owner and timing for next actions
- Decision needed from stakeholders
- Checkpoint schedule

## Deliverable Format

Return a one-page brief in this structure:

```markdown
# Deadline Scope Tradeoff Brief

## 1. Situation
- Deadline:
- Stakeholders:
- Current progress:
- Constraint summary:

## 2. Real Success Outcome
- Must-ship outcome 1:
- Must-ship outcome 2:

## 3. Scope Sort
- Must:
- Should:
- Could:
- Remove:

## 4. Tradeoff Options
| Option | What changes | Value protected | Risk introduced | Mitigation |
|---|---|---|---|---|

## 5. Recommended Plan
- Ship:
- Cut:
- Defer:
- Simplify:
- Quality safeguards:

## 6. Stakeholder Message
[Draft message]

## 7. Immediate Action Plan
- Next 24 hours:
- Next checkpoint:
- Decision needed:
```

If tables are unsuitable for the channel, use bullets instead.

## Example Prompts

- "We have a product launch in 2 weeks and 40 unfinished features. Help me make a scope tradeoff brief."
- "The client wants everything by Friday. Help me sort what must ship vs. what can wait."
- "Make a deadline tradeoff brief for a conference talk I haven't finished preparing."
- "Help me tell stakeholders we need to cut scope without sounding like we failed."

## Safety Boundaries

- This skill provides decision support, not legal, contractual, financial, compliance, or employment advice.
- Do not encourage deception, hiding material risks, falsifying status, blaming others unfairly, or breaching contracts.
- If contractual, legal, safety, or compliance obligations are involved, advise the user to verify obligations with an appropriate responsible person.
- Do not recommend cutting safety, accessibility, security, privacy, compliance, or trust-critical work without explicit escalation and risk review.
- Do not present a stakeholder message as sent or approved; it is a draft for review.

## Acceptance Criteria

1. The brief identifies the deadline, stakeholders, scope, and progress.
2. The real success outcome is defined separately from the original scope.
3. Scope is sorted into must, should, could, and remove.
4. Tradeoffs are scored or described using value, risk, effort, dependency, and reversibility.
5. Simplification options are provided.
6. Quality risks and mitigations are explicit.
7. A truthful stakeholder update is drafted.
8. A recommended action plan is included.
9. The skill remains prompt-only and requires no API, network access, credentials, or executable code.