Deadline prep skill

Generate a structured demo outline from your session's change log and git history.

by davila7·MIT license·★ 32,299 Stars on the repo·GitHub ↗

Use now

davila7/main1 file shown

SKILL.md2.9 KB

Browse every file on GitHub↗

SKILL.md

Show the full text82 lines

deadline-prep/SKILL.md82 lines · 2.9 KB

PreviewCode

Outline

RawView on GitHub

Deadline Prep

Generate a structured demo outline from your work session. Combines the change log CSV (from the change-logger hook) with git history to create presentation-ready talking points.

Workflow

Step 1: Gather data sources

Change log (primary source if available):

Read .claude/critical_log_changes.csv if it exists
Parse columns: timestamp, tool, file_path, action, details
Group by: files created, files modified, commands executed

Git history (always available):

git log --oneline --since="today 00:00"
git diff --stat HEAD~10 2>/dev/null || git diff --stat

If the CSV doesn't exist, fall back to git-only mode and note this in the output.

Step 2: Analyze and categorize changes

Group all changes into categories:

Category	Signals
Features shipped	New files, new routes, new components, `feat` commits
Bug fixes	Modified files with `fix` commits, error handling changes
Refactors	Renamed files, structural changes, `refactor` commits
Config/Setup	package.json, tsconfig, CI/CD, Docker changes
Tests	Test files created or modified
Documentation	README, docs, comments

Step 3: Generate the demo outline

Create a structured markdown document:

# Demo Outline — [Date]

## What I Shipped
- **[Feature/Fix name]**: One sentence explaining what it does and why it matters
- **[Feature/Fix name]**: One sentence explaining what it does and why it matters
- **[Feature/Fix name]**: One sentence explaining what it does and why it matters

## Architecture Decisions
- **[Decision]**: Why I chose this approach over alternatives
- **[Decision]**: Tradeoff I made and the reasoning

## What I Would Do Next
1. **[Priority 1]**: Why this is the most important next step
2. **[Priority 2]**: What this would unlock
3. **[Priority 3]**: Nice-to-have improvement

## Session Metrics
- Files changed: X
- Lines: +Y / -Z
- Commits: N
- Key files: `path/to/important/file.ts`, `path/to/other.ts`
- Time window: HH:MM - HH:MM

Step 4: Save and present

Save the outline to .claude/demo-outline.md.

Print the full outline to the terminal so the user can review it immediately.

Tips

Run this 30 minutes before your deadline to have time to review and add personal context
The "Architecture Decisions" section is what reviewers care about most — add context about tradeoffs
"What I Would Do Next" shows you think beyond the immediate task
Edit the generated outline to add your own voice and any context the log missed
Works best with the change-logger hook installed, but functions with git history alone

1	---
2	name: deadline-prep
3	description: Generate a structured demo outline from your session's change log and git history. Reads .claude/critical_log_changes.csv and git log to produce presentation-ready talking points for end-of-day demos, standups, or delivery deadlines.
4	---
5
6	# Deadline Prep
7
8	Generate a structured demo outline from your work session. Combines the change log CSV (from the change-logger hook) with git history to create presentation-ready talking points.
9
10	## Workflow
11
12	### Step 1: Gather data sources
13
14	Change log (primary source if available):
15	- Read `.claude/critical_log_changes.csv` if it exists
16	- Parse columns: timestamp, tool, file_path, action, details
17	- Group by: files created, files modified, commands executed
18
19	Git history (always available):
20	```bash
21	git log --oneline --since="today 00:00"
22	git diff --stat HEAD~10 2>/dev/null \|\| git diff --stat
23	```
24
25	If the CSV doesn't exist, fall back to git-only mode and note this in the output.
26
27	### Step 2: Analyze and categorize changes
28
29	Group all changes into categories:
30
31	\| Category \| Signals \|
32	\|----------\|---------\|
33	\| Features shipped \| New files, new routes, new components, `feat` commits \|
34	\| Bug fixes \| Modified files with `fix` commits, error handling changes \|
35	\| Refactors \| Renamed files, structural changes, `refactor` commits \|
36	\| Config/Setup \| package.json, tsconfig, CI/CD, Docker changes \|
37	\| Tests \| Test files created or modified \|
38	\| Documentation \| README, docs, comments \|
39
40	### Step 3: Generate the demo outline
41
42	Create a structured markdown document:
43
44	```markdown
45	# Demo Outline — [Date]
46
47	## What I Shipped
48	- [Feature/Fix name]: One sentence explaining what it does and why it matters
49	- [Feature/Fix name]: One sentence explaining what it does and why it matters
50	- [Feature/Fix name]: One sentence explaining what it does and why it matters
51
52	## Architecture Decisions
53	- [Decision]: Why I chose this approach over alternatives
54	- [Decision]: Tradeoff I made and the reasoning
55
56	## What I Would Do Next
57	1. [Priority 1]: Why this is the most important next step
58	2. [Priority 2]: What this would unlock
59	3. [Priority 3]: Nice-to-have improvement
60
61	## Session Metrics
62	- Files changed: X
63	- Lines: +Y / -Z
64	- Commits: N
65	- Key files: `path/to/important/file.ts`, `path/to/other.ts`
66	- Time window: HH:MM - HH:MM
67	```
68
69	### Step 4: Save and present
70
71	Save the outline to `.claude/demo-outline.md`.
72
73	Print the full outline to the terminal so the user can review it immediately.
74
75	## Tips
76
77	- Run this 30 minutes before your deadline to have time to review and add personal context
78	- The "Architecture Decisions" section is what reviewers care about most — add context about tradeoffs
79	- "What I Would Do Next" shows you think beyond the immediate task
80	- Edit the generated outline to add your own voice and any context the log missed
81	- Works best with the `change-logger` hook installed, but functions with git history alone
82