/blog Command - How I Reduced Blog Writing Time by 83% - Yunjeong Luna Lee

TL;DR

After 2-3 weeks post-development, you lose context and can’t write blog posts. The /blog command analyzes Git + work logs + Features to auto-generate drafts and inserts screenshot recommendations as HTML comments. 83% reduction in blog writing time (4 hours → 1 hour), 4x increase in publishing frequency.

Why Don’t Developers Write Blogs?

Common reasons developers don’t blog:

“It’s tedious”
“I don’t know what to write about”
“Taking screenshots is annoying”
“I wanted to write later, but can’t remember what I did”

Especially 2-3 weeks after completing a feature:

UI changed, can’t capture the same screens
Can’t recall why I implemented it this way
Git commit logs alone can’t reconstruct the story

To solve this, I created the /blog command that auto-generates blog drafts immediately after finishing work.

Similar Approaches

1. eesel.ai - `/new-post` Command

/new-post "My Awesome Blog Post"
→ Creates 2025-11-01-my-awesome-blog-post.md
→ Auto-inserts Jekyll frontmatter

Auto-generates filename from today’s date + slugified title.

2. ezablocki.com - Cursor Slash Commands

Stores reusable AI prompts in the project, version-controlled via Git, shared across the team.

3. n8n Workflow - AI Blog Automation

News collection → Relevance filtering → AI expansion → Image generation → WordPress publishing

Generates 10 blog posts per day fully automatically.

How CheckUS’s `/blog` is Different

While the above focus on “blog writing automation”, /blog focuses on “preserving development context + draft generation”.

✅ Automatic Git history analysis
✅ Technical decision extraction
✅ Screenshot recommendations inserted directly in draft (key differentiator)
✅ Integration with Features tracking system

/blog Command 6-Step Workflow

Step 1: Context Detection from Conversation

When running /blog in the same conversation, no need to re-parse Git log.

User: F033 done! Run /blog

AI (checks conversation context):
- Worked on F033 in this conversation ✅
- Feature ID: F033
- Title: /blog command - AI-based blog automation
→ "Should I write a blog post about F033?"

Benefits:

No Git log parsing (saves tokens)
Instant Feature identification
No mixing with other features

For new conversations, extracts F0XX pattern from Git log.

Step 1.5: Research Existing Content & Competition Analysis

Before writing, search existing Korean/English posts:

Avoid duplicate content
Choose high-traffic target (Korean vs Global)
Find differentiation points
Learn natural writing style

WebSearch query examples:
- "Features tracking system" site:velog.io
- "feature tracking system" site:dev.to

Analysis result:

- Korean posts: 5 found (avg 5K views)
- English posts: 50 found (avg 2K views)
→ "Korean target recommended (lower competition, higher views)"

Step 2: Read Features Documentation (Top Priority)

What is the Features folder? A system that tracks all work in docs/features/F001-xxx/ format. Each feature has a README.md documenting tasks, technical decisions, and problems solved. For details, see the Features tracking system post.

Information source priority:

Features/README.md (highest)
daily_work_summary (supplementary)
Git diff (code examples)

# 1. Check INDEX.md for Feature
checkus-docs/features/INDEX.md

# 2. Read the Feature's README.md
checkus-docs/features/F033/README.md

Extract from Features/README.md:

frontmatter (title, labels, elapsed_hours)
“✅ Completed Tasks” → main content
“💡 Technical Decisions” → why this approach
“🐛 Problems Solved” → Before/After

Why Features first?

Already structured context (background → problem → solution → result)
Reuse AI-processed content
No mixing with other features

Step 3: Reference daily_work_summary (Supplementary)

What is daily_work_summary? A daily log file documenting work. While Features tracks “what was done”, daily_work_summary captures “why this approach was chosen” and “what trial-and-error occurred” - the decision-making context.

Supplement details not in Features:

Trial and error (why B instead of A?)
Decision rationale
Issues discovered

# Read only recent 1-2 days (save tokens)
checkus-docs/daily_work_summary/2025-11-01.md

Step 4: Check Git (For Code Examples)

# Check "🔗 Related Commits" section in README.md
git show [commit-hash]

