majiayu000 Blog Topic Research
When to Use
Trigger when:
- User mentions wanting to write about a topic
- User asks "should I write about X?"
- Before running blog-scaffolding
- User wants to validate an idea
Purpose
Prevent writing generic content by:
- Checking what already exists on the topic
- Identifying what's been covered well by others
- Finding gaps and unique angles
- Validating the topic is worth YOUR time
Research Process
1. Internal Search First
Check if you've already written about this:
- Search existing blog posts in
content/en/blog/ - Search drafts in
content/en/drafts/ - Look for related tags
Ask: "Have you already covered this? If so, is this a follow-up or rehash?"
2. External Landscape
Use WebSearch to understand what exists:
- What's the common narrative on this topic?
- What angles are already covered well?
- What gaps exist in existing coverage?
- Who has authority on this topic already?
Focus: Not comprehensive research - just enough to understand the landscape.
3. Find YOUR Angle
This is the critical part. Ask:
- What's YOUR specific experience with this?
- What problem did YOU encounter that others might not discuss?
- What did YOU learn that contradicts common advice?
- What unique implementation/approach do YOU have?
Red flags:
- "I think this would be interesting" (but no personal experience)
- "People should know about X" (but you haven't used it)
- "This is a trending topic" (but you have nothing unique to add)
Green flags:
- "I built X and discovered Y"
- "Everyone says X but I found Y"
- "I tried the common solution and it failed because Z"
- "Here's my implementation that handles edge case W"
4. Unique Value Assessment
Compare what exists vs. what you can offer:
Proceed if:
- You have hands-on experience others don't discuss
- You found problems with common solutions
- You built something that solves a gap
- Your perspective adds genuine value
Don't proceed if:
- You'd just be summarizing others' work
- You haven't actually tried it yourself
- The topic is well-covered and you have nothing new
- You're writing it because you "should" not because you experienced it
Response Format
Present findings conversationally:
I searched for existing content on [topic]. Here's what I found:
**Already well-covered:**
- [Common angle 1 with examples]
- [Common angle 2 with examples]
**Potential unique angles from your experience:**
- [Your specific implementation/discovery]
- [Edge case you encountered]
- [Contrarian finding]
**Recommendation:**
[Proceed with unique angle] OR [This might be too generic - consider X instead]
What's your specific experience with this that would add value?
Integration with Other Skills
Before blog-scaffolding:
- Topic research validates the idea
- Scaffolding uses the unique angle to structure the post
During scaffolding conversation:
- Reference the unique angle identified
- Push for personal experience on that specific angle
- Avoid generic content based on research gaps
Anti-patterns
Don't:
- Write the post for them based on research
- Accept "I think people should know" without experience
- Do comprehensive research that belongs in the post itself
- Approve topics just because they're trending
Do:
- Surface what already exists
- Push for personal, specific experience
- Validate uniqueness before investing in writing
- Suggest pivoting if the angle isn't unique enough
Examples
Good Validation
Topic: "Building a custom deployment script for X"
Research findings:
- Generic tutorials exist (common approach Y)
- Manual configuration patterns covered
- No automation examples found
User's unique angle:
- Built automated solution that handles edge case Z
- Implements pattern nobody else discusses
- Integrates with tool W in a novel way
- Has battle scars from production failures
Recommendation: ✅ Proceed - implementation details and lessons learned are unique
Bad Validation
Topic: "Getting started with popular tool X"
Research findings:
- Official docs cover this extensively
- Multiple tutorials exist
- Getting started guides are thorough
User's unique angle:
- "I think people should know about X"
- "It's a cool tool"
- (No specific experience or problems encountered)
Recommendation: ❌ Don't proceed - this would be generic. Unless you have specific daily workflow experience, unique integration challenges, or discovered non-obvious problems.
Key Principle
The blog exists to share experience, not summarize knowledge.
If you haven't lived it, struggled with it, built it, or learned something surprising about it - it's not ready to be a post yet.