PostHog Growth Workspace
Contribute within authority. The active workspace contract and current task scope decide whether a run may modify this skill, open an upstream pull request, or record portable growth-tooling friction. When authorized, fix the canonical source and use its normal release flow. When upstream maintenance is not authorized, leave the skill untouched; if the normal .growth/log.md handoff is already in scope, record concrete, non-duplicate friction there. Invoking this skill never implies product-development scope.
Run a durable growth operating workspace on top of a product's live PostHog data. The goal is not advice; it is evidence from real events, one verified action per pass, and continuity between sessions.
Use this skill as a mode router. Load only the reference the selected mode needs.
Ground Rules
- Every claim about the product cites live PostHog data (a query, insight, or replay), never intuition. If the data disproves the hypothesis, that is the finding.
- PostHog access is CLI/REST only:
scripts/pg-query.mjs (HogQL + raw API) or posthog-cli. Auth comes from the environment (POSTHOG_PERSONAL_API_KEY); never print keys.
- Keep one current focus ticket at a time; task lists live only in
.growth/backlog.md.
- Evidence goes to
.growth/audit.md, decisions to .growth/strategy.md, handoffs to .growth/log.md, dated reviews to .growth/reports/.
- Registries are rewritten in place, never forked: dashboards in
dashboards.md, experiments in experiments.md, campaigns in campaigns.md.
Boundaries
Three-way contract — respect it in both directions:
- Install doctrine (SDK wiring, proxy, identify, consent, keys, provisioning) belongs to the consuming stack's doctrine — for the Andes fleet,
andes-stack references/analytics-posthog.md. This skill audits install health from the data side only (references/platform-ops.md) and never edits product-repo instrumentation.
- This skill owns everything done with the data: dashboards and insights (creation + audit), funnels, experiments, replay mining, campaign plays, growth reviews.
- Search-channel growth (keywords, content, Search Console, AI-search visibility, SEO-page CTAs) belongs to
seo-growth-workspace. references/campaigns/channels.md excludes organic search and points there.
- The Organic Outcome Bridge is the narrow handoff between them: this skill produces aggregate landing-page outcomes from PostHog;
seo-growth-workspace joins them to aggregate Search Console page demand. It never joins queries to people, sessions, or CRM identities (references/organic-search-outcomes.md).
Required Workspace
Create or verify at GROWTH_WORKSPACE (see Install Modes), copying skeletons from templates/workspace/:
.growth/
README.md # what this workspace is, for the next agent
context.md # product, ICP, funnel, north-star + primary conversion event
backlog.md # prioritized growth tickets, one current focus
log.md # session handoffs
strategy.md # durable decisions, tooling, PostHog project id
audit.md # evidence: live data findings
dashboards.md # PostHog dashboards/insights inventory (names, ids, URLs)
experiments.md # hypothesis → flag → verdict registry
campaigns.md # campaign plays + outcomes
reports/ # dated growth reviews
Install Modes
Hub mode is stamped in the hub's .growth/config.json ({"mode": "hub"}); standalone is inferred by its absence — light machinery, create-if-missing, no migration tooling:
- standalone — a product repo; GROWTH_WORKSPACE is repo-local
.growth/.
- hub — an orchestrator repo managing many products; the hub's
.growth/ holds config.json, registry.md (slug → product, repo, PostHog project id, last review), and one workspace per product under .growth/products/<slug>/. Resolve the target product from registry.md before any work.
Choose A Mode
Pick the narrowest mode that satisfies the request; default to operate.
| Mode |
Use when |
Exit criteria |
operate |
Continuing growth work without a narrower request |
State read, one evidence-backed action completed and verified in live PostHog data, log.md handoff written |
bootstrap |
Starting a workspace |
.growth/ exists, context.md names ICP + north star + primary conversion event, the Product Overview baseline dashboard exists and is registered (references/dashboard-baseline.md), first audit and backlog rows exist |
experiment |
Testing a hypothesis with a flag/experiment |
Hypothesis, flag, and success metric registered in experiments.md; experiment launched or verdict recorded |
replay-mining |
Extracting friction from session replays |
Replays reviewed, friction findings with replay links in audit.md, at least one backlog row filed or explicitly ruled out |
campaign |
Running a marketing/sales play |
One playbook from references/campaigns/ executed against the real product, outcome row in campaigns.md |
growth-review |
Periodic review (monthly per product; hub-batched; manually triggered — scheduling it is the operating profile's decision, not this skill's) |
Dated report in reports/ with metric deltas, experiment verdicts, and the single next action; hub runs also stamp each product's last-review date in registry.md |
operate reads state in this order: backlog.md → log.md → audit.md → strategy.md → latest reports/* → context.md. If .growth/ is missing, run bootstrap first. If no ticket is ready, pick the smallest checkpoint from the funnel: install health (references/platform-ops.md) → activation/retention (references/funnels-activation-retention.md) → replay friction → experiment pipeline → campaign pipeline. Log the evidence even when everything is healthy.
Data Access
scripts/pg-query.mjs runs HogQL (--project <id> --hogql "…") and raw API reads (--get /api/projects/<id>/…). Recurring queries live in references/data-cookbook.md — start there before writing a query from scratch; route a recurring query through that reference's contribution boundary.
Progressive References
- Install-health audit from the data side:
references/platform-ops.md
- Day-one dashboard baseline (spec + creation recipe):
references/dashboard-baseline.md
- Funnels, activation, retention method:
references/funnels-activation-retention.md
- Experiment method and registry discipline:
references/experiments.md
- Session-replay mining:
references/replay-mining.md
- HogQL cookbook:
references/data-cookbook.md
- Organic-search landing-page outcome export for SEO/marketing/sales:
references/organic-search-outcomes.md
- Self-driving / scouts (capability doc; adoption is a fleet-doctrine decision, not this skill's):
references/scouts-self-driving.md
- Marketing-budget framework:
references/budget-framework.md
- Campaign playbooks:
references/campaigns/positioning.md, launch.md, channels.md, pricing.md, sales.md
1---2name: posthog-growth-workspace3description: Use when operating data-driven growth for a product instrumented with PostHog — funnels, activation, retention, experiments, session-replay mining, campaign plays, and periodic growth reviews. Triggers: "growth review", "why aren't users activating", "run an experiment", "mine session replays", "what does the product data say", "set up the growth workspace", "monthly growth report". Creates a durable .growth workspace per product, reads live PostHog data CLI-first, does one verified high-leverage action per pass, and logs handoffs. Installs in a single product repo (standalone) or in an orchestrator/agent-profile repo managing many products (hub). Install/instrumentation doctrine and SEO/search-channel work belong to other skills.4license: MIT5---67# PostHog Growth Workspace89> **Contribute within authority.** The active workspace contract and current task scope decide whether a run may modify this skill, open an upstream pull request, or record portable growth-tooling friction. When authorized, fix the canonical source and use its normal release flow. When upstream maintenance is not authorized, leave the skill untouched; if the normal `.growth/log.md` handoff is already in scope, record concrete, non-duplicate friction there. Invoking this skill never implies product-development scope.1011Run a durable growth operating workspace on top of a product's live PostHog data. The goal is not advice; it is evidence from real events, one verified action per pass, and continuity between sessions.1213Use this skill as a mode router. Load only the reference the selected mode needs.1415## Ground Rules1617- Every claim about the product cites live PostHog data (a query, insight, or replay), never intuition. If the data disproves the hypothesis, that is the finding.18- PostHog access is CLI/REST only: `scripts/pg-query.mjs` (HogQL + raw API) or `posthog-cli`. Auth comes from the environment (`POSTHOG_PERSONAL_API_KEY`); never print keys.19- Keep one current focus ticket at a time; task lists live only in `.growth/backlog.md`.20- Evidence goes to `.growth/audit.md`, decisions to `.growth/strategy.md`, handoffs to `.growth/log.md`, dated reviews to `.growth/reports/`.21- Registries are rewritten in place, never forked: dashboards in `dashboards.md`, experiments in `experiments.md`, campaigns in `campaigns.md`.2223## Boundaries2425Three-way contract — respect it in both directions:2627- **Install doctrine** (SDK wiring, proxy, identify, consent, keys, provisioning) belongs to the consuming stack's doctrine — for the Andes fleet, `andes-stack` `references/analytics-posthog.md`. This skill audits install health *from the data side* only (`references/platform-ops.md`) and never edits product-repo instrumentation.28- **This skill** owns everything done *with* the data: dashboards and insights (creation + audit), funnels, experiments, replay mining, campaign plays, growth reviews.29- **Search-channel growth** (keywords, content, Search Console, AI-search visibility, SEO-page CTAs) belongs to `seo-growth-workspace`. `references/campaigns/channels.md` excludes organic search and points there.30- **The Organic Outcome Bridge** is the narrow handoff between them: this skill produces aggregate landing-page outcomes from PostHog; `seo-growth-workspace` joins them to aggregate Search Console page demand. It never joins queries to people, sessions, or CRM identities (`references/organic-search-outcomes.md`).3132## Required Workspace3334Create or verify at GROWTH_WORKSPACE (see Install Modes), copying skeletons from `templates/workspace/`:3536```text37.growth/38 README.md # what this workspace is, for the next agent39 context.md # product, ICP, funnel, north-star + primary conversion event40 backlog.md # prioritized growth tickets, one current focus41 log.md # session handoffs42 strategy.md # durable decisions, tooling, PostHog project id43 audit.md # evidence: live data findings44 dashboards.md # PostHog dashboards/insights inventory (names, ids, URLs)45 experiments.md # hypothesis → flag → verdict registry46 campaigns.md # campaign plays + outcomes47 reports/ # dated growth reviews48```4950## Install Modes5152Hub mode is stamped in the hub's `.growth/config.json` (`{"mode": "hub"}`); standalone is inferred by its absence — light machinery, create-if-missing, no migration tooling:5354- **standalone** — a product repo; GROWTH_WORKSPACE is repo-local `.growth/`.55- **hub** — an orchestrator repo managing many products; the hub's `.growth/` holds `config.json`, `registry.md` (slug → product, repo, PostHog project id, last review), and one workspace per product under `.growth/products/<slug>/`. Resolve the target product from `registry.md` before any work.5657## Choose A Mode5859Pick the narrowest mode that satisfies the request; default to `operate`.6061| Mode | Use when | Exit criteria |62| --- | --- | --- |63| `operate` | Continuing growth work without a narrower request | State read, one evidence-backed action completed and verified in live PostHog data, `log.md` handoff written |64| `bootstrap` | Starting a workspace | `.growth/` exists, `context.md` names ICP + north star + primary conversion event, the Product Overview baseline dashboard exists and is registered (`references/dashboard-baseline.md`), first audit and backlog rows exist |65| `experiment` | Testing a hypothesis with a flag/experiment | Hypothesis, flag, and success metric registered in `experiments.md`; experiment launched or verdict recorded |66| `replay-mining` | Extracting friction from session replays | Replays reviewed, friction findings with replay links in `audit.md`, at least one backlog row filed or explicitly ruled out |67| `campaign` | Running a marketing/sales play | One playbook from `references/campaigns/` executed against the real product, outcome row in `campaigns.md` |68| `growth-review` | Periodic review (monthly per product; hub-batched; manually triggered — scheduling it is the operating profile's decision, not this skill's) | Dated report in `reports/` with metric deltas, experiment verdicts, and the single next action; hub runs also stamp each product's last-review date in `registry.md` |6970`operate` reads state in this order: `backlog.md` → `log.md` → `audit.md` → `strategy.md` → latest `reports/*` → `context.md`. If `.growth/` is missing, run `bootstrap` first. If no ticket is ready, pick the smallest checkpoint from the funnel: install health (`references/platform-ops.md`) → activation/retention (`references/funnels-activation-retention.md`) → replay friction → experiment pipeline → campaign pipeline. Log the evidence even when everything is healthy.7172## Data Access7374`scripts/pg-query.mjs` runs HogQL (`--project <id> --hogql "…"`) and raw API reads (`--get /api/projects/<id>/…`). Recurring queries live in `references/data-cookbook.md` — start there before writing a query from scratch; route a recurring query through that reference's contribution boundary.7576## Progressive References7778- Install-health audit from the data side: `references/platform-ops.md`79- Day-one dashboard baseline (spec + creation recipe): `references/dashboard-baseline.md`80- Funnels, activation, retention method: `references/funnels-activation-retention.md`81- Experiment method and registry discipline: `references/experiments.md`82- Session-replay mining: `references/replay-mining.md`83- HogQL cookbook: `references/data-cookbook.md`84- Organic-search landing-page outcome export for SEO/marketing/sales: `references/organic-search-outcomes.md`85- Self-driving / scouts (capability doc; adoption is a fleet-doctrine decision, not this skill's): `references/scouts-self-driving.md`86- Marketing-budget framework: `references/budget-framework.md`87- Campaign playbooks: `references/campaigns/positioning.md`, `launch.md`, `channels.md`, `pricing.md`, `sales.md`
jorgemenadev