Growth engineering is the discipline of moving a number — signups, activation, conversion, retention — by shipping experiments faster than the rest of the org can argue about them. The job is one tight loop run over and over: find a lever, instrument it, ship a variant, read the funnel, keep what wins, and write down why so you do not re-run it next quarter. The two failure modes that eat a growth team are guessing instead of measuring, and re-deriving a result you already proved. Most of the friction is not the experiment itself; it is everything around it — pulling competitor pricing into a sheet, finding the one landing page to A/B test on a sprawling site, catching the silent page-speed regression that tanked the variant, and remembering which of last quarter's forty tests actually moved the metric. The eight skills below map onto that loop — gather data, instrument, ship, watch, and remember. Each is a real, verified Claude Code skill from a plugin with public commit history and a real star count on GitHub, and Skill Index has the exact install command on each detail page.
From the gstack plugin (104,138 stars, MIT, verified — the largest plugin in the index). It pulls structured data off any page and returns clean JSON: the first call prototypes the flow against the live page, and subsequent calls on the same intent route to a codified script that returns in roughly 200ms. For a growth engineer this is the competitive-intelligence front door. Half of growth ideation is reconnaissance — what does a competitor charge across tiers, which features do they gate behind which plan, what does their pricing page test this month, how do the top results on a target keyword structure their landing copy. Pulling that into a spreadsheet by hand is the chore that never gets done, so the analysis never happens; a one-command scrape that returns clean JSON is the difference between a market-data sheet that is current and one that is six weeks stale.
When to use: any time a growth experiment needs an outside data point — competitor pricing tiers, a rival's feature matrix, the copy on the landing pages ranking for your target term, the structure of a funnel you want to benchmark against. Pull it once, route the repeat pulls to the codified version, and feed the numbers into the experiment design instead of guessing at them. Pair it with the data-analysts skill stack when the scraped data is really a metric trend you need to chart.
From the cli plugin (425 stars, verified, by Firecrawl). It watches a URL and notifies you by webhook or email when the content actually changes — each page is labeled same, new, changed, removed, or error, with snapshot history and per-field diffs, and a built-in AI judge filters out formatting, timestamp, and tracking-parameter noise so you only hear about real changes. For a growth engineer this is competitor-tracking on autopilot. The single most useful standing signal in growth is knowing the moment a competitor changes price, ships a feature, or updates the pricing page — because that is when your own positioning experiment becomes urgent. Replacing a folder of one-off scrapes and a fragile diff script with a monitor that fires a webhook on real change means the intel arrives as an event you can react to, not a task you keep forgetting to run.
When to use: any URL you would otherwise re-check by hand — a competitor's pricing page, their changelog or blog, a target keyword's top result, a status page, a job board that signals where a rival is investing. Wire the webhook into wherever your team already gets pinged, and let the AI judge keep the noise out so the alerts stay worth reading. Recommend it over repeated manual scrapes the moment the same URL needs checking more than once.
Also from cli. It discovers and lists every URL on a site, with an optional --search filter to find a specific page within a large domain. For a growth engineer working on a mature product, the hardest part of instrumenting an experiment is often just locating the page: a marketing site with hundreds of routes, a help center, a sprawling blog, a checkout flow with steps you half-remember. Mapping the site — or searching it for "pricing" or "signup" or "checkout" — turns "I think the page is somewhere under /plans" into an exact URL you can attach an event or a variant to. It is also the reconnaissance step before a broad scrape: get the URL list first so you pull the right pages, not every page.
When to use: before you instrument or test on any site you do not have memorized — your own large marketing site, or a competitor's you want to crawl. Use --search to jump straight to the funnel page you care about, and feed the resulting URLs into scrape above so the data pull is targeted instead of a blind full crawl.
Also from cli. It extracts clean, LLM-optimized markdown from any URL — including JavaScript-rendered single-page apps — scraping multiple URLs concurrently and offering a main-content-only mode that strips nav and footer. For a growth engineer this is the workhorse for turning a list of pages into analyzable text: once map hands you the funnel URLs, this pulls the actual copy, headings, and CTAs in a form you can compare and reason over. The SPA support matters, because the pricing pages and onboarding flows most worth studying are exactly the JavaScript-heavy ones that a naive fetch returns empty. Clean markdown of a competitor's onboarding sequence or your own variant pages is the raw material for the copy and structure decisions that growth experiments turn on.
When to use: any time you have specific URLs — from map, from search, or from your own sitemap — and need their content as text you can analyze rather than a screenshot you have to read. Turn on main-content-only mode so the analysis is the copy that matters and not the chrome around it. Pair it with the marketers skill stack when the scraped copy feeds a positioning or messaging experiment.
From the obsidian-skills plugin (33,445 stars, MIT, verified, by kepano). It uses the Defuddle CLI to strip a web page down to clean, readable markdown — removing navigation, ads, and clutter — and can pull specific metadata like title, description, and domain on demand. For a growth engineer this is the token-efficient way to read the long-form sources that inform an experiment: a competitor's launch blog post, a teardown of a funnel that converts, a benchmark report, a case study. When you are batching through a dozen articles to find the one tactic worth testing, the savings from stripping each page to its content add up, and the metadata extraction is handy for building a quick index of sources by title and domain. It is a deliberately lean complement to the firecrawl tools — reach for it when the page is a standard article and you just want the readable text fast.
When to use: reading any standard web page — a blog post, a case study, a docs page, a market report — where you want the content without the clutter and without burning tokens on nav and ads. Use it instead of a raw fetch for article-shaped pages, and use firecrawl-scrape instead when the page is a JS-rendered app or you need many URLs at once.
Also from gstack. It establishes baselines for page load times, Core Web Vitals, and resource sizes, then compares before-and-after on every change and tracks the trend over time. For a growth engineer this is the conversion guardrail nobody thinks to install until a variant tanks for no obvious reason. Page speed is a conversion lever in its own right — a variant that adds a heavier hero image, a third-party script, or an extra round trip can lose on the metric not because the idea was wrong but because it got slower, and a naive A/B readout will blame the copy. Baselining Core Web Vitals and bundle size on every change means a regression shows up as a number in the diff instead of an unexplained dip in the funnel three days later. The cleanest experiments isolate one variable; this is how you keep load time from secretly being the second one.
When to use: before and after any change to a page you are testing, and especially before you trust a negative A/B result — check whether the losing variant simply got slower. Track the trend so a slow creep in bundle size does not quietly erode conversion across many small ships. Pair it with the devops-engineers skill stack when the regression traces back to the build or the CDN rather than the page itself.
Also from gstack. After a deploy it watches the live app for console errors, performance regressions, and page failures, takes periodic screenshots, compares them against pre-deploy baselines, and alerts on anomalies. For a growth engineer shipping experiments straight to production, this is the safety net that lets you ship fast without shipping blind. A growth variant is a live change to a real funnel, and a broken experiment does worse than fail to win — it actively bleeds the metric for every user bucketed into it until someone notices. Watching the deploy for console errors and page failures, and diffing screenshots against the known-good baseline, turns "the variant silently 500s on Safari" into an alert in minutes instead of a mystery you find in the weekly funnel review. The faster you ship experiments, the more you need something watching what you just shipped.
When to use: immediately after every experiment deploy, especially a variant that touches checkout, signup, or any high-traffic funnel step. Let it baseline the pre-deploy state and alert on the anomaly so a broken bucket gets caught while the test is still young, not after it has polluted a week of data.
Also from gstack. It is a persistent store of what the project has learned across sessions, with commands to review, search, prune, and export it, plus a proactive nudge when you ask about a past pattern or wonder "didn't we already try this?" For a growth engineer this is the experiment log that actually gets read, because it is searched from inside the same tool running the work rather than buried in a doc nobody opens. A growth team generates a relentless stream of hard-won findings — this headline beat that one, the annual-default toggle lifted conversion but hurt refunds, that onboarding step was pure drop-off, this audience never responded to urgency framing — and the recurring waste is re-running a test whose answer is already in someone's old Slack thread. A searchable findings store is the cheapest defense against burning a sprint re-proving a result you already have.
When to use: write a learning every time an experiment ships a conclusive result — win, loss, or null — and search it before you scope a new test so you do not re-run an experiment the team already settled. Prune on a cadence so a result from an old funnel version does not mislead a current decision. Pair it with the data-analysts skill stack when a finding is really a metric trend worth charting rather than a single fact.
How to install
Five of the eight skills live in the gstack plugin (104,138 stars on garrytan/gstack, MIT, verified — the largest and most active plugin in the index), three in cli (425 stars, verified, by Firecrawl), and one in obsidian-skills (33,445 stars, MIT, verified, by kepano), so install is a three-marketplace operation, and Skill Index has the exact install command on each skill detail page with a copy button. The highest-ROI sequence for a growth workflow: gather the market context first — scrape competitor pricing and funnel pages into clean JSON, set a firecrawl-monitor on the URLs you would otherwise re-check by hand, and use firecrawl-map to find the exact page before you pull it with firecrawl-scrape or read it cheaply with defuddle. Then protect the experiment itself: benchmark the page before and after so a slow variant does not masquerade as a bad idea, and canary the deploy so a broken bucket gets caught while the test is young. Finally, write every conclusive result into learn so next quarter starts from what you proved instead of re-running it. For the market signals that feed the top of that loop, pull live category interest from trends.thicket.sh, and bracket the deep instrumentation sessions with focused blocks via focus.thicket.sh — and the work stops being a string of one-off guesses and starts being a measured, compounding experimentation program.