Extract code examples:

Core code changes only
Before/After comparison
Snippets to insert in blog

Step 5: Auto-Generate Blog Draft

# Generated file structure
checkus-docs/features/F004-feature-tracking-system/
├── README.md           # Technical docs
├── blog.md            # Blog draft (auto-generated)
└── images/            # Screenshot storage

blog.md structure:

# [Title]

## Background
Why this feature was needed

## Problem Definition
What problem was solved

## Solution
Specific implementation

## Results
What improved

## Lessons Learned
Technical insights

Step 6: Insert Screenshot Recommendations as HTML Comments ⭐

Key Innovation: Screenshot recommendations inserted as HTML comments inside blog.md, not separate file

## Implementation

<!-- 📸 Recommended Screenshot #1: Folder Structure
Filename: 01-folder-structure.png
Content: Full features/ tree in VS Code Explorer
How to capture:
1. Right-click features/ in VS Code
2. Select "Expand All"
3. Scroll to show F001-F031
4. Capture full Explorer sidebar
-->

The Features tracking system has the following folder structure...

Why HTML Comments?

Method	Pros	Cons
Separate file	Separate management	Disconnected from draft, management burden
Frontmatter	Metadata	Hard to express per-section location
HTML Comments	✅ Visible when editing ✅ Hidden when rendered ✅ Accurate placement	None

Before/After Comparison

Before: Manual Blog Writing

Feature development complete
Git commit
(3 weeks pass)
"Should write a blog post"
Look at Git log: "What did I do?"
Re-read code to understand
UI changed, can't capture screenshots
Give up or write poorly

Time: 3-4 hours (or infinity)

After: /blog Command (6-Step Workflow)

1. Feature development complete
2. Git commit
3. Run /blog (30 seconds)
   → Step 1: Auto-detect F033 from conversation context
   → Step 1.5: Web search for existing content
   → Step 2: Read Features/README.md
   → Step 3: Supplement with daily_log
   → Step 4: Git (code examples)
   → Step 5: Generate blog.md
   → Step 6: Insert screenshot comments
4. Capture screenshots based on comments (10 min)
5. (3 weeks pass)
6. Open blog.md
7. Insert images following comments
8. Polish and publish

Time: 30 min - 1 hour

Improvement:

⏱️ 83% time reduction (4 hours → 1 hour)
🎯 100% context preservation
📸 Screenshot timing problem solved
📝 Blog publishing rate 4x increase

Integration with Other Slash Commands

/finish → /blog Pipeline

# 1. Work completion process
/finish
→ Update Features system (status: DONE)
→ Write work log in daily_work_summary/
→ Sync requirement.md
→ Git commit

# 2. Generate blog draft
/blog
→ Reference all content created above
→ Auto-generate blog.md (with screenshot comments)

Synergy:

/finish for data collection
/blog for content generation
Seamless connection, no duplicate work

Team Collaboration Aspect

# Global command (personal)
~/.claude/commands/blog.md

# Project command (team shared)
my-project/.claude/commands/blog.md

Team sharing benefits:

Consistent blog style
- All team members write with same structure
- Maintain company tech blog tone & manner

Command improvements apply to entire team

# A improves /blog command
git commit -m "feat: add performance metrics to /blog"
git push

# B pulls
git pull
→ B immediately uses improved /blog

Reduced onboarding time
- New hire: “How do I write blogs?”
- Senior: “Just type /blog”

Technical Implementation

Command File Structure

# ~/.claude/commands/blog.md

You are an AI that analyzes recent work to write blog drafts.

## Step 1: Detect Work from Conversation Context
...

## Step 2: Read Features Documentation
...

## Step 5: Insert Screenshot Recommendations
**Important**: Insert screenshot recommendations as HTML comments inside blog.md.

### Comment Format
<!-- 📸 [Priority] Screenshot #number: [Description]
Filename: XX-description.png
Content: [What to capture]
How to capture:
1. [Step]
-->

SlashCommand operation:

User types /blog
Claude Code reads blog.md file
Expands content as prompt
AI executes steps 1-6
Saves result to features/FXXX/blog.md

HTML Comment Parsing (For Future Automation)

