Deadline Prep Complete

A practical skill for preparing demo-ready presentations from your work — covering change log analysis, talking point generation, demo script creation, and structured presentation outlines from git history and session activity.

When to Use This Skill

Choose Deadline Prep Complete when you need to:

• Generate demo talking points from recent development work
• Create a structured presentation from git commit history
• Prepare for sprint demos or stakeholder presentations
• Summarize what was built, why, and how to present it
• Turn raw development activity into audience-ready narratives

Consider alternatives when:

• You need slide design (use a presentation design skill)
• You need meeting facilitation (use a meeting management skill)
• You need status reports (use an internal comms skill)

Quick Start

Copy
# Generate demo prep from git history
claude "Create demo talking points from the last 2 weeks of commits on the 'feature/auth-redesign' branch. Audience: product team and stakeholders."

Copy
# Demo Prep: Auth Redesign
**Sprint**: Dec 2-13, 2024
**Audience**: Product team, stakeholders
**Duration**: 15 minutes

## Demo Script

### 1. Opening (2 min)
"We redesigned the authentication flow to reduce login
friction and improve security. Here's what changed."

**Key metric**: Login success rate improved from 82% to 96%

### 2. New Login Flow (5 min)
**Show**: Navigate to login page
- Social login buttons (Google, GitHub) now prominent
- Email/password moved to secondary option
- "Remember me" enabled by default (30-day sessions)

**Talking point**: "We analyzed 10,000 login attempts and
found that 68% of users prefer social login. We made that
the primary path."

### 3. Session Management (3 min)
**Show**: Login → Dashboard → Settings → Active Sessions
- Users can see all active sessions
- One-click "Sign out everywhere" button
- Session list shows device, location, last active

**Talking point**: "This replaces the old 'change password
to log out everywhere' workaround."

### 4. Security Improvements (3 min)
**Show**: Developer tools → Network tab during login
- Tokens no longer stored in localStorage
- HttpOnly cookies with SameSite=Strict
- CSRF token on every form submission

**Talking point**: "These changes close 3 of the 5 security
findings from the October pentest."

### 5. Q&A (2 min)
**Prepared for likely questions**:
- "When does this roll out?" → Progressive rollout starting Dec 16
- "What about existing sessions?" → Migrated automatically
- "Mobile app impact?" → SDK update shipping same week

## Changes Summary (from git log)
| Area              | Commits | Key Changes                |
|------------------|---------|----------------------------|
| Auth flow        | 12      | Social login, session mgmt |
| Security         | 5       | Cookie auth, CSRF tokens   |
| UI/UX            | 8       | Login page redesign        |
| Tests            | 6       | E2E auth flow tests        |
| Docs             | 3       | API auth documentation     |

Core Concepts

Demo Prep Pipeline

Step	Input	Output
Gather Changes	Git log, change log CSV	Raw change list
Categorize	Change list	Grouped by feature/area
Prioritize	Grouped changes	Demo-worthy items ranked
Script	Priority items	Talking points + actions
Rehearse	Demo script	Timed walkthrough

Change Analysis

Copy
# Extract changes for demo prep
git log --oneline --since="2 weeks ago" --no-merges

# Group by area (using conventional commits)
git log --since="2 weeks ago" --format="%s" --no-merges \
  | grep -oP '^(feat|fix|refactor|perf|docs)\([^)]+\)' \
  | sort | uniq -c | sort -rn

# Files changed (shows scope of work)
git diff --stat HEAD~30 HEAD | tail -5

# Contributors (for acknowledgment)
git shortlog -sn --since="2 weeks ago"

Audience Adaptation

Copy
## Tailoring the Demo

### Technical Audience (Engineers)
- Show architecture diagrams and code changes
- Discuss tradeoffs and technical decisions
- Demo edge cases and error handling
- Include performance benchmarks

### Product Audience (PM, Design)
- Focus on user experience improvements
- Show before/after comparisons
- Reference user research/metrics
- Highlight what's visible to end users

### Executive Audience (Leadership)
- Lead with impact metrics (conversion, security)
- Keep to 3-5 key points
- Show the product, not the code
- End with timeline and next steps

Configuration

Parameter	Description	Example
time_range	Period of work to summarize	"2 weeks"
branch	Git branch to analyze	"feature/auth-redesign"
audience	Demo audience type	"product" / "executive"
duration	Target demo length in minutes	15
include_metrics	Add quantitative results	true

Best Practices

1. Lead with the outcome, not the process — "Login success rate improved from 82% to 96%" is more compelling than "We spent 2 weeks refactoring the auth module." Start with what changed for users or the business, then explain how you got there.

2. Prepare for the top 3 likely questions — After every demo, someone asks "When does this ship?" and "What about [edge case]?" Anticipate these questions and have answers ready. Prepared answers demonstrate confidence and thoroughness.

3. Show the product, not the code — Unless your audience is engineering peers, demo the running application. Click through the actual UI, show real (or realistic) data, and narrate the user experience. Code screenshots belong in tech talks, not stakeholder demos.

4. Time your demo and cut ruthlessly — A 15-minute slot means 12 minutes of content and 3 minutes for questions. Rehearse with a timer and cut anything that doesn't directly demonstrate value. Better to show 3 features well than 7 features rushed.

5. End with a clear next step, not "any questions?" — Close with "This ships to 10% of users on Monday. Full rollout by end of month." A clear next step signals confidence and gives stakeholders something concrete to track.

Common Issues

Demo breaks during live presentation — Always have a recorded fallback. Before the demo, screen-record a successful walkthrough. If the live demo fails, switch to the recording with "Let me show you the recording I prepared." Never debug live.

Too much detail for the audience — Engineers demo to stakeholders and explain database migrations. Stakeholders demo to engineers and skip technical context. Match your depth to your audience. Ask yourself: "Would this person care about this detail?"

Demo covers everything but highlights nothing — A demo that touches 15 features in 15 minutes leaves no impression. Pick 3 features that demonstrate the most value, demo them thoroughly, and mention the rest in a "we also shipped" summary slide.