Blog Post Creation Workflow
Purpose
Streamline the daily blog post creation process by automating research, drafting, and style review in a single command.
Usage Modes
Mode 1: Start from scratch with a topic
/blog-post "CPU Scheduling in Hypervisors"
/blog-post "Database Connection Pools" --category infra --tags db,performance,connections
This will:
- Run deep-dive research using
docs/deep_dive_prompt.md
- Save research to
_research/ directory
- Generate blog post draft following style guide
- Review against
blog-post-style-guide.md
- Create final file in
_posts/ with proper naming
Mode 2: From existing research document
/blog-post --from-research _research/physical-virtual-foundations/03-physical-virtual-foundations-CPU.md
/blog-post --from-research _research/programming/01-distributed-programming-IBLT.md --series "Distributed Programming"
This will:
- Read the research document
- Generate blog post draft following style guide
- Review against
blog-post-style-guide.md
- Create final file in
_posts/ with proper naming
Workflow Steps
Step 0: Setup & Context Gathering
ALWAYS start with:
- Create todos using TodoWrite - Track all workflow steps, mark in_progress/completed as you work
- Read 2-3 recent posts from
_posts/ to match current voice and patterns
- Check for series - If topic matches existing series (grep titles), use series format
- Sequential numbering - For research files:
ls _research/<category>/ | sort -n | tail -1 to get next number
- Validate research path (Mode 2) - Ensure file exists before proceeding
Step 1: Research Phase (Mode 1 only)
If starting from topic:
- Read
docs/deep_dive_prompt.md
- Use the prompt structure to conduct deep research on the topic
- Create comprehensive research document in
_research/ directory
- Organize under appropriate subdirectory (infra, programming, systems, etc.)
- Save as
_research/<category>/<number>-<topic-slug>.md
Quality gate - Research must have:
- All 8 sections from deep_dive_prompt (Mental Model, Failure Modes, Tradeoffs, Socratic Questions, Lifecycle, Experiments, Red Flags, Operator Truths)
- At least 5 concrete failure modes
- 10 Socratic questions (unanswered)
- Real examples, not hypotheticals
If from existing research:
- Read the provided research document path
- Validate it exists and has content (if not, show available files in
_research/)
- Skip to drafting phase
Step 2: Draft Generation
CRITICAL: Transform, don't copy!
- Blog = 30-40% of research length (800-1500 words max)
- NEVER copy entire research sections verbatim
- Extract 2-3 key insights, not everything
- Add first-person narrative that research lacks ("As I explored...", "I was surprised to find...")
- Pick 1-2 failure modes → inline examples with real commands
- Socratic questions → DO NOT include directly, use to shape narrative flow
- Operator truths → Final Thoughts section
Content Transformation:
- Extract key insights from research that match blog philosophy (personal learning, operational focus)
- Distill complexity - research is comprehensive, blog is focused and digestible
- Add personal voice - first-person, conversational, "I found myself learning..."
- Focus on "why it matters" - connect theory to practice for software engineers
- Include concrete examples - real commands, outputs, scenarios
Structure Requirements:
Front matter - Generate based on topic and user-provided options:
---
title: "<Series Name - Specific Topic>" or "<Standalone Topic>"
date: <today's date in YYYY-MM-DD HH:MM:SS -0500>
categories: <programming|infra|ai>
tags: [ <3-6 relevant tags> ]
---
- CRITICAL: Date must be today or earlier, NEVER a future date
- Ask user for series name if ambiguous
- Suggest category and tags based on content
Opening (1-2 sentences) - Personal context, direct and concise:
- Jump to what sparked interest
- No verbose setup
- Examples from existing posts show this pattern
Main sections with ## and ### headings:
- Start with concept definition
- Include "Why should software engineers care?" section
- Use question-based headers when appropriate
- Progress simple → complex
Examples and visuals:
- Real command outputs (not hypotheticals)
- ASCII diagrams for architecture
- Code blocks with language specifiers
- Citations required: All concrete numbers (latency, throughput, %, multipliers) MUST cite source (Intel docs, AWS specs, etc.) OR use qualitative ("significantly faster" instead of "2x")
Final Thoughts (optional but recommended):
- Synthesize learnings
- Connect to broader applications
- Pose implications
Voice Requirements (from style guide):
- First-person perspective ("I", "we")
- Conversational without sacrificing accuracy
- Avoid overloaded adjectives ("very", "highly", "incredibly", "remarkably")
- No AI-sounding intensifiers
- Trust technical content to speak for itself
- Use concrete details over vague praise
Quality gate - Draft must have:
- Word count 800-1500 (concise, not research republished)
- Opening 1-2 sentences max
- "Why should software engineers care?" section exists
- At least one concrete example or command output
- No future dates in front matter
- First-person voice throughout ("I", "we", "As I learned...")
Step 3: Style Review
Review the draft against .claude/blog-post-style-guide.md:
Check:
Provide:
- List of issues found (if any)
- Suggested fixes for each issue
- Revised sections for critical problems
- Overall assessment: "Ready to publish" or "Needs revision"
If issues found:
- Auto-fix minor issues: AI intensifiers, missing citations (convert to qualitative), formatting
- For critical issues (missing sections, wrong voice): Show before/after, apply fixes
- Re-run style review after fixes (max 2 iterations)
- Only ask user for major structural decisions
Step 4: File Creation
Filename format: YYYY-MM-DD-topic-slug.md
- Use today's date
- Convert topic to lowercase kebab-case
- Example:
2026-01-03-cpu-scheduling-hypervisors.md
Location: _posts/
Before saving:
- Check if file exists → Ask: "Overwrite, save as new (-v2), or cancel?"
- Validate filename format and date
Final output:
- Save the reviewed and polished draft to
_posts/<filename>
- Show summary: file path, word count, series (if applicable)
- Ask next step: "Preview locally? Commit to git? Review file? Done?"
User Interaction
Ask for clarification when:
- Category is ambiguous (suggest based on content)
- Tags are unclear (suggest 3-6 relevant tags)
- Series name is needed but not provided
- Topic is too broad (suggest narrowing)
- Research document path doesn't exist
Provide feedback:
- "Research phase complete - saved to
_research/..."
- "Draft generated - reviewing against style guide..."
- "Style review complete - found X issues"
- "Blog post created:
_posts/YYYY-MM-DD-topic.md"
Critical Rules
- Transform, don't republish - Blog is 30-40% of research length with personal narrative added
- Quality gates - Validate research completeness, draft word count, voice consistency
- Voice matching - Read recent posts before drafting, match established patterns
- Citations - All numbers cite sources OR use qualitative descriptions
- Auto-fix - Apply minor fixes automatically, iterate max 2 times
- Error handling - Validate paths, check file existence, ask before overwriting
- Todo tracking - Use TodoWrite from start, mark completed immediately after each step
Example Interactions
Example 1: From scratch
User: /blog-post "Memory Balloon Drivers"
Assistant: Starting research phase on "Memory Balloon Drivers"...
[Creates research document]
Research complete: _research/infra/04-memory-balloon-drivers.md
Generating blog post draft...
Style review complete - 2 minor issues found
Blog post created: _posts/2026-01-03-memory-balloon-drivers.md
Example 2: From existing research
User: /blog-post --from-research _research/infra/03-cpu-scheduling.md --series "Physical Virtual Foundations"
Assistant: Reading research document...
Generating blog post draft following "Physical Virtual Foundations" series pattern...
Style review complete - ready to publish
Blog post created: _posts/2026-01-03-physical-virtual-foundations-cpu-scheduling.md
1---2name: blog-post3description: Complete workflow for creating blog posts - from research to publication-ready draft. Handles research generation, draft creation, and style review. Use with "/blog-post <topic>" or "/blog-post --from-research <path>".4---5
6# Blog Post Creation Workflow
7
8## Purpose
9Streamline the daily blog post creation process by automating research, drafting, and style review in a single command.
10
11## Usage Modes
12
13### Mode 1: Start from scratch with a topic
14```
15/blog-post "CPU Scheduling in Hypervisors"
16/blog-post "Database Connection Pools" --category infra --tags db,performance,connections
17```
18
19This will:
201. Run deep-dive research using `docs/deep_dive_prompt.md`
212. Save research to `_research/` directory
223. Generate blog post draft following style guide
234. Review against `blog-post-style-guide.md`
245. Create final file in `_posts/` with proper naming
25
26### Mode 2: From existing research document
27```
28/blog-post --from-research _research/physical-virtual-foundations/03-physical-virtual-foundations-CPU.md
29/blog-post --from-research _research/programming/01-distributed-programming-IBLT.md --series "Distributed Programming"
30```
31
32This will:
331. Read the research document
342. Generate blog post draft following style guide
353. Review against `blog-post-style-guide.md`
364. Create final file in `_posts/` with proper naming
37
38## Workflow Steps
39
40### Step 0: Setup & Context Gathering
41
42**ALWAYS start with:**
431. **Create todos using TodoWrite** - Track all workflow steps, mark in_progress/completed as you work
442. **Read 2-3 recent posts** from `_posts/` to match current voice and patterns
453. **Check for series** - If topic matches existing series (grep titles), use series format
464. **Sequential numbering** - For research files: `ls _research/<category>/ | sort -n | tail -1` to get next number
475. **Validate research path** (Mode 2) - Ensure file exists before proceeding
48
49### Step 1: Research Phase (Mode 1 only)
50
51**If starting from topic:**
521. Read `docs/deep_dive_prompt.md`
532. Use the prompt structure to conduct deep research on the topic
543. Create comprehensive research document in `_research/` directory
554. Organize under appropriate subdirectory (infra, programming, systems, etc.)
565. Save as `_research/<category>/<number>-<topic-slug>.md`
57
58**Quality gate - Research must have:**
59- All 8 sections from deep_dive_prompt (Mental Model, Failure Modes, Tradeoffs, Socratic Questions, Lifecycle, Experiments, Red Flags, Operator Truths)
60- At least 5 concrete failure modes
61- 10 Socratic questions (unanswered)
62- Real examples, not hypotheticals
63
64**If from existing research:**
651. Read the provided research document path
662. Validate it exists and has content (if not, show available files in `_research/`)
673. Skip to drafting phase
68
69### Step 2: Draft Generation
70
71**CRITICAL: Transform, don't copy!**
72- Blog = 30-40% of research length (800-1500 words max)
73- NEVER copy entire research sections verbatim
74- Extract 2-3 key insights, not everything
75- Add first-person narrative that research lacks ("As I explored...", "I was surprised to find...")
76- Pick 1-2 failure modes → inline examples with real commands
77- Socratic questions → DO NOT include directly, use to shape narrative flow
78- Operator truths → Final Thoughts section
79
80**Content Transformation:**
81- **Extract key insights** from research that match blog philosophy (personal learning, operational focus)
82- **Distill complexity** - research is comprehensive, blog is focused and digestible
83- **Add personal voice** - first-person, conversational, "I found myself learning..."
84- **Focus on "why it matters"** - connect theory to practice for software engineers
85- **Include concrete examples** - real commands, outputs, scenarios
86
87**Structure Requirements:**
881. **Front matter** - Generate based on topic and user-provided options:
89 ```yaml
90 ---
91 title: "<Series Name - Specific Topic>" or "<Standalone Topic>"
92 date: <today's date in YYYY-MM-DD HH:MM:SS -0500>
93 categories: <programming|infra|ai>
94 tags: [ <3-6 relevant tags> ]
95 ---
96 ```
97 - CRITICAL: Date must be today or earlier, NEVER a future date
98 - Ask user for series name if ambiguous
99 - Suggest category and tags based on content
100
1012. **Opening (1-2 sentences)** - Personal context, direct and concise:
102 - Jump to what sparked interest
103 - No verbose setup
104 - Examples from existing posts show this pattern
105
1063. **Main sections with ## and ### headings**:
107 - Start with concept definition
108 - Include "Why should software engineers care?" section
109 - Use question-based headers when appropriate
110 - Progress simple → complex
111
1124. **Examples and visuals**:
113 - Real command outputs (not hypotheticals)
114 - ASCII diagrams for architecture
115 - Code blocks with language specifiers
116 - **Citations required**: All concrete numbers (latency, throughput, %, multipliers) MUST cite source (Intel docs, AWS specs, etc.) OR use qualitative ("significantly faster" instead of "2x")
117
1185. **Final Thoughts (optional but recommended)**:
119 - Synthesize learnings
120 - Connect to broader applications
121 - Pose implications
122
123**Voice Requirements (from style guide):**
124- First-person perspective ("I", "we")
125- Conversational without sacrificing accuracy
126- Avoid overloaded adjectives ("very", "highly", "incredibly", "remarkably")
127- No AI-sounding intensifiers
128- Trust technical content to speak for itself
129- Use concrete details over vague praise
130
131**Quality gate - Draft must have:**
132- Word count 800-1500 (concise, not research republished)
133- Opening 1-2 sentences max
134- "Why should software engineers care?" section exists
135- At least one concrete example or command output
136- No future dates in front matter
137- First-person voice throughout ("I", "we", "As I learned...")
138
139### Step 3: Style Review
140
141Review the draft against `.claude/blog-post-style-guide.md`:
142
143**Check:**
144- [ ] Front matter complete and properly formatted
145- [ ] Date is not in the future
146- [ ] Opening is concise (1-2 sentences)
147- [ ] Main concept defined early
148- [ ] "Why should software engineers care?" addressed
149- [ ] Technical terms defined on first use
150- [ ] Examples use real commands/outputs
151- [ ] Visuals are clean and readable
152- [ ] Actionable takeaways provided
153- [ ] Tone is conversational and first-person
154- [ ] No overloaded adjectives or intensifiers
155- [ ] Concrete numbers cite sources OR use qualitative descriptions
156- [ ] Logical flow from simple to complex
157
158**Provide:**
1591. List of issues found (if any)
1602. Suggested fixes for each issue
1613. Revised sections for critical problems
1624. Overall assessment: "Ready to publish" or "Needs revision"
163
164**If issues found:**
165- Auto-fix minor issues: AI intensifiers, missing citations (convert to qualitative), formatting
166- For critical issues (missing sections, wrong voice): Show before/after, apply fixes
167- Re-run style review after fixes (max 2 iterations)
168- Only ask user for major structural decisions
169
170### Step 4: File Creation
171
172**Filename format:** `YYYY-MM-DD-topic-slug.md`
173- Use today's date
174- Convert topic to lowercase kebab-case
175- Example: `2026-01-03-cpu-scheduling-hypervisors.md`
176
177**Location:** `_posts/`
178
179**Before saving:**
180- Check if file exists → Ask: "Overwrite, save as new (-v2), or cancel?"
181- Validate filename format and date
182
183**Final output:**
1841. Save the reviewed and polished draft to `_posts/<filename>`
1852. Show summary: file path, word count, series (if applicable)
1863. Ask next step: "Preview locally? Commit to git? Review file? Done?"
187
188## User Interaction
189
190**Ask for clarification when:**
191- Category is ambiguous (suggest based on content)
192- Tags are unclear (suggest 3-6 relevant tags)
193- Series name is needed but not provided
194- Topic is too broad (suggest narrowing)
195- Research document path doesn't exist
196
197**Provide feedback:**
198- "Research phase complete - saved to `_research/...`"
199- "Draft generated - reviewing against style guide..."
200- "Style review complete - found X issues"
201- "Blog post created: `_posts/YYYY-MM-DD-topic.md`"
202
203## Critical Rules
204
2051. **Transform, don't republish** - Blog is 30-40% of research length with personal narrative added
2062. **Quality gates** - Validate research completeness, draft word count, voice consistency
2073. **Voice matching** - Read recent posts before drafting, match established patterns
2084. **Citations** - All numbers cite sources OR use qualitative descriptions
2095. **Auto-fix** - Apply minor fixes automatically, iterate max 2 times
2106. **Error handling** - Validate paths, check file existence, ask before overwriting
2117. **Todo tracking** - Use TodoWrite from start, mark completed immediately after each step
212
213## Example Interactions
214
215### Example 1: From scratch
216```
217User: /blog-post "Memory Balloon Drivers"
218
219Assistant: Starting research phase on "Memory Balloon Drivers"...
220[Creates research document]
221Research complete: _research/infra/04-memory-balloon-drivers.md
222
223Generating blog post draft...
224Style review complete - 2 minor issues found
225Blog post created: _posts/2026-01-03-memory-balloon-drivers.md
226```
227
228### Example 2: From existing research
229```
230User: /blog-post --from-research _research/infra/03-cpu-scheduling.md --series "Physical Virtual Foundations"
231
232Assistant: Reading research document...
233Generating blog post draft following "Physical Virtual Foundations" series pattern...
234Style review complete - ready to publish
235Blog post created: _posts/2026-01-03-physical-virtual-foundations-cpu-scheduling.md
236```