update-that-earns-a-dm
Skill1 starsChanged 26 days agoMITView on GitHub
Rewrites a founder's build-in-public update so it speaks to the customer's problem instead of the founder's changelog, making the right reader see the product's value for themselves and get in touch. Use for build in public posts, product update posts, shipping announcements on X, LinkedIn, Reddit or Indie Hackers, or when a founder says \"my updates get likes from other founders but no customers\".
In this repository15 other files it gives its agents.
- alert-wordsSkill
- ask-for-an-introductionSkill
- customer-interviewSkill
- daily-fiveSkill
- expert-to-skillSkill
- find-one-personSkill
- first-messageSkill
- one-line-pitchSkill
- readiness-checkSkill
- reddit-reply-not-pitchSkill
- research-one-personSkill
- show-hn-launchSkill
- where-my-customers-areSkill
- who-buys-from-meSkill
- why-they-said-yesSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Write updates for the customer who might be watching, not the founders who'll clap.
- Distinctive: line 48
Before: "Big week! Shipped dark mode, a new onboarding flow and Slack notifications.
- Distinctive: line 56
No follower-growth tricks, no threads of generic lessons, no fake urgency.
- Distinctive: line 57
No em dashes, no emojis as decoration, no "excited to announce".
- Distinctive: line 62
When the MyPip MCP is live, this skill will be able to use the words real people used when they said yes to an introduction, so your …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
The update that earns a DM
Write updates for the customer who might be watching, not the founders who'll clap.
"Just shipped a new onboarding flow" gets likes from other founders doing the same thing. It rarely gets a message from a customer, because nothing in it is about them. The update that brings customers is framed on their problem: "people kept getting stuck before they saw any value, so I cut setup to one step." The same work, written so the right reader recognises their own situation.
Followers are the wrong scoreboard. A small audience with one right person in it is worth more than a big one with none. The update's job is to make that one person think "this is for me".
What you need
- What the founder shipped, learned or changed. A rough note is fine.
- Who the customer is and the problem they have.
- The platform: X, LinkedIn, Reddit, Indie Hackers, a newsletter.
- Any real number or real moment behind it. Optional, but it helps.
Steps
- Find the customer reason. Why did this change happen? Which customer problem, complaint or moment caused it? If there's no customer reason, ask whether it's worth posting about.
- Lead with the problem, in their words. Open on what the customer was struggling with, not on what you built.
- Show the change as their gain. What's easier, faster or possible for them now.
- Add one piece of real evidence. A real number, a named moment, a screenshot description, what someone said. Never invented.
- Leave a door open, quietly. The reader should be able to tell what the product is and how to try it. No hard call to action, no engagement-bait question at the end. Stop when the point is made, or end on one line the post earned.
- Fit the platform. Learn how each place talks. A LinkedIn post, a Reddit post and a tweet are different shapes. On Reddit, check the community's rules and write it as a useful story, not an announcement.
Output
Customer reason: <the problem that caused the change>
Update (<platform>):
<text>
What the right reader takes from it: <one sentence>Before and after
Before: "Big week! Shipped dark mode, a new onboarding flow and Slack notifications. Loving the progress."
After (for a made-up invoicing tool): "Most freelancers who signed up last month never sent a single invoice, because setup asked for twelve fields before anything happened. Now you paste a client's email and the first invoice is ready to send. If you've been putting off chasing a payment, that's the bit I fixed."
Rules
- One idea per update.
- Share what you're learning, including what didn't work. Holding ideas back stops them finding the right people. Honesty and real numbers read as trustworthy because so little online does.
- No follower-growth tricks, no threads of generic lessons, no fake urgency.
- No em dashes, no emojis as decoration, no "excited to announce".
- Post consistently. The update that finds a customer is rarely the first one.
With MyPip (coming)
When the MyPip MCP is live, this skill will be able to use the words real people used when they said yes to an introduction, so your updates speak in the same language your customers do.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

