Transform meaningful commits into engaging technical content for Twitter/X.

Table of Contents

Philosophy

The goal isn’t to tweet every commit—it’s to identify meaningful moments worth sharing:

  1. Build in public - Show progress, not perfection
  2. Teach through work - Extract learnings from real implementation
  3. Be specific - Vague posts don’t perform; specificity builds trust
  4. Vulnerability wins - Debugging stories beat success announcements

What Makes a Commit Tweet-Worthy

High Tweet Potential

SignalWhy It Works
New feature implementationShows capability + teaches patterns
Problem solved after struggleRelatable debugging story
Architectural decisionSparks discussion on tradeoffs
Performance improvement with numbersConcrete, measurable wins
Migration/refactor completedReal-world lessons learned
Tool or library evaluationHelps others make decisions

Skip These

  • Pure documentation updates (unless major)
  • Version bumps
  • Typo fixes
  • Test-only commits (unless testing philosophy)
  • “WIP” or checkpoint commits

The 7 Tweet Angles

Every tweet-worthy commit can be framed through one of these angles:

1. The Learning Angle

Share what you learned implementing the feature.

Structure:

TIL while building [feature]:


[Specific insight or surprise]


[Optional: code snippet or link]

2. The Problem/Solution Angle

Frame as a problem you solved.

Structure:

Problem: [Pain point]
Solution: [What you built]


[Optional: How it works]

3. The Milestone Angle

Celebrate progress on a larger project.

Structure:

[Project] milestone: [Achievement]


Next up: [What's coming]


[Optional: Screenshot/demo]

4. The Technical Deep-Dive Angle

Explain an interesting technical decision.

Structure:

Why I chose [approach A] over [approach B] for [context]:


[Bullet points of reasoning]


[Optional: Link to code/blog]

5. The Numbers Angle

Share concrete metrics and performance.

Structure:

[Before/After] or [Metric achieved]:


• [Specific number 1]
• [Specific number 2]


How: [Brief explanation]

6. The Hot Take Angle

Share an opinion formed from real implementation experience.

Structure:

After [building/using X], hot take:


[Your opinion]


[Evidence from your experience]

7. The Thread Angle

For complex features, create a build thread.

Structure:

Building [feature] for [project] 🧵


1/ [Context and goal]
2/ [Challenge faced]
3/ [Approach taken]
4/ [Interesting detail]
5/ [Result + link]

Real Examples from Your Commits

Example 1: Multi-street MCCFR (Algorithm Implementation)

Commit:

Phase 2: Implement full multi-street MCCFR for Limit Hold'em
- 32,887 info sets in 500 iterations
- ~26 iterations/sec on CPU
- 131 tests passing

Tweet Options:

Learning Angle:

TIL implementing Monte Carlo CFR for poker:


Position rules flip between streets—SB acts first preflop, BB first postflop.


Took me 47 tests to get the street detection right.


131 tests later, it works across all 4 betting rounds.

Numbers Angle:

Full 4-street poker solver running:


• 32,887 game states (info sets)
• 26 iterations/sec on CPU
• 131 tests, 0 failures


Next: GPU acceleration for 100x speedup.

Hot Take Angle:

After implementing MCCFR for poker:


The algorithm is simple. The edge cases around position switching and bet sizes are where you lose days.


Lesson: Test every state transition exhaustively before integration.

Example 2: CLI Framework Migration (Refactor)

Commit:

refactor: migrate CLI from Commander.js to nest-commander
- 10 commands converted to decorator pattern
- Removed commander dependency
- Tests directly instantiate command classes

Tweet Options:

Problem/Solution Angle:

Problem: Commander.js + NestJS = awkward wrapper code


Solution: Migrated to nest-commander


• Native @Command/@Option decorators
• Commands are just NestJS providers
• Tests mock at constructor level


10 commands converted in one session.

Learning Angle:

TIL about nest-commander:


If you're using NestJS + Commander.js, you're writing unnecessary glue code.


nest-commander gives you:
• Decorator-based commands
• DI just works
• Testing is straightforward


Wish I'd found this earlier.

Example 3: Multi-Agent Documentation System (Architecture)

Commit:

Implement intelligent multi-agent documentation system
- Agent-based template processing
- Context-aware Mermaid diagram creation
- Component detection triggers CREATE vs UPDATE

Tweet Options:

Milestone Angle:

Shipped: Intelligent documentation system for @anthropic Claude


It watches for architectural changes and auto-generates:
• C4 diagrams
• ADRs
• Component docs


Single source of truth, always in sync.

Technical Deep-Dive Angle:

Why I built an agent-based doc generator instead of templates:


1. Templates can't assess architectural impact
2. Context-aware content > string substitution
3. CREATE vs UPDATE needs different logic


Result: Docs that understand the codebase.

Example 4: Search Scope Feature (Small but Useful)

Commit:

feat: add scope parameter to search_personal MCP tool
- Enables searching facts (edges) and entities (nodes)
- Default maintains backward compatibility

Tweet Options:

Problem/Solution Angle:

Small win today:


Problem: My AI memory tool only searched conversations


Solution: Added scope parameter to search facts and entities too


search_personal({ query: "...", scope: "edges" })


Now I can query relationships, not just raw chat history.

Tweet Structure Patterns

The Hook → Detail → CTA Pattern

[Hook: surprising fact or result]


[Detail: how you achieved it]


[CTA: link, question, or next step]

The Before/After Pattern

Before: [old state]
After: [new state]


[What changed and why]

The Question → Answer Pattern

[Question you had]


After [building/researching], the answer:


[Your finding]

Workflow Integration

Option 1: Post-Commit Hook Review

After each meaningful commit, ask:

  1. Does this teach something?
  2. Did I struggle with something others might?
  3. Are there concrete numbers to share?

If yes to any, draft a tweet.

Option 2: Weekly Batch

Every Friday:

  1. Review week’s commits: git log --since="1 week ago" --oneline
  2. Pick 2-3 tweet-worthy ones
  3. Draft using angle templates
  4. Schedule for next week

Option 3: Real-Time Build Threads

For larger features:

  1. Start a thread when you begin
  2. Add updates as you hit milestones
  3. Close with the final result

Using x-cli

Post directly from terminal:

Terminal window
bun run packages/x-cli/src/main.ts tweet "Your tweet here"

Sources