why-they-said-yes
Skill1 starsChanged 26 days agoMITView on GitHub
Studies a founder's wins (customers who paid, people who replied, posts that worked) to find out why they worked and rewrite the ideal customer profile from evidence. Use when a founder has a few customers or replies and wants to know who to look for next, asks for voice of customer analysis, wants to learn from early users, or says \"what do my customers have in common\".
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
- update-that-earns-a-dmSkill
- where-my-customers-areSkill
- who-buys-from-meSkill
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 19
If possible, a few who said no or went quiet, for contrast.
- Distinctive: line 36
Rewrite the profile: Keep what the evidence supports, delete what it doesn't, add what you didn't expect.
- Distinctive: line 66
Don't flatter the original plan.
- Distinctive: line 67
Keep the founder's direct relationship with these early customers.
- Distinctive: line 72
When the MyPip MCP is live, this skill will be able to read who said yes, no, or nothing to your introductions across your MyPip account, …
≈ “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
Why they said yes
Study your wins harder than your flops.
When something fails, founders take it apart for weeks. When something works, they say "nice" and move on. That's backwards. Analysing a failure mostly tells you one way not to do it. Analysing a win, in detail, tells you something you can repeat on purpose.
This skill takes whatever early wins exist (three customers, a handful of good replies, one post that took off) and works out what those people and moments had in common. The answer usually overwrites the profile the founder started with. That's the point. The first ideal customer profile is a guess. Your customers correct it.
What you need
Anything real. More is better, but three examples beats none.
- The people who said yes: customers, paying users, people who replied warmly, people who asked to try it. For each: what you know about them, where they came from, what they said in their own words.
- If possible, a few who said no or went quiet, for contrast.
- The founder's current idea of who the customer is.
Steps
- Lay the wins out side by side. One row per person. Columns: where they found you or you found them, what they said first, how quickly they understood the product, what they'd tried before, anything personal you know.
- Look for soft traits first. Shared attitudes, habits, places they spend time, things they care about, how they write. These are usually the real pattern. Plastic Bank's planned buyer was a sustainability director at a mid-sized company; the people who actually signed up turned out to share a love of the ocean and a humble, well-travelled outlook, and had little to do with job title.
- Measure speed of getting it. Which people understood the product fastest, with the fewest questions? Speed is a stronger fit signal than enthusiasm. Slow conversations full of questions usually mean the wrong person or the wrong message.
- Find the moment. For each win, what was happening for them right before they said yes? A launch that flopped, a new job, a deadline, a tool that broke. That moment is what to look for in the next person.
- Collect their words. Pull the exact phrases they used for the problem. Group the ones that repeat.
- Contrast with the no's. What did the people who said no or went quiet have that the yeses didn't? Those become your warning signs.
- Rewrite the profile. Keep what the evidence supports, delete what it doesn't, add what you didn't expect. Be honest when the data is thin. Three people is a hint, not a law.
Output
What the yeses share (strongest first):
1. <trait>, seen in <n> of <n>: <evidence>
The moment before yes: <what was happening for them>
Their words for the problem:
- "<exact phrase>" (<n> people)
Fastest to get it: <who, and what they had in common>
What the no's had instead (new warning signs):
- <trait>
Profile changes:
Keep: ...
Drop: ...
Add: ...
Confidence: <low / medium / high>, because <how much data>
Next: <who to find next, and where>Rules
- Evidence over theory. Every claim cites the people it came from.
- Don't flatter the original plan. If the data says the founder targeted the wrong person, say so plainly.
- Keep the founder's direct relationship with these early customers. The people who said yes are also the people most worth calling for the next product decision.
- Revisit this every time the number of wins doubles.
With MyPip (coming)
When the MyPip MCP is live, this skill will be able to read who said yes, no, or nothing to your introductions across your MyPip account, so the analysis runs on every reply instead of the few you remember.
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.

