git:20261018.82709c2 to git:20261020.8caec6f

---

name: mine-community

description: Harvest a founder community (a subreddit, a forum, a newsletter archive) for what is actually working in app marketing, pricing, ASO and growth, then filter it honestly and file the few findings worth keeping. Drops milestone and promotional posts, keeps only claims that either converge with an unrelated source or contradict something the project already believes, and ranks the survivors against the app's real stage. Use when the user wants to learn from other founders, asks what is working for other people, says "mine r/<something>", "what are other indie devs doing", "find the best tips from this community", or pastes a community link and asks whether it is useful.

---

# Mine a community

Founder communities are full of people describing what worked for them. Most of

it is noise, some of it is advertising, and a little of it is the most useful

input available to someone running an app alone. This turns a community into a

few findings worth acting on, and throws the rest away.

This is not the research skill. Research answers a question you already have.

This reads a room and tells you which few things in it apply to you.

## The honesty rules

These exist because the failure mode here is confident nonsense, and it is

expensive: a founder spends a week on a tactic that never worked for anyone.

**Everything is a claim, not a measurement.** Nobody in a community posts

audited numbers. A revenue screenshot is a screenshot. Write "a dev reports",

never "it is proven that".

**Assume survivorship bias, and say so out loud.** A top posts listing from a

founder community is a sample of winners and self promoters. The people whose

identical tactic produced nothing do not post. Count the failures in your

sample and put the number in the output. If it is near zero, the sample cannot

tell you a tactic's success rate, only that the tactic sometimes works.

**Flag the posts that are themselves marketing.** A long tactical post that ends

with a link to the author's own tool is an advertisement with data attached. It

can still be useful. Say which ones they are.

**A claim earns its place by convergence or contradiction.** Keep a finding when

either:

- two unrelated sources reach it independently, especially when one of them is

the project's own existing research, or

- it contradicts something the project currently believes, in which case say so

plainly and do not resolve it by picking the newer source.

Everything else is interesting reading and does not go in the output.

**Never carry a number across from a different app's situation.** Someone's 20%

conversion at 50,000 followers says nothing about a conversion rate at 15 daily

users. Report the mechanism, not the multiplier.

## 1. Know the user's stage before reading anything

Findings are only rankable against a real situation. Read the project's rules

file, goals file and research folder, and write down in one line each:

- roughly how many people use the app now, and how many arrive a month

- which channels have already been tried, and what the project concluded

- what the project has already decided and closed

That last one matters most. A community will cheerfully recommend something the

user has already tried and rejected, and repeating it reads as not listening.

Standing decisions in the rules file are closed. Say when a finding touches one,

and do not reopen it.

## 2. Get the posts

Prefer whatever the user can give you with least effort. In order:

```

https://www.reddit.com/r/<subreddit>/top/.json?t=year&limit=100

```

Then parse `data.children[].data` for `title`, `selftext`, `score`,

Weaker, since you get what is quoted elsewhere rather than what the community

upvoted.

obvious junk first.

Respect each community's terms. Read what is public, do not republish it

wholesale, and quote only what you cite.

## 3. Drop the noise before reading

In a founder community most posts are celebrations with no content: a revenue

screenshot and a sentence. They carry the community's mood, not its knowledge.

- Drop anything whose body is under roughly 1,000 characters. In one Reddit

harvest this left 40 of 100 posts and lost nothing.

- Keep the long ones regardless of score. A detailed post at 90 points usually

beats a celebration at 500.

- Read the titles of everything you dropped once, in a list. The pattern of what

people celebrate is itself a finding, and it is free.

## 4. Read for mechanisms

For each surviving post, pull out only:

- **The mechanism**: what the person actually did, in enough detail to copy.

"Ten image carousels a day, confession framing, the app never named in the

post" is a mechanism. "Posted engaging content" is not.

- **The claimed result**, with its timeframe, quoted.

- **What it cost**: money, hours a week, and whether it needs a skill the user

does not have.

- **Whether the post is selling something.**

Quote the exact words for anything that will be acted on. Paraphrase loses the

detail that makes a tactic reproducible.

## 5. Rank for this user, not in the abstract

Order the survivors by what the user can act on now:

1. Converges with the project's own research, and is cheap at the user's size.

2. Converges, but costs real money or a skill they do not have.

3. Contradicts something the project believes, and is worth sitting with.

4. Works only at a size the user is not at yet. Say when it becomes relevant.

Mark anything that touches a standing decision. Name the decision, say the

finding exists, and leave it closed.

## 6. Answer in chat

Short. Lead with the single most useful finding, not with the method.

```

<N> posts, <date range>. <M> had real content; the rest were milestone posts.

Caveat: <survivorship, and how many of the substantive posts are selling something>.

The finding worth the harvest: <one paragraph, with the quote>

Ranked for where you are:

1. <mechanism> <what it costs> <what it converges with>

2. ...

Confirms what you already decided: <one line each>

Contradiction worth sitting with: <one, or none>

Saved: <path>

```

## 7. File it

Write a dated doc in the project's research folder, following whatever naming

the project already uses. It must carry:

- the date, the source, the sample size and the date range of the posts

- the honesty caveats from the top of this skill, in the doc, not just in chat

- the quotes, since the next reader cannot re run the harvest

- which findings converge with which existing project docs, by filename

- the method, so the harvest can be repeated without rediscovering it

Then add the project's usual one line index entry wherever research docs are

indexed, with the headline finding in it rather than a description of the topic.

## What this skill will not do

- It will not turn a community into a strategy. It produces inputs to a decision

the user makes.

- It will not rank a channel by how often it is mentioned. Popularity inside a

community measures the community, not the channel.

- It will not recommend a tactic the project has already tried and rejected,

however many people are recommending it this month.