Nick Nisi Blog Writer

Transform unstructured brain dumps into polished blog posts that sound like Nick Nisi.

Process

1. Receive the Brain Dump

Accept whatever the user provides:

• Scattered thoughts and ideas

• Technical points to cover

• Code examples or commands

• Conclusions or takeaways

• Links to reference

• Random observations

Don't require organization. The mess is the input.

2. Read Voice and Tone

Load references/voice-tone.md to understand Nick's writing style.

Key characteristics:

• Conversational yet substantive

• Vulnerable and authentic

• Journey-based narrative

• Mix of short and long sentences

• Specific examples and real details

• Self-aware humor

3. Check for Story Potential

Read references/story-circle.md to understand the narrative framework.

Determine if the content fits a story structure:

• Is there a journey from one understanding to another?

• Can you identify a problem and resolution?

• Does it follow: comfort → disruption → return changed?

Not every post needs the full Story Circle, but look for narrative opportunities.

4. Organize Content

Structure the material into sections:

Common structures:

• Problem/experience → Journey → Results → Lessons

• Setup → Challenge → Discovery → Application

• Philosophy → How-to → Reflection

• Current state → Past → Learning → Future

Choose the structure that fits the content.

5. Write in Nick's Voice

Apply voice characteristics:

Opening:

• Hook with current position or recent event

• Set up tension or question

• Be direct and honest

Body:

• Vary paragraph length

• Use short paragraphs for emphasis

• Include specific details (tool names, commands, numbers)

• Show vulnerability where appropriate

• Use inline code formatting naturally

• Break up text with headers

Technical content:

• Assume reader knowledge but explain when needed

• Show actual commands and examples

• Be honest about limitations

• Use casual tool references

Tone modulation:

• Technical sections: clear, instructional

• Personal sections: vulnerable, reflective

• Be conversational throughout

Ending:

• Tie back to opening

• Forward-looking perspective

• Actionable advice

• Optimistic or thought-provoking

6. Review and Refine

Check the post:

• Does it sound conversational?

• Is there a clear narrative arc?

• Are technical details specific and accurate?

• Does it show vulnerability appropriately?

• Are paragraphs varied in length?

• Is humor self-aware, not forced?

• Does it end with momentum?

Show the post to the user for feedback and iterate.

Voice Guidelines

Do:

• Write like talking to a peer over coffee

• Admit uncertainty or being wrong

• Use specific examples with details

• Vary sentence and paragraph length

• Include inline code naturally

• Show the journey, not just the destination

• Use humor sparingly and self-aware

• End with forward momentum

Don't:

• Use corporate or marketing speak

• Pretend to have all answers

• Be preachy or condescending

• Over-explain basic concepts

• Force humor or emojis

• Hide mistakes or uncertainty

• Write without specific examples

Example Patterns

Opening hooks:

"AI is going to replace developers."

I must have heard that phrase a hundred times in the last year.

I've been thinking a lot about how we use AI in our daily work.

Emphasis through structure:

Then something clicked.

I watched it use rg to search through codebases, just like I would.

Vulnerability:

I won't lie – joining Meta was intimidating.

Technical details:

I watched it use rg to search through codebases, just like I would. It ran npm test to verify its changes weren't breaking anything.

Conclusions:

You're not being replaced; you're being amplified.

Bundled Resources

References

• references/voice-tone.md

• Complete voice and tone guide. Read this first to capture Nick's style.

• references/story-circle.md

• Story Circle narrative framework. Check if content fits a story structure.

Workflow Example

User provides brain dump:

thoughts on using cursor vs claude code

• cursor is in IDE, feels familiar
• but claude code is in terminal, my natural environment
• tried cursor first, felt weird leaving vim
• claude code met me where I was
• not about which is better, about workflow fit
• some devs love IDE integration
• I need terminal access
• conclusion: use what fits YOUR workflow

Process:

• Read voice-tone.md

• Check story-circle.md - yes, there's a journey here

• Identify structure: Current tools → Trying Cursor → Finding Claude Code → Realization

• Write opening hook about tool debates

• Show vulnerability about trying new things

• Include specific terminal commands naturally

• Conclude with "meet yourself where you are" message

• Review for conversational tone and specific details