// Extract screenshot comments from blog.md
function extractScreenshotComments(blogContent) {
  const regex = /<!-- 📸.*?-->/gs;
  const matches = blogContent.match(regex);

  return matches.map(comment => {
    const numberMatch = comment.match(/#(\d+)/);
    const filenameMatch = comment.match(/Filename: (.+)/);
    const contentMatch = comment.match(/Content: (.+)/);

    return {
      number: numberMatch[1],
      filename: filenameMatch[1],
      description: contentMatch[1],
      fullComment: comment
    };
  });
}

// Usage example
const screenshots = extractScreenshotComments(fs.readFileSync('blog.md', 'utf-8'));
console.log(`${screenshots.length} screenshots needed`);

Potential uses:

/blog-check command: Check for missing images
Auto image optimization
Pre-publish checklist

Real-World Results

Case Study: F004 Features System Blog

Estimated manual writing time:

Git log analysis: 30 min
Context recall: 1 hour
Screenshot planning: 30 min
Draft writing: 2 hours
Total: 4 hours

Actual time with /blog:

/blog execution: 30 sec
AI generation wait: 2 min
Screenshot capture: 15 min
Draft review & editing: 30 min
Total: 47 min 30 sec

Savings: 83% time saved

Blog Publishing Frequency Change

Period	Method	Blog Count	Avg Quality
2024 Q1-Q2	Manual	3	⭐⭐⭐
2024 Q3-Q4	`/blog`	12	⭐⭐⭐⭐

Improvement factors:

Reduced psychological barrier: “At least I have a draft”
Context preservation: “Why I did this” is clear
Screenshot timing: Can capture right after development

Lessons Learned

1. Blogs Written “Later” Never Get Written

Developers are always busy. “I’ll organize and write later” - but that “later” never comes.

Solution: Auto-generate draft immediately after work completion.

2. Screenshots are “Now or Never”

UI keeps changing. After just 2 weeks, can’t reproduce the same screen.

Solution: Insert screenshot recommendations as comments in draft → encourage immediate capture.

3. Information Should Be Close to Where It’s Used

Storing screenshot recommendations in a separate file:

Hard to find
Hard to understand context
Management burden

Putting them as HTML comments in blog.md:

Visible when editing
Clear context
Managed together via git

4. AI is Stronger at “Context Preservation” than “Eliminating Repetitive Work”

Other blog automation focuses on reducing “repetitive writing tasks”. But the real problem was “I don’t know what to write about”.

/blog:

Git analysis extracts what was done
Work log extracts why it was done
Features extract how it was done

→ AI reconstructs the story to generate blog draft.

5. Slash Commands are “Workflow Standardization” Tools

Committing /blog to Git means:

Entire team writes blogs the same way
Command improvements apply to everyone
Simplified new hire onboarding

Team-level productivity improvement.

Future Improvements

1. Auto Image Capture

/blog --auto-capture
→ Auto-capture screenshots with Puppeteer
→ Save to images/ folder

Challenge: Hard to automate complex interactions (hover, click, scroll).

2. Image Optimization Pipeline

convert *.png -resize 1200x -quality 85 optimized/

3. Pre-Publish Checklist

/blog-check
→ Check if images in comments exist
→ Output list of missing images
→ Check file size (warn if >1MB)

4. Multi-Language Support

/blog --lang=en
→ Generate English blog draft
→ Same screenshot comments (keep Korean descriptions)

5. Blog Platform Integration

/blog-publish --platform=medium
→ Auto-publish via Medium API
→ Upload images and convert links

Conclusion

The /blog command isn’t just a “blog auto-generator”:

Development Context Preservation System - Git + work logs + Features integration
Screenshot Timing Problem Solved - HTML comments encourage immediate capture
Team Collaboration Tool - Share via Git, maintain consistent style
AI-Based Workflow Automation - “Creative context reconstruction”, not just repetitive tasks

Result: 83% reduction in blog writing time, 4x increase in publishing frequency.

Developers don’t write blogs not because “it’s tedious” but because “they lose context”.

/blog automatically preserves that context.

/blog Command - How I Reduced Blog Writing Time by 83%