Turn GitHub Work into Shareable Content
Analyze your commits and PRs to draft an X thread. Building in Public becomes effortless.
Who This Is For
- Developers who want to share their side project journey on X (Twitter)
- Indie hackers and solopreneurs looking to grow followers through Building in Public
- Anyone who wants to document weekly dev progress but lacks the time
Template Overview
Automatically analyzes your GitHub repository's commits, PRs, and issues to summarize your weekly work and generate a ready-to-post X thread draft.
Auto-generated content includes:
- 🎯 This week's challenges and goals
- 🔨 Work attempted and results table
- 💡 Lessons learned and difficulties faced
- ➡️ Next week's goals
- 📱 X thread draft (5-tweet structure)
How to Use
Getting Started
- Select the template and connect your GitHub repository
- Set the update schedule (Friday recommended)
- AI analyzes commits and PRs to generate your building story and X thread
Repository Selection Tips
Connect repositories suitable for Building in Public:
- Side projects you're actively working on
- Open source projects
- Projects your followers would find interesting
Tips
- Use as a weekly routine: Set auto-updates for Friday so you can easily share over the weekend
- Share honestly: Including failures and struggles makes your content more authentic
- Use numbers: Instead of "worked hard", say "merged 3 PRs, fixed 2 bugs"
- End with a question: Asking questions at the end of your thread increases follower engagement
One-liner: Completely revamped the template system to feed format for better user experience.
🎯 This Week's Challenge
- Goal: Convert template previews from tables to feed format
- Context: Feedback that tables are hard to read on mobile
🔨 What I Tried
- Task: Update community-content-ideas template to feed format
- Result: ✅ Done
- Commit/PR:
784189b4
💡 What I Learned
- What worked: Introduced FeedEntry[] type for consistent feed rendering
- What was hard: Maintaining type compatibility between old table and new feed formats
- What I'd do differently: Design with feed format from the start to reduce migration cost
➡️ Next Steps
- Migrate remaining templates to feed format
- Regenerate OG images
X Thread Draft
1/ Hook
This week I completely revamped Daigest's template system. From tables to feeds!
2/ The Problem
Kept getting feedback that tables with horizontal scroll were hard to read on mobile.
3/ The Solution
Defined new FeedEntry[] type and changed rendering to date-based card format.
4/ Lesson
Should have thought mobile-first. Choosing tables based on desktop view was a mistake.
5/ CTA
How do you handle mobile UX in your projects?
One-liner: Focused on mobile UX improvements, fixing iOS input fields and bottom sheet behavior.
🎯 This Week's Challenge
- Goal: Improve mobile user experience
- Context: iOS auto-zoom on input and bottom sheet closing behavior bugs
🔨 What I Tried
-
Task: Fix TreePanel bottom sheet close behavior on deselect
-
Result: ✅ Done
-
Commit/PR:
f05f7796 -
Task: Prevent iOS input field auto-zoom and fix modal header
-
Result: ✅ Done
-
Commit/PR:
61fb0421
💡 What I Learned
- What worked: font-size: 16px solved iOS auto-zoom issue
- What was hard: Figuring out iOS Safari's quirky behavior
- What I'd do differently: Test on real iOS devices from the start
➡️ Next Steps
- Test on various Android devices
- Improve touch interactions
X Thread Draft
1/ Hook
You know how iOS zooms in when you tap an input field? Finally fixed it this week.
2/ The Problem
Mobile users kept experiencing auto-zoom on inputs and weird bottom sheet closing behavior.
3/ The Solution
Turns out iOS doesn't auto-zoom if font-size is 16px+. One line of CSS fixed it!
4/ Lesson
Real device testing matters. This bug didn't reproduce in the simulator at all.
5/ CTA
Any iOS Safari debugging war stories to share?
One-liner: Completed AI agent performance optimization and plan limit adjustments.
🎯 This Week's Challenge
- Goal: Improve AI agent response speed and balance pricing plans
- Context: Feedback that responses were slow due to excessive output tokens
🔨 What I Tried
-
Task: Reduce output token limit (16384 → 7000)
-
Result: ✅ Done
-
Commit/PR:
45ed9df4 -
Task: Adjust AI request limits (Free 20, Starter 320, Pro 1220)
-
Result: ✅ Done
-
Commit/PR:
b49df9d6
💡 What I Learned
- What worked: Token limit doubled response speed, reduced costs
- What was hard: A/B testing to find optimal token count
- What I'd do differently: Build token usage monitoring dashboard from the start
➡️ Next Steps
- Build usage dashboard
- Automate token efficiency reports
X Thread Draft
1/ Hook
Users leaving because AI responses are too slow? This week I 2x'd response speed with token optimization.
2/ The Problem
Allowed up to 16384 output tokens. Responses were too long and slow. Users got tired of waiting.
3/ The Solution
A/B tested to find the sweet spot. Cutting to 7000 tokens maintained quality while doubling speed!
4/ Lesson
"More is better" was a fallacy. Proper constraints actually improve UX.
5/ CTA
For those running AI services - how do you set your token limits?
Sample preview generated from public sources for illustration. Daigest summarizes and links back to original articles — it doesn't reproduce or claim ownership of them.
Daigest will create a briefing for you with this template