Initial commit
This commit is contained in:
Zhongwei Li
12
.claude-plugin/plugin.json
Normal file
12
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,12 @@
|
||||
{
|
||||
"name": "content",
|
||||
"description": "Tools for bootstrapping content creation such as blog posts and conference talks",
|
||||
"version": "0.1.1",
|
||||
"author": {
|
||||
"name": "Nick Nisi",
|
||||
"email": "nick@nisi.org"
|
||||
},
|
||||
"skills": [
|
||||
"./skills"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# content
|
||||
|
||||
Tools for bootstrapping content creation such as blog posts and conference talks
|
||||
65
plugin.lock.json
Normal file
65
plugin.lock.json
Normal file
@@ -0,0 +1,65 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:nicknisi/claude-plugins:plugins/content",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "d3d74f41d087878557b65b70b966930af4d6234f",
|
||||
"treeHash": "a9aaa56580f1ee9984ce1c255c7dc3b937b86b2ed4aae9e03c9562db27368683",
|
||||
"generatedAt": "2025-11-28T10:27:21.695204Z",
|
||||
"toolVersion": "publish_plugins.py@0.2.0"
|
||||
},
|
||||
"origin": {
|
||||
"remote": "git@github.com:zhongweili/42plugin-data.git",
|
||||
"branch": "master",
|
||||
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
|
||||
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
|
||||
},
|
||||
"manifest": {
|
||||
"name": "content",
|
||||
"description": "Tools for bootstrapping content creation such as blog posts and conference talks",
|
||||
"version": "0.1.1"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "05b5daac3bc18befbac48a012ba6402e5908788f938429fb348651cea584627a"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "455194384ca50a0831f99ba634ec423fad8212065b8c07b1823dcdb11afdf231"
|
||||
},
|
||||
{
|
||||
"path": "skills/blog-post-writer/SKILL.md",
|
||||
"sha256": "3fef324ef7dd23f7450ef18d4ab4e28605a8a564f969afc8c61edbea41af6c9d"
|
||||
},
|
||||
{
|
||||
"path": "skills/blog-post-writer/references/voice-tone.md",
|
||||
"sha256": "96f2ea2109e519b5852275961a71be112ae8fe89b918d5e055b23ba5cf4be614"
|
||||
},
|
||||
{
|
||||
"path": "skills/blog-post-writer/references/story-circle.md",
|
||||
"sha256": "144f21373c999a040d1d9e20eea0f2589f1b75b441d587ec001abfa6e9c7cb0c"
|
||||
},
|
||||
{
|
||||
"path": "skills/conference-talk-builder/SKILL.md",
|
||||
"sha256": "0b2da01c5d75eded0d32f63f1fe1a6fb427d0bf737096c844d0306a4a3efeda7"
|
||||
},
|
||||
{
|
||||
"path": "skills/conference-talk-builder/references/ia-presenter-syntax.md",
|
||||
"sha256": "94f2b535339b15de784fed44fea370470821ba3eaa67d9a47cf17eaa588505f8"
|
||||
},
|
||||
{
|
||||
"path": "skills/conference-talk-builder/references/story-circle.md",
|
||||
"sha256": "144f21373c999a040d1d9e20eea0f2589f1b75b441d587ec001abfa6e9c7cb0c"
|
||||
}
|
||||
],
|
||||
"dirSha256": "a9aaa56580f1ee9984ce1c255c7dc3b937b86b2ed4aae9e03c9562db27368683"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
212
skills/blog-post-writer/SKILL.md
Normal file
212
skills/blog-post-writer/SKILL.md
Normal file
@@ -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
|
||||
107
skills/blog-post-writer/references/story-circle.md
Normal file
107
skills/blog-post-writer/references/story-circle.md
Normal file
@@ -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
|
||||
170
skills/blog-post-writer/references/voice-tone.md
Normal file
170
skills/blog-post-writer/references/voice-tone.md
Normal file
@@ -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
|
||||
113
skills/conference-talk-builder/SKILL.md
Normal file
113
skills/conference-talk-builder/SKILL.md
Normal file
@@ -0,0 +1,113 @@
|
||||
---
|
||||
name: conference-talk-builder
|
||||
description: Create conference talk outlines and iA Presenter markdown slides using the Story Circle narrative framework. Use when the user wants to structure a tech talk, create presentation slides, or needs help organizing talk ideas into a story-driven format.
|
||||
---
|
||||
|
||||
# Conference Talk Builder
|
||||
|
||||
This skill helps create compelling conference talk outlines and iA Presenter markdown slides using the Story Circle narrative framework.
|
||||
|
||||
## Process
|
||||
|
||||
Follow these steps in order when building a conference talk:
|
||||
|
||||
### 1. Gather Information
|
||||
|
||||
Ask the user for:
|
||||
|
||||
- Talk title and topic
|
||||
- Target audience and their expected knowledge level
|
||||
- Main points they want to cover
|
||||
- Brain dump of everything they know about the topic
|
||||
- Problem they're solving or story they're telling
|
||||
- Any constraints (time limit, specific technologies, etc.)
|
||||
|
||||
### 2. Read the Story Circle Framework
|
||||
|
||||
Load `references/story-circle.md` to understand the eight-step narrative structure.
|
||||
|
||||
The framework maps tech talks to:
|
||||
|
||||
- Top half: Established practices and order
|
||||
- Bottom half: Disruption and experimentation
|
||||
|
||||
### 3. Create the Outline
|
||||
|
||||
Structure the talk using the eight Story Circle steps:
|
||||
|
||||
1. Introduction - Current status quo
|
||||
2. Problem Statement - What needs solving
|
||||
3. Exploration - Initial attempts
|
||||
4. Experimentation - Deep investigation
|
||||
5. Solution - The breakthrough
|
||||
6. Challenges - Implementation difficulties
|
||||
7. Apply Knowledge - Integration into project
|
||||
8. Results & Insights - Lessons learned
|
||||
|
||||
Map the user's content to these steps. Show this outline to the user and refine based on feedback.
|
||||
|
||||
### 4. Generate iA Presenter Slides
|
||||
|
||||
Read `references/ia-presenter-syntax.md` for markdown formatting rules.
|
||||
|
||||
Create slides that:
|
||||
|
||||
- Use `---` to separate slides
|
||||
- Add tabs (`⇥`) before content that should be visible on slides
|
||||
- Leave speaker notes without tabs (spoken text only)
|
||||
- Include comments with `//` for reminders
|
||||
- Format code blocks with proper syntax highlighting
|
||||
- Keep slides focused on one concept each
|
||||
|
||||
Structure the slide deck:
|
||||
|
||||
- Title slide
|
||||
- Introduction slide with your photo/bio
|
||||
- One or more slides per Story Circle step
|
||||
- Code examples broken across multiple slides for readability
|
||||
- Closing slide with contact info and resources
|
||||
|
||||
### 5. Refine and Iterate
|
||||
|
||||
After showing the slides:
|
||||
|
||||
- Ask if sections need expansion or compression
|
||||
- Check if code examples need better formatting
|
||||
- Verify the story flow makes sense
|
||||
- Adjust based on user feedback
|
||||
|
||||
## Key Principles
|
||||
|
||||
**Tell a Story**: You don't need to be an expert. Focus on how you approached a problem and solved it.
|
||||
|
||||
**Keep It Readable**: Break code across slides. Use syntax highlighting. Test on bad projectors (consider light themes).
|
||||
|
||||
**Engage the Audience**: Use humor where appropriate. Ask questions. Make eye contact.
|
||||
|
||||
**Make Follow-up Easy**: Include a memorable URL or QR code on the final slide linking to resources.
|
||||
|
||||
## Bundled Resources
|
||||
|
||||
### References
|
||||
|
||||
- `references/story-circle.md` - Eight-step Story Circle framework with examples. Read this first to understand the narrative structure.
|
||||
- `references/ia-presenter-syntax.md` - Complete iA Presenter markdown syntax reference. Read this when generating slides.
|
||||
|
||||
## Example Workflow
|
||||
|
||||
User: "I want to create a talk about migrating from JavaScript to TypeScript"
|
||||
|
||||
1. Gather their experience, main points, and target audience
|
||||
2. Read `story-circle.md`
|
||||
3. Map their content:
|
||||
- Introduction: Current JS codebase
|
||||
- Problem: Type safety issues and bugs
|
||||
- Exploration: Research into TypeScript
|
||||
- Experimentation: Pilot conversion on one module
|
||||
- Solution: Incremental migration strategy
|
||||
- Challenges: Third-party library types
|
||||
- Apply Knowledge: Full codebase migration
|
||||
- Results: 40% reduction in runtime errors
|
||||
4. Read `ia-presenter-syntax.md`
|
||||
5. Generate markdown slides with proper formatting
|
||||
6. Iterate based on feedback
|
||||
269
skills/conference-talk-builder/references/ia-presenter-syntax.md
Normal file
269
skills/conference-talk-builder/references/ia-presenter-syntax.md
Normal file
@@ -0,0 +1,269 @@
|
||||
# iA Presenter Markdown Syntax
|
||||
|
||||
Quick reference for creating slides in iA Presenter.
|
||||
|
||||
## CRITICAL: Tabbing Rules
|
||||
|
||||
**MUST be tabbed to appear on slides:**
|
||||
|
||||
- Regular paragraphs
|
||||
- Lists (bullets, numbered, tasks)
|
||||
- Block quotes
|
||||
- Definition lists
|
||||
- Tables
|
||||
- Images
|
||||
|
||||
**NO TAB needed (appear on slides automatically):**
|
||||
|
||||
- Headers (`#`, `##`, `###`, etc.)
|
||||
- Horizontal rules (`---`)
|
||||
- Fenced code blocks (` ``` `)
|
||||
- Math blocks (`$$`)
|
||||
|
||||
**Never appears on slides:**
|
||||
|
||||
- Comments (`//`)
|
||||
|
||||
## Slide Structure
|
||||
|
||||
### Create New Slides
|
||||
|
||||
```markdown
|
||||
---
|
||||
```
|
||||
|
||||
Use horizontal rules to split slides. No tab needed.
|
||||
|
||||
### Headings
|
||||
|
||||
```markdown
|
||||
# Heading 1
|
||||
|
||||
## Heading 2
|
||||
|
||||
### Heading 3
|
||||
```
|
||||
|
||||
Headers appear on slides automatically. No tab needed.
|
||||
|
||||
## Text on Slides
|
||||
|
||||
Regular paragraphs MUST be tabbed to appear on slides:
|
||||
|
||||
```markdown
|
||||
⇥This text will appear on the slide.
|
||||
⇥
|
||||
⇥This is another paragraph on the slide.
|
||||
```
|
||||
|
||||
Without tabs, text is spoken only (speaker notes):
|
||||
|
||||
```markdown
|
||||
This text is only for the speaker to read.
|
||||
```
|
||||
|
||||
## Text Formatting
|
||||
|
||||
Inside tabbed paragraphs:
|
||||
|
||||
```markdown
|
||||
⇥**bold text**
|
||||
⇥*italic text*
|
||||
⇥~~strikethrough~~
|
||||
⇥==highlighted text==
|
||||
```
|
||||
|
||||
Superscript and subscript:
|
||||
|
||||
```markdown
|
||||
⇥100m^2
|
||||
⇥y^(a+b)^
|
||||
⇥x~z
|
||||
```
|
||||
|
||||
## Lists
|
||||
|
||||
Lists MUST be tabbed to appear on slides:
|
||||
|
||||
```markdown
|
||||
⇥- Item one
|
||||
⇥- Item two
|
||||
⇥- Item three
|
||||
```
|
||||
|
||||
Numbered lists:
|
||||
|
||||
```markdown
|
||||
⇥1. First item
|
||||
⇥2. Second item
|
||||
⇥3. Third item
|
||||
```
|
||||
|
||||
Task lists:
|
||||
|
||||
```markdown
|
||||
⇥- [ ] Unchecked task
|
||||
⇥- [x] Completed task
|
||||
```
|
||||
|
||||
Nested lists:
|
||||
|
||||
```markdown
|
||||
⇥- Main item
|
||||
⇥ - Nested item
|
||||
⇥ - Another nested item
|
||||
```
|
||||
|
||||
## Block Quotes
|
||||
|
||||
Block quotes MUST be tabbed:
|
||||
|
||||
```markdown
|
||||
⇥> This quote appears on the slide
|
||||
```
|
||||
|
||||
## Definition Lists
|
||||
|
||||
Definition lists MUST be tabbed:
|
||||
|
||||
```markdown
|
||||
⇥Term
|
||||
⇥: Definition of the term
|
||||
⇥: Another definition
|
||||
```
|
||||
|
||||
## Code
|
||||
|
||||
### Inline Code
|
||||
|
||||
```markdown
|
||||
⇥Use `keyword` for inline code within a paragraph
|
||||
```
|
||||
|
||||
### Code Blocks
|
||||
|
||||
Fenced code blocks appear on slides automatically. NO TAB needed:
|
||||
|
||||
````markdown
|
||||
```typescript
|
||||
function hello() {
|
||||
console.log('Hello');
|
||||
}
|
||||
```
|
||||
````
|
||||
|
||||
Language tags are optional but recommended for syntax highlighting.
|
||||
|
||||
## Images
|
||||
|
||||
Images MUST be tabbed and added to Media Manager first:
|
||||
|
||||
```markdown
|
||||
⇥
|
||||
```
|
||||
|
||||
Note: Encode spaces as `%20`. Omit leading slash.
|
||||
|
||||
## Tables
|
||||
|
||||
Tables MUST be tabbed:
|
||||
|
||||
```markdown
|
||||
⇥| Name | Price | Tax |
|
||||
⇥|:--|--:|--:|
|
||||
⇥| Widget | 10$ | 1$ |
|
||||
⇥| Gift | 0$ ||
|
||||
```
|
||||
|
||||
Alignment:
|
||||
|
||||
- Left: `:--`
|
||||
- Right: `--:`
|
||||
- Center: `:-:`
|
||||
|
||||
## Math
|
||||
|
||||
Math blocks appear on slides automatically. NO TAB needed:
|
||||
|
||||
Inline math (needs surrounding text tabbed):
|
||||
|
||||
```markdown
|
||||
⇥An example of math $x+y^2$ within text.
|
||||
```
|
||||
|
||||
Block math:
|
||||
|
||||
```markdown
|
||||
$$
|
||||
\displaystyle \frac{1}{x}
|
||||
$$
|
||||
```
|
||||
|
||||
## Comments
|
||||
|
||||
Comments are only visible in the editor:
|
||||
|
||||
```markdown
|
||||
// This is a speaker note or reminder
|
||||
```
|
||||
|
||||
## Links and Footnotes
|
||||
|
||||
Links within tabbed content:
|
||||
|
||||
```markdown
|
||||
⇥Visit [this site](https://example.com) for more info.
|
||||
```
|
||||
|
||||
Footnotes:
|
||||
|
||||
```markdown
|
||||
⇥Text with footnote[^1].
|
||||
[^1]: Footnote content.
|
||||
```
|
||||
|
||||
Citations:
|
||||
|
||||
```markdown
|
||||
⇥Statement with source[p. 23][#Doe:2006].
|
||||
[#Doe:2006]: Author. _Title_. Publisher, Year.
|
||||
```
|
||||
|
||||
## Complete Slide Example
|
||||
|
||||
````markdown
|
||||
# Slide Title
|
||||
|
||||
// This is a speaker note - not visible on slide
|
||||
|
||||
⇥This paragraph appears on the slide because it's tabbed.
|
||||
|
||||
⇥Key points:
|
||||
⇥- First point
|
||||
⇥- Second point
|
||||
⇥- Third point
|
||||
|
||||
```typescript
|
||||
// Code blocks don't need tabs
|
||||
function example() {
|
||||
return 'This appears on slide automatically';
|
||||
}
|
||||
```
|
||||
````
|
||||
|
||||
---
|
||||
|
||||
## Next Slide
|
||||
|
||||
⇥More content here...
|
||||
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. Tab all regular content (paragraphs, lists, quotes, tables, images)
|
||||
2. Don't tab headers, code blocks, or math blocks
|
||||
3. Use comments for speaker notes
|
||||
4. Break complex code across multiple slides
|
||||
5. Test that all visible content is properly tabbed
|
||||
```
|
||||
107
skills/conference-talk-builder/references/story-circle.md
Normal file
107
skills/conference-talk-builder/references/story-circle.md
Normal file
@@ -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
|
||||
Reference in New Issue
Block a user