@twentylabs/ai-os-registry 1.0.0

package/skills/app-store-compliance/references/review-checklist.md

@@ -0,0 +1,46 @@
+# Review checklist
+
+Check what applies; report only applicable findings. Locate each item at the paths the store-review knowledge file records for this stack (native project, cross-platform config, plugin-generated manifests).
+
+## Privacy and data
+- Every data type collected, by the app and by each SDK, is declared in the store's privacy disclosure (App Store privacy labels, Google Play Data safety).
+- iOS privacy manifest present where the app or its SDKs use required-reason APIs; tracking declared and the tracking-permission prompt shown before any tracking.
+- A privacy policy is linked in the listing and reachable in the app.
+- No device fingerprinting; identifiers used only as declared.
+
+## Permissions
+- Every permission the build requests (including those added by plugins) has a specific purpose string — not "needs camera".
+- Permissions are requested in context, after the user understands why, not all at launch.
+- Android: only permissions the app uses; sensitive ones (background location, SMS, call log, all-files access, exact alarms, accessibility) have an approved use case and declaration.
+
+## Purchases and subscriptions
+- Digital goods and features are sold through the store's billing system; no links or prompts to pay elsewhere unless a current, applicable entitlement allows it.
+- The paywall states price, billing period, renewal, trial length and what happens after the trial.
+- Restore purchases is visible and works; entitlements are validated (preferably on the server) and survive reinstall.
+- Nothing labelled "free" requires payment for its core function.
+
+## Accounts and sign-in
+- If an account is required, the app explains why, and the reviewer has a working demo account or demo mode.
+- If accounts can be created, they can be deleted from inside the app, and deletion really deletes (or the retention is explained).
+- iOS: offering third-party social sign-in requires an equivalent privacy-preserving option such as Sign in with Apple; token revocation on deletion where applicable.
+
+## Content and safety
+- User-generated content has filtering, reporting, blocking, published contact information and an effective removal path.
+- Medical, financial, safety and other regulated claims are framed and substantiated.
+- Age rating answers match the actual content.
+- Messaging features (push, live activities, notifications) are not used for unsolicited promotion without consent and an off switch.
+
+## Technical quality
+- No crash on launch or on the main paths; network errors and offline states are handled.
+- No placeholder screens, dead ends or "coming soon" features in the build under review.
+- Minimum OS and target API levels meet the store's current requirements (Google Play enforces a target SDK floor).
+
+## Reviewability
+- The core value is reachable without special setup, or the review notes explain the setup.
+- Review notes cover: steps to key features, account placeholders, unusual permissions, how to test purchases, any hardware or region dependency.
+
+## Severity
+- **P0** — very likely rejection, or the app does not work for the reviewer.
+- **P1** — a common rejection reason or serious reviewer friction.
+- **P2** — risky pattern or unclear compliance.
+- **P3** — polish.

package/skills/app-store-compliance/references/update-eligibility.md

@@ -0,0 +1,23 @@
+# Over-the-air update eligibility
+
+For each item headed for an over-the-air update (a code-push, a hot patch, a remotely loaded bundle), decide one of: **update-safe**, **store build required**, or **unclear** — with the reason.
+
+## Store build required
+- A new screen, tab or feature, or a feature turned on that the reviewed build did not offer.
+- A change to the app's primary purpose or how it is presented.
+- New data collection, new tracking, or new sharing of data with a third party.
+- New permissions, entitlements, SDKs or native code.
+- Changes to purchase flows, prices shown, or what a plan includes.
+- Anything that changes the answers in the store's privacy disclosure or age rating.
+
+## Usually update-safe
+- Bug fixes that restore reviewed behaviour.
+- Copy and translation fixes that do not change claims.
+- Performance improvements.
+- Content updates of the kind the reviewed build was designed to load.
+
+## Unclear — escalate to the owner
+- Feature flags that reveal code present in the reviewed build but hidden at review time.
+- Remote configuration that changes paywall behaviour or limits.
+
+Measure each item against the project's own update policy (recorded in the store-review knowledge file) and both stores' rules on downloaded executable code. When the project's policy is stricter, it wins.

