mine-community git:20261018.82709c2A

Immutable. This exact content never changes and is served at /api/v1/blob/209c8dcd177c198a.

---
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:

1. **The user saves the page.** For Reddit, a signed in browser is served JSON
   directly, while scripts and datacenter addresses are refused. Give them the
   URL, ask them to open it in their browser and save the file:

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

   Then parse `data.children[].data` for `title`, `selftext`, `score`,
   `num_comments` and `created_utc`. Checked 2026-10-18.

2. **A web search**, when the community is indexed and you only want a sample.
   Weaker, since you get what is quoted elsewhere rather than what the community
   upvoted.

3. **The user pastes posts.** Fine, and often better, since they filter the
   obvious junk first.

Do not build or install a scraper for a one time harvest, and do not send the
user through an API approval queue to read a forum. If the easy routes fail, say
so and ask for pastes.

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.