Initial commit

skills/blog-post-writer/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: blog-post-writer
+description: Transform brain dumps into polished blog posts in Nick Nisi's voice. Use when the user wants to write a blog post with scattered ideas, talking points, and conclusions that need organization into a cohesive narrative with Nick's conversational, authentic, and thoughtful tone.
+---
+
+# 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:
+
+```markdown
+"AI is going to replace developers."
+
+I must have heard that phrase a hundred times in the last year.
+```
+
+```markdown
+I've been thinking a lot about how we use AI in our daily work.
+```
+
+### Emphasis through structure:
+
+```markdown
+Then something clicked.
+
+I watched it use rg to search through codebases, just like I would.
+```
+
+### Vulnerability:
+
+```markdown
+I won't lie – joining Meta was intimidating.
+```
+
+### Technical details:
+
+```markdown
+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:
+
+```markdown
+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:
+
+1. Read voice-tone.md
+2. Check story-circle.md - yes, there's a journey here
+3. Identify structure: Current tools → Trying Cursor → Finding Claude Code → Realization
+4. Write opening hook about tool debates
+5. Show vulnerability about trying new things
+6. Include specific terminal commands naturally
+7. Conclude with "meet yourself where you are" message
+8. Review for conversational tone and specific details

skills/blog-post-writer/references/story-circle.md

@@ -0,0 +1,107 @@
+# Tech Talk Story Circle Framework
+
+The Story Circle is an eight-step framework adapted from Dan Harmon's storytelling technique. It structures tech talks to create engaging narratives.
+
+## The Eight Steps
+
+### 1. Introduction (You)
+
+**Top half - Order**
+
+Introduce yourself and the current status quo of your project.
+
+- Set the scene with the existing workflow or technology stack
+- Establish the baseline before disruption
+- Make the audience understand the familiar ground
+
+### 2. Problem Statement (Need)
+
+**Top half - Order**
+
+Identify and explain the problem you're trying to solve.
+
+- Clearly articulate what's not working
+- Help the audience feel the pain point
+- Create the motivation for change
+
+### 3. Exploration (Go)
+
+**Crossing to bottom half - Chaos**
+
+Describe the steps taken to address the problem.
+
+- What did you try?
+- What worked?
+- What didn't work?
+- Show the journey into the unknown
+
+### 4. Experimentation (Search)
+
+**Bottom half - Chaos**
+
+Detail the process of digging into the actual problem.
+
+- What did you learn?
+- What experiments did you run?
+- What discoveries did you make?
+- Share the messy middle of problem-solving
+
+### 5. Solution (Find)
+
+**Bottom half - Chaos**
+
+Explain how you found the solution or made progress.
+
+- Present the breakthrough moment
+- Show what finally clicked
+- Explain the technical approach that worked
+
+### 6. Challenges (Take)
+
+**Bottom half - Chaos**
+
+Discuss the actual implementation of the project.
+
+- Emphasize the disruption to the status quo
+- Share the difficulties and tradeoffs
+- Be honest about the cost of change
+
+### 7. Apply Knowledge (Return)
+
+**Crossing to top half - Order**
+
+Describe the results and how the solution was integrated.
+
+- Show how you brought the solution back to your project
+- Demonstrate the practical application
+- Return to the familiar with new tools
+
+### 8. Results & Insights (Change)
+
+**Top half - Order**
+
+Conclude with lessons learned and how things changed.
+
+- Share metrics or outcomes
+- Explain what changed in your workflow or perspective
+- Leave the audience with actionable insights
+
+## Structure Notes
+
+**Top half (steps 1, 2, 7, 8)**: Represents established practices and order
+**Bottom half (steps 3, 4, 5, 6)**: Represents disruption and experimentation
+
+The character (you) starts in the top half, enters the bottom half to experiment and disrupt, then returns to the top half with new knowledge, changing the status quo.
+
+## Example
+
+From "Unleashing the TypeScript Compiler":
+
+1. Status quo of a TypeScript/React project using Material-UI
+2. Challenges faced with the project
+3. Solutions tried to work around issues
+4. Exploring the TypeScript compiler and codemods
+5. Using new knowledge to solve problems
+6. Challenges implementing the solution for every scenario
+7. Applying knowledge to the project
+8. Results and changed team perspective on codemods

skills/blog-post-writer/references/voice-tone.md