package/skills/app-store-compliance/skill.yaml

@@ -0,0 +1,9 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: app-store-compliance
+spec:
+  capabilities: [ store-compliance, quality-assurance ]
+  domains: [ mobile-app ]
+  requiredKnowledge:
+    - store-review

package/skills/aso/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: aso
+spec:
+  capabilities: [ app-store-optimization ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/aso
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-314414f430ca07494fd771bc24828ec5d1da79f643f0ee7b9f0d2004111da080
+    license: MIT
+  description: When the user wants to audit or optimize an App Store or Google Play listing.

package/skills/aso-ops/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: aso-ops
+description: "Use when auditing, changing or reading the results of an App Store or Google Play listing — title, subtitle, keywords, descriptions, screenshots, preview video, listing experiments, ratings prompts. Keeps the live listing and a changelog in the repository. NOT for paid ads (ads-review) or in-app copy."
+---
+
+# Store listing operations
+
+The store keeps the numbers (impressions, product page views, conversion to install); the repository keeps **the copy that is live and the reason for every change**. Never change a listing without a changelog line, and never change two things at once on the same store — the result would be unreadable.
+
+This skill has no access to store consoles and never signs in. It edits the repository's copy of the listing and the owner pastes the change into the console. If the project enabled the external `aso` skill, use it for the audit checklist; this skill runs the loop around it.
+
+## Repository layout — `aso/`
+
+| Path | What it is |
+| --- | --- |
+| `appstore/<locale>.md` | title, subtitle, keywords, promotional text, description — **as live** |
+| `play/<locale>.md` | title, short description, full description — **as live** |
+| `screenshots/README.md` | order, caption and reason for each screenshot; sources in the assets folder |
+| `changelog.md` | date · store · field · before → after · reason · readout date |
+| `experiments.md` | listing experiments: hypothesis, variable, start date, result |
+| `audits/ASO_YYYY-MM-DD.md` | dated audits |
+
+## Three modes
+
+**audit** — If the live listing is not yet in the repository, capture it first: the repository must reflect what runs before anything is proposed. Some fields can be fetched from public pages; others (keywords, subtitle, promotional text, short description, screenshot captions) exist only in the console — ask the owner to copy them and record which fields were hand-copied and when. An empty changelog means "never audited", not "nothing to do". **Mandatory step: put the same field from both stores side by side** — a language or positioning mismatch between stores is a finding that per-store review never sees. A read-only audit is answered in chat; write the file when the owner wants to keep it.
+
+**change** — one field at a time. Edit the live file, add the changelog line with its reason and a readout date at least 14 days out, and hand the new text to the owner to paste. Field rules: [field rules](references/field-rules.md).
+
+**review** — on the readout date, compare conversion to install for the 14 days before and after, split by source (search, browse, referrals). Record the result on the changelog line. A difference under about one percentage point on a few hundred page views is noise — write "not yet readable", not "no effect".
+
+## Experiments
+
+Use the stores' native experiments (Play store listing experiments; App Store product page optimization) — one variable per experiment, logged in `experiments.md`. Custom product pages can be matched to ad keywords or audiences; coordinate with ads-review.
+
+## Ratings
+
+Ask for a rating in the product **after a moment of achievement**, never after an error, at most once per platform-recommended interval. If the product has no prompt, open an issue in the code repository — ratings volume is a ranking factor and social proof.
+
+## Not this skill
+
+Paid ads (ads-review), landing pages (conversion-audit), in-app copy (designer).

package/skills/aso-ops/references/field-rules.md

@@ -0,0 +1,15 @@
+# Field rules
+
+| Field | Rule |
+| --- | --- |
+| Title and subtitle (App Store) | Do not repeat words across the two — each word is indexed once. Lead with the category term people search for. |
+| Keywords (App Store, 100 characters) | No words already in title or subtitle; commas without spaces; no competitor brand names; singular or plural, not both. |
+| Promotional text (App Store) | Not indexed; use it for timely messages — it can change without a new build. |
+| Short description (Play, 80 characters) | Use all of it; include a commercial keyword; no slogans. |
+| Full description (Play, 4000 characters) | The field Play indexes most strongly. Describe only features that exist in the current release; repeat the main terms naturally. |
+| Screenshots | The first one states the outcome, never a login screen. Captions carry the words people search for (App Store indexes caption text). Show the real product. |
+| Preview video | First seconds show the core action; it autoplays muted, so it must read without sound. |
+| Age rating | Review the questionnaire before changing anything that touches it; a higher rating hides the app from filtered audiences. |
+| Localization | The primary market's language is complete in both stores before secondary languages are polished. |
+
+Every claim in a listing must be true of the current release; check the offer catalog and brand voice for what may be promised.

package/skills/aso-ops/skill.yaml

@@ -0,0 +1,7 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: aso-ops
+spec:
+  capabilities: [app-store-optimization]
+  domains: [mobile-app]

package/skills/attribution/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: attribution
+spec:
+  capabilities: [ measurement, growth-analytics ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/attribution
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-6a10ba3a3211b3855919a318c4c86bc5d38c9719a8fd1aa94841b3fabed944d6
+    license: MIT
+  description: When the user wants to figure out which marketing actually drives conversions and revenue, choose or interpret an attribution model, or reconcile conflicting numbers across tools.

package/skills/churn-prevention/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: churn-prevention
+spec:
+  capabilities: [ lifecycle-marketing ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/churn-prevention
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-1f31620b1dd963e4e5f05e1b679728fcafd27ee94e9e15fff7e873a024400fef
+    license: MIT
+  description: When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies.

package/skills/co-marketing/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: co-marketing
+spec:
+  capabilities: [ partnerships ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/co-marketing
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-df6eaf0ca1188c6aff00b9565f39b544dd28ecb670116feaba4207a21890625c
+    license: MIT
+  description: When the user wants to find co-marketing partners, plan joint campaigns, or brainstorm partnership opportunities.

package/skills/cold-email/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: cold-email
+spec:
+  capabilities: [ outreach, email-marketing ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/cold-email
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-f01ed70cd8b0692f035d46c2e32e0b7c12f2ecebd11462edfa37a237fca02b07
+    license: MIT
+  description: Write B2B cold emails and follow-up sequences that get replies. Use when the user wants to write cold outreach emails, prospecting emails, cold email campaigns, sales development emails, or SDR emails.

package/skills/community-marketing/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: community-marketing
+spec:
+  capabilities: [ community ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/community-marketing
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-f2bd696508760504056a765c412d5a6e92ed7bf825bb3f14e3f42734a7e11c74
+    license: MIT
+  description: Build and leverage online communities to drive product growth and brand loyalty.

package/skills/competitor-profiling/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: competitor-profiling
+spec:
+  capabilities: [ competitive-analysis ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/competitor-profiling
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-c909983201a9a87721dfcec6191b8f540dfade9103feac8e2a1e3034467f50d9
+    license: MIT
+  description: When the user wants to research, profile, or analyze competitors from their URLs.

package/skills/competitors/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: competitors
+spec:
+  capabilities: [ competitive-analysis, seo ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/competitors
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-abbddb9ee2abc27960ac74d0ad74b6ca30a0166dbd2aff451b5e7da8aaa1c2b4
+    license: MIT
+  description: When the user wants to create competitor comparison or alternative pages for SEO and buyer-facing use.

package/skills/content-pipeline/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: content-pipeline
+description: "Use when producing or scheduling organic content — short video, social posts, long-form — from hook bank to script to publishing queue to weekly review, with a measurable link per piece. NOT for paid ad creatives (ads-review) or partner outreach (partner-outreach)."
+---
+
+# Content pipeline
+
+From hook to publishing queue, with a measurable link on every piece. Organic content is the cheapest early channel and the one that reveals **which message** the audience responds to before money is spent amplifying it. So every piece (1) ties to a real feature, (2) carries its own measurable link, and (3) is recorded with its hook and result so the hook bank grows from evidence.
+
+If the project enabled external skills such as `social`, `video` or `content-strategy`, use them for the craft; this skill runs the pipeline.
+
+## Repository layout — `content/`
+
+| Path | What it is |
+| --- | --- |
+| `hooks.md` | hook bank: hook · angle · feature · platform · results once published |
+| `angles.md` | the content angles, each tied to a real feature and why it fits the audience |
+| `scripts/YYYY-MM-DD-<slug>.md` | script: hook · body · call to action · caption · tags · link |
+| `queue.md` | publishing queue: date · platform · script · link · status |
+| `reviews/YYYY-MM-DD.md` | weekly review: top and bottom pieces by views and by attributed signups or installs |
+
+## Angles
+
+Keep three to five angles, each tied to a feature the current release really has, with the reason it resonates with the audience (from the audience file). Before writing, check the release's real capabilities and feature flags, and the brand voice's allowed and forbidden claims: content may promise only what the current build does. Demo footage uses the real product and a demo account, on a build where the feature works — one frame is a promise.
+
+## Weekly loop
+
+1. **ideas** — new hooks into the hook bank, each on one angle. A hook states an outcome or a mistake in the first seconds and does not lead with the product name.
+2. **script** — choose a few; write short scripts: hook, one idea, the real product on screen, one call to action. Caption in the project's locale, a handful of relevant tags.
+3. **link** — every script gets its own tracking link (deferred deep link or UTM-tagged link with a campaign parameter equal to the slug), placed where the platform allows (bio, pinned comment, description). Never link straight to the store or homepage: the result lands in "organic" and teaches nothing.
+4. **queue** — add to `queue.md` at a fixed, sustainable cadence. If a scheduler exists, the queue is its input; its dry run is reviewed before anything publishes.
+5. **review** — weekly: views, early retention, link clicks, signups or installs per campaign parameter. Record results in the hook bank. A hook at two times the median or more earns two variants; one under half the median retires its angle for a month.
+
+## Rules
+
+- At least one piece per week sells nothing — a tip that stands on its own.
+- "What is this?" comments are buying signals: answer with the tracked link and note them in the review.
+- Never publish on the owner's behalf until a scheduler exists and the owner approves each piece.
+- Results are reported down to signups or installs, never views alone.

package/skills/content-pipeline/skill.yaml

@@ -0,0 +1,6 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: content-pipeline
+spec:
+  capabilities: [content-marketing, copywriting]

package/skills/content-strategy/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: content-strategy
+spec:
+  capabilities: [ content-marketing ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/content-strategy
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-4babb09488da1425367c1ce29a1f07a82d7980331177e74ed7307b08e5b08c1d
+    license: MIT
+  description: When the user wants to plan a content strategy, decide what content to create, or figure out what topics to cover.

package/skills/conversion-audit/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: conversion-audit
+description: "Use when auditing why a product does not convert — users not activating or paying, what to limit or gate, when the paywall should fire, which bugs cost money — or walking the journey before launch or ads. Produces a ranked, read-only diagnosis with one decided fix. NOT for a single metric question or building the fix."
+---
+
+# Conversion audit
+
+Find where the product loses users and money, decide what to do about it, and defend each recommendation with evidence. The value is the diagnosis: this skill never writes product code, not even a throwaway script. The only file it creates is the report. Production is read-only — query, never write, and never print a secret.
+
+## Pick the mode
+
+| Situation | Mode | Evidence |
+| --- | --- | --- |
+| Real users pass through the funnel (roughly 50+ per step in the window) | **Data mode** — walk the value chain with numbers | code, data, users' own signals |
+| No users yet, before launch or ads, or a flow just changed | **Journey mode** — walk the stations as a new user | code, the running product, external config |
+
+Most audits of a young product are journey mode with a little data. Say which mode you are in and why.
+
+## Before anything: priors
+
+Read the prior-findings and domain-playbook knowledge files if the project has them, the most recent previous audit (beat its baselines instead of rediscovering them), and what shipped lately — usually what moved the numbers. A decision recorded with its reason goes under "deliberate — don't fix", not under findings.
+
+## Scope the ask
+
+| The ask | Lead with | But still do |
+| --- | --- | --- |
+| "how do we get people to pay" | gating and paywall placement | the value chain — the answer is usually upstream |
+| "when should the paywall show" | trigger reachability and timing | check nothing fires before activation |
+| "which limits should change" | gating design | read prior findings on gating first |
+| "which bugs matter" | bug triage by money | rank by chain position, not crash volume |
+| "audit the product" | the whole chain | everything |
+
+Push back on exactly one framing: optimizing the paywall when users never reach it. Say so in a sentence, then deliver the requested analysis anyway, plus the upstream finding.
+
+## Data mode
+
+1. **Ground truth from code and live config** — what each plan actually gets (live tables, not constants), every paywall trigger and whether it is reachable, what is enforced on the server versus only displayed, what is deliberately disabled.
+2. **The numbers** — users not events, test accounts filtered, dual-emitted events swept before any total, zeros checked against never-fired lists, small-N rates labeled hypotheses.
+3. **Walk the value chain** ([funnel playbook](references/funnel-playbook.md) §1). Report both readings of "weakest": the step losing the most users absolutely and the step with the lowest pass-through. Name the steps you cannot measure — a blind spot is a finding, often the cheapest. Split the weakest step by at least one segment.
+4. **Interrogate each dimension** — gating, paywall timing, content or supply, bugs by money (playbook §3–§7). Parallel subagents are fine if each is briefed read-only, counts users, and returns claim · evidence · users per week · confidence.
+5. **Users' own signals** — replays (watched by humans), support threads, reviews, and walking the flow yourself as a new free user. Two independent signals on one screen is a finding; one is a hypothesis.
+
+## Journey mode
+
+Walk every station in [the journey stations](references/journey-stations.md), from the store listing to the first renewal, as a new user. Every station gets a row in the report, including stations where nothing was found. Use all three evidence sources at each station: **code** (file and line), **the running product** (a screenshot per station), and **external config** (store listing, billing offerings, remote config). A station missing a source is capped at 3 of 5 and marked unconfirmed; if the product cannot be run, say "code only" for that station rather than skipping it silently.
+
+At every station also check measurement: an event the project's analytics plan lists that does not fire, or fires without the property needed to segment it, is a finding — it would leave that step blind once users arrive.
+
+## Decide
+
+Rank by expected value over effort, value in users per week or revenue per month, not adjectives. **Pick one top recommendation** — twelve unranked ideas is a way of making no decision — and state how you will know it worked. Fill "deliberately not recommended": rejecting obvious-looking ideas with reasons is what makes the rest credible. If the honest conclusion is "instrument X first", say that; never invent a finding to look useful.
+
+## Write it up
+
+Use [the report template](references/report-template.md), saved as `docs/audits/<YYYY-MM-DD>-conversion-audit.md` (or the project's reviews folder if it has one). Chat gets the one thing, the weakest step and the finding count. Each product change becomes a proposed issue for the code repository, with its evidence and how it will be measured — opened only after the owner agrees. Correct prior findings where this audit proved them wrong.
+
+## The quality bar
+
+| Weak | Strong |
+| --- | --- |
+| Percentages with no denominator | "37% (3 of 8) — hypothesis, small N" |
+| A limit quoted from a document | The live row, with the date read |
+| Twelve findings, unranked | One decided fix, the rest sequenced, the deciding metric named |
+| Silent about what could not be measured | A blind-spots section with the cheapest fix for each |
+| An average | The weakest step split by segment |
+
+The subtlest failure is mistaking measurable for important. The instrumented parts of the funnel are the parts someone already thought about; the biggest leaks usually live in the unmeasured steps.

package/skills/conversion-audit/references/funnel-playbook.md

@@ -0,0 +1,80 @@
+# Funnel playbook
+
+Portable reasoning for a product that converts free users to paying ones. The category- and market-specific half lives in the project's domain-playbook knowledge file; where the two disagree, the domain playbook wins — it was written closer to the ground.
+
+## 1. The value chain, in order
+
+```
+first contact → account → activation (first real value delivered)
+→ habit (returns unprompted) → limit felt → paywall seen with a reason
+→ purchase → renewal
+```
+
+- **Fixing a step only helps users who reach it.** Paywall polish is worthless to users who never activated. Find the earliest step losing the most users per week.
+- **Activation is delivering the core value once**, not completing signup. Proxies (a session opened, a screen viewed) are named as proxies.
+- **Habit precedes monetization.** A user who has not returned unprompted has nothing to lose at a wall; a limit felt before habit converts nobody and churns somebody.
+- **Renewal is part of the chain** — the cheapest revenue there is.
+
+## 2. Small-N discipline
+
+- Under about 30 users in a denominator, rates are hypotheses; show absolute counts.
+- At small scale one user's week moves weekly lines by double digits; movements inside that band are noise without a mechanism.
+- Structural evidence — a trigger that cannot fire, a step with no instrumentation, a price shown wrong — outranks statistics and is decidable at any N. Prefer it.
+- Natural experiments (a promotion ending, a forced update) beat A/B tests you lack the volume to run.
+
+## 3. Gating
+
+Per limit:
+
+- Is it hit **while wanting more** (engaged, mid-flow) or **while discovering less** (before value)? The first converts; the second churns.
+- Is daily use still possible? A gate that blocks the habit starves the paywall.
+- Is the limit legible before it bites? A visible meter converts; a surprise wall enrages.
+- **Reach before scarcity** — tightening a gate helps only if users reach it. If few do, the problem is upstream.
+- Server-enforced or display-only? A limit only the UI knows about is a suggestion.
+- Consider value sampling — tastes of paid value inside the free flow — before a tighter limit. Free is an acquisition strategy, judged by the activated users it feeds the paywall.
+
+## 4. Paywall timing
+
+- Map every trigger: reason, surface, and whether it can fire **before activation** (if it can, that is a bug).
+- Strong moments: a limit reached mid-flow, a result worth keeping, progress about to be lost, an evident habit on day 2–3. Weak: app open, end of onboarding, random interstitials.
+- **A strong moment with no trigger wired** usually beats any copy change on existing triggers.
+- Every surface emits shown and dismissed events, or its conversion rate is fiction.
+- Per-reason funnel (impression → call to action → purchase) by users. A reason with impressions and no purchases is mistimed, mispriced or mis-targeted — the split says which.
+
+## 5. Unit economics
+
+Where usage has real marginal cost (AI inference, media, messaging):
+
+- Know the monthly cost of one active free user and which feature drives it; watch the 95th percentile, not the mean.
+- The free tier is a cost decision wearing a growth costume — price "more generous free" per user before judging it.
+- Anything that grants the expensive resource (referrals, rewards, promotions) competes with its own paid product; check how much is given away versus sold.
+- Before touching a price point: does the value metric scale with delivered value; is the debate at the right order of magnitude; is "underpricing" really too few tiers for the spread of willingness to pay?
+- Churn ceiling ≈ new users per period ÷ churn rate. If the ceiling is near, the headline belongs to retention, not the paywall.
+
+## 6. Content and supply
+
+When a content-shaped surface underperforms, four diagnoses — only one is answered by producing more:
+
+- **Starvation** — engaged users exhaust what exists. More of the same.
+- **Difficulty cliff** — entry works, the next step loses them. Fill the gap, not the end.
+- **Wrong audience band** — supply aimed above or below the actual users. Re-aim.
+- **Discovery** — the content is fine and unreachable. Surface it.
+
+Count supply from the live store, not the repository: authored and published diverge.
+
+## 7. Bugs by money
+
+Rank by **chain position × users per week × silence**, never by crash volume:
+
+1. The money path first — purchase, restore, renewal, entitlement resolution, discounts, grants. A silent restore failure churns payers who wanted to stay.
+2. Then the activation path — a broken first run loses everyone at the top.
+3. Silent failures outrank loud ones at equal position.
+4. Expired-but-live surfaces (a blocker for a disabled feature, an orphaned route) are bugs even though nothing crashes.
+
+## 8. Segment before you average
+
+Split the weakest step at least once — lifecycle stage, entry path, platform, plan history. A mediocre average is often one healthy segment plus one broken one.
+
+## 9. Qualitative signal
+
+Replays, reviews, support threads and walking the flow yourself carry the most information per minute at small N. Replays show layout and where a thumb went, never content — content questions need events or transcripts within the project's privacy rules.

package/skills/conversion-audit/references/journey-stations.md

@@ -0,0 +1,57 @@
+# Journey stations
+
+Journey mode walks these stations in order as a brand-new user. Adapt the names to the product (a web product's "store listing" is its landing page and search result), but never drop a station — every station is a row in the report.
+
+**Scoring.** Each station's score = round(5 × questions answered "yes" ÷ questions asked). A red-flag sign caps the station at 2. A missing evidence source (code, running product, external config) caps it at 3 and marks it unconfirmed. Two audits with the same evidence must produce the same scores.
+
+At every station also ask: **when real users arrive, will this step be measurable?** Name the event that must exist and check that it fires with the properties needed to segment it.
+
+## 1. Store listing or landing page
+- Do the first three seconds say what the product does, for whom, with one reason to believe?
+- Is the first screenshot or hero an outcome, not a login screen?
+- Is there social proof (ratings volume, reviews) and nothing that contradicts the product?
+- Red flag: the listing describes features that no longer exist, or is not in the audience's language.
+
+## 2. Landing to install or signup
+- One primary call to action?
+- Do campaign parameters survive into the product (tracking links, deferred deep links)?
+- Is web analytics installed, with consent where required?
+- Red flag: no measurement on the page — every ad that lands here is blind.
+
+## 3. First open to account
+- Can value be tasted before an account is demanded?
+- Is the fastest sign-in method first; does email verification have a resend and a way back in?
+- Red flag: a hard wall at sign-in with no taste of value first.
+
+## 4. Onboarding and setup
+- Does each step say why it asks? Can steps be skipped? Does progress never go backwards?
+- Do permission requests come after value, with a fallback when refused?
+- Red flag: an OS permission prompt before anything has been taught or shown; a mandatory step with no exit.
+
+## 5. First session
+- Can the first session not fail? Is it short? Does it end with a concrete achievement and a one-tap next step?
+- Is the first unit of content or work non-empty on the current build?
+- Red flag: the first item opens empty, or the first session can end in failure.
+
+## 6. Day-2 return
+- Is a reason to return planted on day 1 (progress, a goal, a specific promise for tomorrow)?
+- Is notification permission asked after first value; do messages carry personal progress and deep-link to the right screen?
+- Red flag: the same message for everyone, or a tap that goes nowhere.
+
+## 7. Limit reached → paywall
+- Does the free tier let users taste the paid value a few times?
+- Does the paywall appear at a moment of achievement more often than at a moment of frustration?
+- Do users know the paid plan exists before they hit a limit?
+- Red flag: the first time a user meets the paid plan is an error message.
+
+## 8. Paywall → purchase
+- Does the headline state an outcome? Is the free-versus-paid comparison clear; are trial terms and the post-trial price printed?
+- Is the annual plan's saving marked; is there an exit that is visible but not louder than the call to action?
+- If the store or billing returns no products, does someone get alerted?
+- Red flag: no purchasable products in the test environment, or a displayed price that does not match the store.
+
+## 9. After purchase
+- Does the success screen lead straight back into the product?
+- Does subscription management show the renewal date; does cancellation ask why?
+- Are offers, gifts and win-back paths reachable and measured?
+- Red flag: nothing changes in the product after paying.

package/skills/conversion-audit/references/report-template.md

@@ -0,0 +1,60 @@
+# Conversion audit — <YYYY-MM-DD>
+
+Mode: data | journey. Window: <from → to, plus comparison window> (data mode). Volumes: <active users, payers — absolute>. Status: draft | delivered.
+
+## 1. The one thing
+
+The single decided fix: what, why this one first (expected value over effort, in users per week or revenue per month), and how we will know it worked (event or query, threshold, date).
+
+## 2. Where users are lost
+
+Data mode — the value chain:
+
+| Step | Definition used | Users in → out | vs prior window | Confidence |
+| --- | --- | --- | --- | --- |
+| first contact → account | | | | |
+| account → activation | | | | |
+| activation → habit | | | | |
+| habit → limit felt | | | | |
+| limit → paywall seen | | | | |
+| paywall → purchase | | | | |
+| purchase → renewal | | | | |
+
+Journey mode — the stations:
+
+| # | Station | Evidence used (code / product / config) | Score 1–5 | One-line reason |
+| --- | --- | --- | --- | --- |
+
+Unmeasurable steps, each with the cheapest instrumentation that would light it up. The weakest step, split by at least one segment, and the one-sentence conclusion.
+
+## 3. Findings
+
+Ranked. Per finding:
+
+### F<n> — <short imperative title>
+- **Claim:**
+- **Evidence:** file and line, table row with the date read, screenshot, or query — never a document or memory
+- **Users per week or revenue per month affected:**
+- **Confidence:** verified | hypothesis (N=…)
+- **Fix shape and effort:**
+- **How it will be measured:**
+
+## 4. Bugs, ranked by money
+
+Chain position × users per week × silence. The money path (purchase, restore, renewal, entitlement, grants) covered explicitly, even when clean.
+
+## 5. Deliberate — don't fix
+
+Behaviour that looks wrong but was decided on purpose, with where the decision is recorded.
+
+## 6. What I could not determine
+
+Each blind spot, why, and the cheapest way to remove it.
+
+## 7. Deliberately not recommended
+
+Obvious-looking ideas rejected, each with the reason.
+
+## 8. Sequence and proposed issues
+
+Ordered next steps after the one thing, each with its deciding metric. Proposed issues for the code repository (title, evidence, measurement), awaiting the owner's go-ahead.

package/skills/conversion-audit/skill.yaml

@@ -0,0 +1,7 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: conversion-audit
+spec:
+  capabilities: [conversion-optimization, product-analytics]
+  domains: [consumer-subscription, saas]

package/skills/copy-editing/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: copy-editing
+spec:
+  capabilities: [ copywriting ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/copy-editing
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-2d79dc653cc3c758ac33972358c27ae5233e6ab964b24ce60b840831a01691b3
+    license: MIT
+  description: When the user wants to edit, review, or improve existing marketing copy, or refresh outdated content.

package/skills/copywriting/skill.yaml

@@ -0,0 +1,13 @@
+apiVersion: ai-os.twentylabs.dev/v1
+kind: Skill
+metadata:
+  id: copywriting
+spec:
+  capabilities: [ copywriting ]
+  source:
+    github: coreyhaines31/marketingskills
+    path: skills/copywriting
+    ref: dda3841f0b294e01e93b1541486beefbfab0915e
+    hash: sha256-e04e269ca6db314564d8d8760b7955d0f22f2ddb511978e9f64a9b65c30a482c
+    license: MIT
+  description: When the user wants to write, rewrite, or improve marketing copy for any page, including homepage, landing pages, pricing pages, feature pages, about pages, or product pages.