agentleFS
T4LELT4LEL/Claude-Arsenal/skills/grow/SKILL.md

grow

Skill1 starsChanged 4 months agoMITView on GitHub

Use when working the growth loop on a launched product - or when the user says more users, growth, traffic is flat, improve conversion, improve retention. Run it monthly or when growth stalls.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 4

    Distinctive

    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
  1. Distinctive:

    Run the growth loop on numbers, not hunches.

    line 8
  2. Distinctive:

    No numbers available: stop here and instrument first (events, a funnel view, a retention query).

    line 26
  3. Distinctive:

    Before closing Step 4, verify the change actually works where it runs — load the page, send the test email, hit the endpoint — and capture …

    line 47
  4. Distinctive:

    Review date & threshold: when it gets checked and the exact number that counts as a win.

    line 58

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Grow

Run the growth loop on numbers, not hunches. No real numbers means no growth work yet — go get them first.

Copy this checklist and check off items as you complete them:

Grow Progress:
- [ ] Step 1: Numbers first — real funnel + retention pulled
- [ ] Step 2: Bottleneck identified
- [ ] Step 3: Experiments — 3 candidates + 1 recommendation
- [ ] Step 4: Ship it — routed to the right agent
- [ ] Step 5: Close the loop — review date + threshold set
- [ ] Report

Step 1 — Numbers first

Delegate to the data-analyst agent with the product's database/analytics access: pull the current funnel (visitors → signup → activation → paid) and retention, from real queries against Supabase or whatever analytics source exists — not dashboards recalled from memory.

No numbers available: stop here and instrument first (events, a funnel view, a retention query). Guessing is not growth. Any figure not backed by a real query — including anything pulled from memory or a prior conversation — gets labeled an unverified assumption, never reported as data.

Step 2 — Bottleneck

From the real funnel, identify the single weakest stage. Retention leaks outrank acquisition ideas — fixing the bucket beats pouring more water in it. State the bottleneck as a number (e.g. "38% activation → paid, industry-ish baseline is higher"), not a vibe.

Step 3 — Experiments

Delegate to the growth-marketer agent with the funnel numbers and the identified bottleneck: 3 candidate experiments, each with a hypothesis, the metric it moves, an effort estimate, and a timebox. The agent picks ONE recommendation and says why over the other two — recommend by expected impact per unit effort, not novelty.

Step 4 — Ship it

Route execution to the agent that owns the surface — never do the work in this skill directly:

  • Copy changes (landing page, emails, onboarding text) → copywriter agent.
  • Page/UI changes → frontend-builder agent.
  • Emails, drip sequences, scheduled jobs → automation-engineer agent.
  • SEO changes → growth-marketer agent for strategy plus frontend-builder agent for implementation.

Fetch current docs for any third-party integration (email provider, analytics, Stripe if the experiment touches pricing) via the context7 MCP tools before wiring it up. Keys and tokens stay in env vars, never printed into chat or committed. Nothing here gets committed, pushed, deployed, or published without the user's explicit ask.

Before closing Step 4, verify the change actually works where it runs — load the page, send the test email, hit the endpoint — and capture the evidence. An experiment that never really shipped can't be measured in Step 5.

Step 5 — Close the loop

Set an explicit review date and a numeric success threshold for the experiment (e.g. "signup→activation from 38% to 45% by Aug 15"). An experiment without a threshold never closes — it just lingers. Suggest /loop or /schedule to automate the check-in so the review actually happens instead of getting forgotten.

Report

  • Funnel snapshot: real numbers, with the period they cover.
  • Bottleneck: the weakest stage and why it was picked over the others.
  • Experiment shipped: hypothesis, metric, and timebox for the one experiment executed.
  • Review date & threshold: when it gets checked and the exact number that counts as a win.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.