know-if-its-working — Claude Code skill: what it does, how to install
Audits developer tool go-to-market performance using retention cohorts and the DREAM funnel. Useful when stars grow but users churn.
npx skills add AIDevGTM/gtm-cofounder --skill 15-know-if-its-working -a claude-codeWhat know-if-its-working does
This skill implements developer-focused go-to-market analysis based on frameworks by Adam Frankl and Jakub Czakon. It replaces vanity figures like GitHub stars or site impressions with net developer retention. The target threshold sits above 100%, where cohorts expand through internal adoption.
The workflow uses the DREAM funnel to measure one specific metric per phase: discovery visitors, community follows, free-tier signups, monthly active usage, and active forum posters. The key gate is the weekend test. A new developer must reach first value from documentation alone in under an hour, or one day at most. Scaling paid channels before passing this test wastes budget on churn.
Attribution relies on directional trends rather than fragile click tracking. It suggests adding a free-text question to registration, since direct signups often obscure months of lurking after reading a tutorial.
What it helps with
- calculate net developer retention across monthly cohorts
- evaluate user onboarding using the weekend test
- replace vanity metrics with honest DREAM funnel signals
- identify whether acquisition spending makes sense right now
Example prompts for the agent
- Check our dev-tool metrics against the DREAM framework
- Calculate cohort retention for users who joined 8 weeks ago
- Audit our onboarding flow against the weekend test criteria
How to install know-if-its-working
1Skills CLI (Vercel)
npx skills add AIDevGTM/gtm-cofounder --skill 15-know-if-its-working -a claude-code2Manually: put the files in place
~/.claude/skills/15-know-if-its-working/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/15-know-if-its-working/
1Skills CLI (Vercel)
npx skills add AIDevGTM/gtm-cofounder --skill 15-know-if-its-working -a codex2Manually: put the files in place
.agents/skills/15-know-if-its-working/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add AIDevGTM/gtm-cofounder --skill 15-know-if-its-working -a cursor2Manually: put the files in place
.cursor/skills/15-know-if-its-working/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install AIDevGTM/gtm-cofounder 15-know-if-its-working2Manually: put the files in place
.github/skills/15-know-if-its-working/SKILL.md1Skills CLI (Vercel)
npx skills add AIDevGTM/gtm-cofounder --skill 15-know-if-its-working -a gemini-cli2Platform CLI
gemini skills install https://github.com/AIDevGTM/gtm-cofounder --path skills/15-know-if-its-workingManually: put the files in place
.devin/skills/15-know-if-its-working/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add AIDevGTM/gtm-cofounder --skill 15-know-if-its-working -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about know-if-its-working
How to install know-if-its-working in Claude Code?
Run npx skills add AIDevGTM/gtm-cofounder --skill 15-know-if-its-working -a claude-code. The skill file will be placed in ~/.claude/skills/15-know-if-its-working/SKILL.md.
What does the know-if-its-working skill do?
It guides founders and developers through auditing their dev-tool go-to-market metrics. It focuses on cohort retention and time-to-value instead of surface-level pageviews or GitHub stars.
What is the weekend test in this skill?
It is an onboarding benchmark requiring a new developer to get first value within one hour, or at most one day, relying only on docs and Stack Overflow. Without passing it, activation fails and channel acquisition will leak users.
Source text
SKILL.md · MIT
---
name: know-if-its-working
description: Measure GTM with the metrics that matter (net developer retention, DREAM funnel) instead of vanity numbers. Use when the user has dashboards full of stars and pageviews but can't tell if go-to-market is working, or is optimizing acquisition over a leaky bucket.
---
# Know if it's working
> The only early metric that matters is **net developer retention**. Without it, you're not running a funnel; you're running a colander.
**Use this when:** you're tracking GitHub stars and pageviews and still can't answer "is GTM working?", or you're pouring effort into acquisition while new users quietly churn.
## The core idea
Acquisition is worthless if users don't come back. Prove **retention** first; only then does spending on **acquisition** make sense. Most early founders optimize the top of the funnel while the bottom leaks. Fix that order.
## Framework: net developer retention (Frankl)
> Of all the developers who first used the product in **Month 1**, how many used it in **Month 2? Month 3?**
- Hold it **above 100%** (meaning existing cohorts *grow* through internal referral/expansion).
- Below solid retention, **do not focus on acquisition**: you're filling a leaky bucket.
- This single cohort question tells you more than every vanity chart combined.
## Framework: the DREAM metrics (Frankl)
Measure one honest number per stage, not pageviews, not stars.
| Stage | The metric that counts |
|---|---|
| **Discovery** | unique human visitors / month |
| **Research** | newsletter subs + community joins + follows |
| **Evaluation** | free-tier signups / downloads / active free users |
| **Activation** | monthly active users · frequency · session depth |
| **Membership** | community members *actively* posting & answering |
**The gate before all of it, the weekend test:** can a new developer get to first value **over a weekend from docs + Stack Overflow, no support call?** Time-to-value target: **< 1 hour ideal, 1 day max.** If Evaluation/Activation fails here, no channel work will save you.
## Growth benchmarks (non-ARR, Frankl)
- **Pre-seed:** ~30% month-over-month user growth
- **Post-Series-A:** ~10% MoM
- **First $1M ARR:** within 12 months is good, 9 is excellent
## Framework: attribution philosophy (Czakon)
Developer marketing is **hard to attribute and that's normal.** A dev sees your HN post, reads a tutorial, lurks for two months, then signs up direct.
- Don't over-trust last-touch; it will tell you "direct/organic" and hide the real work.
- Add a **"how did you hear about us?"** free-text field. Self-reported attribution beats a broken model.
- Judge channels on *trend* and *directional* signal, not spurious precision.
## Decision tree: what to fix first
```
Is month-2 cohort retention healthy (users come back)?
├─ NO → STOP optimizing acquisition. Fix Evaluation/Activation (the weekend test, time-to-value).
└─ YES → is a channel reliably producing retained users?
├─ YES → pour more in (and only now consider paid to amplify).
└─ NO → go back to first-50-users; find the channel before scaling spend.
```
## Mistakes that look reasonable
- **Vanity metrics**: stars, pageviews, impressions. They feel like progress and predict nothing.
- **Acquisition over a leaky bucket**: buying users who never return.
- **Demanding clean attribution**: chasing a perfect model instead of acting on directional signal.
- **Ignoring the weekend test**: a beautiful funnel that dies at first-value.
## Your next 30 minutes
- [ ] Compute one number: of the devs who first used it 8 weeks ago, what % used it in the last 2 weeks?
- [ ] Pick **one** honest metric per DREAM stage; delete the vanity charts from your dashboard.
- [ ] Time yourself doing your own onboarding cold. Over an hour? That's your #1 GTM problem.
- [ ] Add a "how did you hear about us?" field to signup this week.
---
Built from real dev-tool GTM experience, with frameworks from Adam Frankl (*The Developer-Facing Startup*) and Jakub Czakon (*markepear.dev*).
If your numbers are telling a story you can't read, get a human to look with you. Reach out to me on [LinkedIn](https://www.linkedin.com/in/devtoolgtm/).
© AIDevGTM · MIT · AIDevGTM/gtm-cofounder