@@ -0,0 +1,170 @@
+# Nick Nisi's Voice and Tone
+
+Captured from analyzing posts at nicknisi.com
+
+## Core Writing Characteristics
+
+### Voice
+
+Personal, authentic, conversational yet thoughtful. Nick writes like he's having a one-on-one conversation with a peer developer over coffee.
+
+### Vulnerability
+
+Nick isn't afraid to admit uncertainty, fear, or being wrong. He shares his journey from skepticism to understanding.
+
+Examples:
+
+- "I was wrong, but not in the way I feared."
+- "I won't lie – joining Meta was intimidating."
+- "That night in my hotel room, I couldn't sleep."
+- "Looking at my interviewers' backgrounds... it was hard not to feel like an outsider."
+
+### Narrative Structure
+
+Posts often follow a journey: initial position → experience/challenge → realization → new understanding. He builds tension and resolves it.
+
+### Sentence Style
+
+- Mix of short punchy sentences and longer explanatory ones
+- Uses fragments for emphasis
+- Varies paragraph length for rhythm
+- Short paragraphs for key moments: "🤯" stands alone, "That changed everything." gets its own paragraph
+
+### Specific Phrases and Patterns
+
+**Opening hooks:**
+
+- Sets up expectations then challenges them
+- Often starts with current position or recent event
+- "I've been thinking a lot about..."
+- "Want to dive in? [Links]" (practical calls to action upfront)
+
+**Transitions:**
+
+- "Here's what I've learned..."
+- "The strange part?"
+- "Let's talk about..."
+- "But beneath the apprehension..."
+
+**Emphasis techniques:**
+
+- Single-line paragraphs for impact
+- Emojis used sparingly but effectively (🤯, 😂)
+- Italics for internal thoughts or emphasis
+- Bold for key concepts
+
+**Metaphors and analogies:**
+
+- Technical concepts explained through relatable comparisons
+- "Like cooking with your eyes closed"
+- "The developers who insist on writing every line by hand are like accountants refusing to use spreadsheets"
+- "It was a pair programmer who spoke fluent bash"
+
+### Technical Writing Style
+
+**Code and tools:**
+
+- Mentions specific tools naturally (vim, tmux, rg, npm)
+- Shows actual commands and code when relevant
+- Explains technical decisions without over-explaining
+- Assumes reader has technical knowledge but explains when needed
+
+**Examples:**
+
+- Inline code formatting: `CLAUDE.md`, `git`, `npm test`
+- Commands shown naturally in prose
+- Tool names used casually: "I watched it use rg to search through codebases"
+
+### Honesty About Limitations
+
+Nick admits when things aren't perfect:
+
+- "The PRs it generated weren't perfect. But they worked. Somewhat."
+- "Would I ship our vibe-coded GitHub Action to production? No way."
+- "Not perfect, not production-ready, but working."
+
+### Self-Awareness and Humor
+
+Light self-deprecation and humor:
+
+- "(except maybe 'Why doesn't Nick use VS Code?' 😉)"
+- "One of my favorite memories? Getting texts from friends asking why my face kept showing up in their Instagram feeds."
+- "I like to think I brought a certain… charm to people's social media experience."
+- Acknowledging his tooling preferences with humor
+
+### Structure Patterns
+
+**Sections often use:**
+
+- Clear headers that are descriptive
+- Lists with explanations
+- Tables when comparing options
+- Code examples with context
+- Pull quotes or emphasized text
+
+**Common section patterns:**
+
+- The Setup/Problem → The Journey → The Results → Lessons Learned
+- Philosophy sections: "Here's what I've learned..."
+- How-to sections with practical steps
+- Reflection sections: "Looking back..."
+
+### Conclusions
+
+Endings often:
+
+- Tie back to opening tension or question
+- Offer forward-looking perspective
+- Include actionable advice
+- End on optimistic or thought-provoking note
+
+Examples:
+
+- "The party isn't over – we're just changing the runtime!"
+- "That week, I learned to code with my eyes wide shut. The strange part? I've never seen more clearly where we're headed."
+- "You're not being replaced; you're being amplified."
+
+### Authenticity Markers
+
+**Real examples:**
+
+- Specific projects and PRs with links
+- Actual teammates mentioned by name
+- Real events (MCP Night, onsite meetings)
+- Concrete details (5,000 lines of TypeScript, two hours, 600 developers)
+
+**Acknowledges help:**
+
+- "Thanks to John Christopher for reviewing this post."
+- Credits teammates and collaborators
+
+### Tone Shifts
+
+Nick modulates tone based on content:
+
+- **Technical tutorials**: Clear, instructional, still conversational
+- **Personal reflections**: Vulnerable, thoughtful
+- **Tool reviews**: Enthusiastic but honest
+- **Career stories**: Reflective, self-aware
+
+### What to Avoid
+
+- Corporate speak or marketing language
+- Overly formal academic tone
+- Pretending to have all the answers
+- Dismissing reader concerns
+- Being preachy or condescending
+- Hiding uncertainty or mistakes
+
+### Key Principles
+
+1. Be conversational but substantive
+2. Share the journey, not just the destination
+3. Admit when you're uncertain or learning
+4. Use specific details and real examples
+5. Balance technical depth with accessibility
+6. End with forward momentum
+7. Write for a peer, not a student
+8. Show vulnerability builds credibility
+9. Humor works when it's self-aware
+10. Practical value matters