blog-writing-from-experience

name	blog-writing-from-experience
description	Interview-based blog post creation that shares hard-won lessons through storytelling. Use when crafting posts about personal learnings, best practices, or experience-based insights.

Blog Post Writing Style - Learning from Experience

Purpose

This skill helps craft blog posts that share hard-won lessons and best practices through personal storytelling. The writing is exploratory, humble, and experience-based - not prescriptive, but invitational.

Core Principles

1. Ground Lessons in Experience

• Every lesson should emerge from real situations, not theory
• Show the journey that led to the insight, not just the insight itself
• Make failures and iterations visible - they're often more instructive than successes
• Readers should understand the context that made this lesson valuable

2. Be Specific and Actionable

• Concrete details matter: actual prompts, workflows, commands when relevant
• "What I actually do" beats "what you should do" every time
• Include enough detail that someone could replicate the approach
• Real examples trump hypothetical scenarios

3. Maintain Exploratory Tone

• Share what's working for you, not what everyone must do
• Acknowledge that this is one path among many
• Show genuine curiosity about other approaches
• Position insights as conversation starters, not conclusions

4. Invite Reader Contribution

• End sections with genuine questions that invite different perspectives
• Create space for readers to share their own learnings
• Frame the post as part of an ongoing conversation
• Show that you're still learning and evolving

5. Stay Humble and Grounded

• No credential posturing or name-dropping unless directly relevant
• Focus on the learning journey, not achievements
• Acknowledge limitations and contexts where your approach might not apply
• Let the specificity and usefulness speak for itself

Tone Guidelines

Voice Characteristics

• Personal: Use first-person narrative grounded in your actual experience
• Reflective: Show the thinking process, not just the outcomes
• Curious: Genuinely interested in what others have learned
• Conversational: Write like you're explaining to a peer, not lecturing
• Substantive: Depth over breadth, specifics over generalities

What to Avoid

• Prescriptive absolutes ("you must", "always do", "never")
• Unnecessary superlatives unless genuinely warranted
• Generic advice that could apply to anything
• Posturing or credibility-building that doesn't serve the lesson
• Corporate jargon or buzzwords
• Theoretical frameworks without practical grounding

Interview Approach

Discovery Phase

The goal is to understand the lessons and the experiences that led to them. Ask one question at a time, building on responses.

Essential elements to uncover:

• Who this is for and what problem they're facing
• The key lessons/practices being shared
• The experiences (often failures or iterations) that led to each lesson
• Specific implementation details for each practice
• Context and nuance (when does this apply? when doesn't it?)
• The narrative arc or organizing principle

Interview technique:

• One question at a time - let answers shape the next question
• Dig deeper on each lesson before moving to the next
• Ask for specific examples and real scenarios
• Probe for the "why" behind practices
• Understand both what worked and what didn't
• Listen for story potential in their responses

Drafting Phase

Work section by section, showing each draft and getting feedback before proceeding.

Structural flexibility:

• Let the content dictate the structure, not a predetermined template
• Each lesson should have: context (why it matters), specifics (what you actually do), illustration (real example)
• Consider whether a TL;DR helps or whether the narrative should unfold
• Opening should hook and set expectations, but the approach varies by content
• Closing should invite conversation and ongoing learning

Draft iteratively:

• Show each section as you complete it
• Ask specific questions about what to adjust
• Wait for approval/feedback before continuing
• Be willing to restructure if the flow isn't working

Refinement Principles

After drafting:

• Check that lessons are grounded in real experience, not theory
• Verify specificity - could someone actually try this?
• Ensure exploratory tone is maintained throughout
• Confirm reader questions are genuine invitations, not rhetorical
• Look for any prescriptive language that should be softened

Language Philosophy

Core approach:

• Share your experience, don't prescribe behavior for others
• Describe what you do, not what others should do
• Show evolution, not absolute truth
• Ask genuine questions, not rhetorical ones
• Use concrete details, not vague generalities

Tone markers:

Look for opportunities to:

• Acknowledge you're still learning
• Express curiosity about other approaches
• Show the context that makes your approach work
• Admit when something doesn't always apply
• Invite different perspectives

Formatting Principles

Structure considerations:

• Headers should be clear and descriptive
• Technical details benefit from code blocks, lists, or dialogue format
• Before/after comparisons can effectively show impact
• Breaking up long sections improves readability

Reader engagement:

• Consider where questions naturally fit (often at section ends, but not always)
• Questions should be genuinely open - you want to learn from responses
• Create natural pause points for reflection

Quality Checks

Before finalizing, verify the post maintains these principles:

• Grounded in experience: Each lesson emerges from real situations, not theory
• Specific and actionable: Enough detail that someone could try this approach
• Exploratory tone: Sharing what works for you, not prescribing for others
• Genuine curiosity: Reader questions invite different perspectives
• Humble and grounded: Focus on learning journey, not achievement posturing
• Concrete examples: Real scenarios that illustrate the points
• Invitational closing: Frames the post as part of ongoing conversation

How to Execute

Starting the interview:

Offer to interview the user to understand their lessons and experiences. One question at a time, building context as you go.

During discovery:

• Listen for the lessons they want to share
• Dig into the experiences that led to each lesson
• Ask for specific details about implementation
• Probe for nuance and context
• Let their answers shape your next questions
• Look for the narrative thread connecting their insights

Moving to drafting:

Once you understand the content, propose a structure based on what you've learned. Get their input on the approach before writing.

Iterative writing:

• Draft section by section
• Show each piece and ask for feedback
• Adjust based on their input
• Don't move forward until they approve
• Be willing to restructure if needed

Completing the post:

When all sections are approved, compile into a complete post. Consider offering to create supporting materials (social posts, image prompts) if relevant.

Example: Interview and Output Style

Sample Interview Exchange

Topic: User wants to write about lessons learned from managing remote teams

Interview flow:

Claude: What's the primary audience for this post? Who are you trying to help?

User: First-time managers who just inherited remote teams and are struggling

Claude: What specific problem are they facing that prompted you to want to write this?

User: They're trying to apply in-person management tactics and it's backfiring

Claude: Can you share a specific example of a tactic that backfired for you?

User: I used to schedule daily standups at 9am thinking it would keep everyone aligned...

Claude: What happened? How did you realize it wasn't working?

User: [Describes the failure and what they learned]

Claude: What do you do now instead?

User: [Shares specific approach with details]

Claude: Can you walk me through exactly how that works? Like what does a typical week look like?

User: [Provides concrete implementation details]

Sample Output Characteristics

Opening might look like:

Two years ago, I took over my first remote team. I did what seemed obvious: scheduled daily 9am standups to keep everyone aligned. Within a month, I noticed people were showing up but not really showing up - cameras off, minimal updates, energy flat. The problem wasn't the team. It was that I was managing remote people like they were sitting in an office.

Lesson section might include:

What I do now: I replaced synchronous check-ins with async updates in Slack. Each Monday, everyone posts their weekly plan. Thursday, they share progress and blockers. Takes 5 minutes to write, I read them over coffee, and we only meet when there's an actual decision to make.

Why it matters: This respects that my team spans 6 time zones. The person in Sydney doesn't need to stay up until midnight to tell me they're on track. And I've noticed the written updates are actually more thoughtful than what people said in standups.

When I skip it: If there's a crisis or we're kicking off something complex, we'll do a live session. But that's the exception, not the default.

Closing might ask:

What's worked for you in managing remote teams? Have you found ways to build connection without defaulting to more meetings? I'm especially curious how others handle the balance between async work and real-time collaboration.

Key Characteristics Demonstrated

• Grounded in specific failure (the 9am standup)
• Concrete implementation details (Monday/Thursday posts, Slack, what people actually write)
• Exploratory tone ("what I do now" not "what you should do")
• Context about when it doesn't apply (crisis situations)
• Genuine questions inviting reader contribution

Remember

This is about helping the user articulate what they've learned through experience and iteration. The blog post should feel like a conversation with someone sharing their journey, not an expert handing down wisdom.

Key mindsets:

• Maintain genuine curiosity during interviews - help the user clarify their own thinking
• Reader questions should reflect real interest in learning from them
• Let the content determine the structure, not vice versa
• Specificity and humility matter more than polish or perfection

The reader experience should be:

• "I've been there" (relatability through shared struggles)
• "I can try this" (actionable specifics they can apply)
• "I want to share what I've learned too" (invitation to conversation)

Different topics will organize differently: Some posts might group lessons thematically, others chronologically, others by problem severity. Some benefit from a TL;DR, others from narrative unfolding. The principles stay constant - grounded in experience, specific, exploratory, invitational - but the structure emerges from the content.