@kensaurus/skills 0.0.0-stage → 2.1.0

package/skills/plan-mobile-readiness/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: plan-mobile-readiness
+description: >
+  Plan-only App Store / Google Play submission audit for Capacitor and React
+  Native: manifests, permissions, privacy forms, signing. Use when "ready for
+  App Store?", "will Google Play reject this?", or "pre-submission check".
+license: MIT
+effort: high
+---
+
+# Mobile Store-Readiness Audit + Pre-Submission Plan
+
+**Degree of freedom: HIGH** — inventory A–E, score rejection risk, emit a plan.
+Stay **plan-only**. No manifest, Data Safety, or listing edits until approved.
+
+## This skill vs neighbors
+
+| Skill | Owns |
+|---|---|
+| **plan-mobile-readiness** (this) | Store submission mechanics |
+| `plan-aso` | Listing keywords / conversion |
+| `plan-privacy-compliance` | Privacy labels vs real collection |
+
+
+**Role:** Senior mobile release engineer + store-compliance specialist.
+
+**Task:** Inventory build/config/listing against checklist A–E, map gaps to store
+guidelines, phase remediations, emit `plan-mobile-readiness.md`. **Audit & plan only —
+no manifest, Data Safety, or listing edits until approved.**
+
+**Catch the rejections before the reviewer does. Change nothing until approved.**
+
+## How to reason (every plan item)
+
+1. **Propose** — privacy manifest, usage string, demo account, build, or listing fix
+2. **Risk** — first-pass rejection or Guideline 2.5.2 thin-app block
+3. **Keep-working** — platforms/items that already match store rules
+4. **Phase** — Privacy → Functionality → Payments+build → Listing (do not execute)
+
+## Worked example
+
+> **Propose:** add `PrivacyInfo.xcprivacy` for required-reason APIs; align Play Data Safety with the AdMob SDK.
+> **Risk:** first-pass rejection — missing privacy manifest + Data Safety ↔ permission mismatch.
+> **Keep-working:** iOS usage-description strings already present for camera/photos.
+> **Phase:** Phase 1 — Privacy (blocking).
+> **Store:** iOS 5.1.2 / Play Data Safety; demo account still required in Phase 2 if login-gated.
+
+About **25% of App Store submissions are rejected on first pass** — mechanical,
+pre-detectable causes: missing privacy manifests, Data Safety ↔ permission mismatches,
+no demo account, placeholder buttons, crashes on older devices, stale target API.
+**Apple blocks prompt-to-app builders under Guideline 2.5.2** — the thin web-view
+rejection vibe-coded apps trip constantly.
+
+---
+
+## When this fires
+
+Trigger phrases: *"is my app store-ready"*, *"will Google Play reject this"*,
+*"pre-submission check"*, *"privacy manifest"*, *"data safety form"*, *"app store
+rejection"*, *"about to submit my app"*.
+
+Do **not** fire for: runtime perf (`mobile-rn-performance`), screen polish
+(`mobile-rn-screen`), or general UI (`enhance-capacitor-ui`). This owns *submission
+compliance and rejection-risk*.
+
+---
+
+## The audit  [HIGH freedom]
+
+### A · Privacy (#1 modern rejection class)
+- **iOS privacy manifest** — `PrivacyInfo.xcprivacy`, required-reason APIs, SDK manifests.
+- **Usage-description strings** — every sensitive API has `NS*UsageDescription`.
+- **App Tracking Transparency** — before ad/tracking SDK calls.
+- **Android Data Safety** — matches actual permissions and SDK collection.
+- **Third-party SDK disclosure** — analytics/ad SDKs in Data Safety.
+- **Privacy policy URL** — live, public, matches collection.
+
+### B · Functionality & completeness (2.5.2 / thin-app)
+- **Placeholder / TODO UI** — cross-hand to `plan-stub-checker`.
+- **Too thin / web-view-only** — Guideline 2.5.2 risk; flag honestly.
+- **Demo account** — login-gated apps need working creds in review notes.
+- **Every advertised feature works.**
+
+### C · Payments
+- **IAP via store billing** — digital goods through StoreKit/Play Billing, not external links.
+- **IAP products approved** and tested with sandbox accounts.
+
+### D · Technical / build
+- **Target API level** — meets current store minimum.
+- **Build format & signing** — `.aab`, release-signed, 64-bit, no debuggable.
+- **Crash on older devices** — emulator-only testing isn't enough.
+- **Android closed-testing gate** — personal developer accounts need a closed test before production (12 testers / 14 days at time of writing); verify the current tester count and duration in Play Console policy at submit time.
+
+### E · Listing & metadata
+- **Screenshots/icon match build**; metadata limits; content rating/CSAE.
+
+---
+
+## Procedure  [HIGH freedom — plan only]
+
+1. **Inventory** Capacitor/RN config, manifests, permissions, listing, IAP.
+2. **Run A–E**, map to guidelines. **Blocking** vs **Risk**.
+3. **Score & order** by likelihood × launch-delay cost.
+4. **Phase** — privacy + functionality first.
+5. **Emit `plan-mobile-readiness.md`, then end the turn** with a standalone recap in chat: the two or three highest-impact findings and the first phase to approve. The file is the deliverable — write it before the recap.
+
+---
+
+## Guardrails
+
+- **Plan only.** No manifest, Data Safety, or listing edits.
+- **Declaration must match reality — both ways.**
+- **Be honest about thin-app / 2.5.2 risk.**
+- **Never advise external payment for digital goods.**
+- **Verify current target-API thresholds at submit time.**
+- **Real devices, not emulators only.**
+
+## Self-critique before the burndown  [LOW freedom — do not skip]
+
+1. **evidenced-not-assumed** — manifests, permissions, and listing fields you actually read
+2. **plan-only** — no PrivacyInfo, Data Safety, or metadata edits
+3. **severity/phase justified** — privacy + 2.5.2 before listing polish
+4. **right-owner** — keywords/screenshots → `plan-aso`; collection-vs-claimed → `plan-privacy-compliance`; receipt/restore → `audit-monetization-iap`; placeholders → `plan-stub-checker`
+5. **no-false-safety** — do not hide Guideline 2.5.2 thin-app risk; declaration must match reality both ways
+
+---
+
+## Report template — `plan-mobile-readiness.md`
+
+```markdown
+# Mobile Store-Readiness Audit — <app>
+
+_Audit-only. Pre-submission. Nothing changes until each phase is approved._
+
+## Scope
+- Platform: iOS ☐ Android ☐  | Framework: Capacitor ☐ RN ☐
+
+## Verdict
+| Area | Blocking | Risk | Worst item |
+|------|----------|------|-----------|
+| Privacy | n | n | Data Safety mismatch |
+| Functionality | n | n | 2.5.2 thin-app |
+
+## Findings
+| # | Item | Store | Guideline | Blocking? | Direction |
+|---|------|-------|-----------|-----------|-----------|
+
+## Phased burndown
+- **Phase 1 — Privacy** → `mobile-capacitor-platform`
+- **Phase 2 — Functionality & 2.5.2** → `plan-stub-checker` / `enhance-capacitor-ui`
+- **Phase 3 — Payments & build** → `mobile-capacitor-platform`
+- **Phase 4 — Listing & testing gate** → metadata, Android closed-test
+
+## Execution handoff
+Real older devices + IAP dry-run before submit.
+```
+
+---
+
+## Chains with
+
+- **Launch gates loop** — mobile submission; pair with `plan-aeo-readiness` for web.
+- **`plan-privacy-compliance`** — collection-vs-claimed + store privacy labels.
+- **`plan-aso`** — listing keywords/screenshots after the app is submittable.
+- **`audit-monetization-iap`** — receipt validation / restore (not just "uses official billing").
+- **`plan-stub-checker`** — placeholders are rejections on mobile.
+- **Execution:** `mobile-capacitor-platform`, `enhance-capacitor-ui`,
+  `mobile-emulator-test` (then real device).
+- **Verify:** real-device crash test + IAP dry-run; Android closed-test gate satisfied.
+
+> Planned at high effort; executed at the default effort under the approved-plan execution rule (`approved-plan-execution.mdc`), which forbids reward hacking and feature deletion on any model.

package/skills/plan-perf-audit/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: plan-perf-audit
+description: >
+  Plan-only performance audit across web, mobile, backend, and data; measures
+  first, fixes nothing. Use when "performance audit plan", "perf burndown",
+  "measure before optimize", or "N+1 audit plan". Apply fixes →
+  audit-performance.
+license: MIT
+effort: high
+---
+
+# Performance Audit + Optimization Plan
+
+**Degree of freedom: HIGH** — measure, interpret, plan. Stay
+**plan-only**. Do not optimize in this pass.
+
+**Role:** Senior performance engineer (web + mobile + backend/data).
+
+**Task:** Profile the app, find performance issues across layers, plan fixes. **Measure, don't
+guess. Audit & plan only — do not optimize in this pass.**
+
+## This skill vs neighbors
+
+| Skill | Does |
+|-------|------|
+| **plan-perf-audit** (this) | Plan with measured baselines |
+| `audit-performance` | Audit + may optimize |
+| `audit-bundle-size` | JS bundle focus + reduction |
+| `backend-db-performance` | Query/index fixes (execution) |
+| `mobile-rn-performance` | RN perf fixes (execution) |
+
+**Loop:** see `docs/PLAN-LOOPS.md` — after `plan-test-coverage`, parallel with `plan-security-audit`, before `plan-docs-sync`
+
+## How to reason (every plan item)
+
+1. **Propose** — an optimization tied to a measured baseline
+2. **Risk** — user-visible stall, cost, or timeout if left as-is
+3. **Keep-working** — paths already inside budget
+4. **Phase** — P0 hot-path → structural → polish (do not execute)
+
+## Worked example
+
+> **Propose:** split the 412 KB hero chart chunk; add an index on `orders(user_id, created_at)` after EXPLAIN.
+> **Risk:** `/dashboard` LCP 4.8s (Lighthouse); orders list is a 1.2s sequential N+1.
+> **Keep-working:** `/pricing` already LCP <2s; user lookup is indexed.
+> **Phase:** Phase 1 — P0 hot-path wins. No fabricated numbers.
+
+---
+
+## ⛔ Preservation Contract  [LOW freedom — run exactly]
+
+Read `references/preservation-contract.md`. Acknowledge in output #1.
+
+**Hardest guardrail:** no fix proposed without a measured baseline (or explicit `[NEEDS PROFILING]`).
+
+---
+
+## References
+
+| File | Contents |
+|------|----------|
+| `references/audit-scope.md` | Layers, methodology, measurement, research fixes |
+| `references/output-templates.md` | Baselines, burndown, phased plan |
+
+---
+
+## Phase flow
+
+```
+1. Fingerprint stack (web/RN/API/Supabase)
+2. Measure baselines per layer (no guessing)
+3. Trace hot paths
+4. Per-layer issue inventory
+5. Burndown + phased optimization plan
+6. Guardrails (budgets, Lighthouse CI, RUM)
+7. Research citations
+```
+
+Optional browser: Lighthouse via playwright-cli. Read `protocol-browser-anti-stall` first.
+
+---
+
+## Phase 1 — Measure first  [HIGH freedom]
+
+Establish baselines before any fix proposal:
+
+| Layer | Tools |
+|-------|-------|
+| Web CWV | Lighthouse, `web-vitals`, RUM/Sentry |
+| Bundle | `rollup-plugin-visualizer`, `@next/bundle-analyzer` |
+| RN | Metro bundle report, cold start profiler |
+| API | Sentry transactions, server logs |
+| DB | Supabase advisors, `EXPLAIN ANALYZE`, slow query logs |
+
+Scope detail: `references/audit-scope.md`
+
+---
+
+## Phase 2–4 — Hot paths + inventory  [HIGH freedom]
+
+Prioritize highest-traffic screens, endpoints, queries. Tie each issue to path:line or query text.
+
+Root-cause, not symptom. Quantify expected gain where possible.
+
+---
+
+## Phase 5 — Burndown + plan  [HIGH freedom — plan only]
+
+Template: `references/output-templates.md`
+
+Phases: (1) P0 hot-path wins → (2) structural → (3) polish.
+
+**Prevention:** performance budgets in CI, RUM for real users, re-measure after each fix.
+
+## Self-critique before the burndown  [LOW freedom — do not skip]
+
+1. **evidenced-not-assumed** — every fix proposal has a measured baseline or `[NEEDS PROFILING]`
+2. **plan-only** — do not optimize this pass
+3. **phase justified** — P0 hot-path before polish; no fabricated numbers
+4. **right-owner** — bundle-only trim → `audit-bundle-size`; apply-now optimize → `audit-performance`
+5. **no-false-safety** — symptom without root-cause is not a plan item
+
+---
+
+## Required output (in order)
+
+1. Preservation-contract acknowledgment
+2. Measured baselines per layer
+3. Per-layer issue inventory
+4. Burndown table (measured current + target + risk)
+5. Optimization + enhancement plan, phased
+6. Guardrails/tooling
+7. Research notes + citations
+8. Open questions / `[NEEDS PROFILING]` list
+
+End the turn with a standalone recap in chat: the two or three highest-impact measured issues and the first phase to approve. The plan is the deliverable — write it before the recap.
+
+---
+
+## Rules  [LOW freedom — run exactly]
+
+- Plan only — do not optimize until approved.
+- Measure, don't guess. No fabricated numbers.
+- Optimizations preserve behavior + output.
+- Re-measure after fixes; keep before/after.

package/skills/plan-perf-audit/references/audit-scope.md

@@ -0,0 +1,51 @@
+# Audit Scope & Methodology
+
+## Layers
+
+### Web frontend
+- **CWV:** LCP, CLS, INP — Lighthouse / web-vitals / RUM (not guessed). Loading priority: LCP element identified via attribution; not lazy; fetchpriority/preload; font fallback metrics; 103 Early Hints presence.
+- **Bundle:** total + per-route, code-split gaps, duplicate deps, lazy-load, tree-shaking
+- **Render:** React Compiler enabled; unnecessary re-renders, manual memo only with Profiler evidence, unstable keys, un-virtualized lists, main-thread blocking work
+- **Assets:** image format/size, lazy-load, third-party scripts, compression/CDN
+- **Navigation:** Speculation Rules (prefetch/prerender coverage + exclusions), bfcache eligibility per page type, cross-document View Transitions, Next.js prefetch discipline. Next-navigation p75 measured with web-vitals `onLCP` on soft/hard navs.
+
+### Mobile / React Native
+- Cold start / TTI (target <2s mid-tier), Hermes, JS bundle size, re-renders, JSI/native for heavy work, lazy feature bundles, list virtualization, image caching
+- **Mobile thresholds ~40% stricter than web CWV** (Indeed research pattern)
+
+### Backend / API
+- Slow endpoints (p95/p99), sync I/O, missing caching, over-fetching, unbounded payloads, missing pagination
+
+### Data / Supabase
+- N+1 queries, missing indexes (**EXPLAIN**, not guesses), sequential scans, `select *`, RLS slow filters, missing realtime SELECT policies, unbatched writes
+
+## Methodology
+
+1. **Measure first** — baselines per layer. No fix without baseline.
+2. **Trace hot paths** — highest-traffic screens/endpoints/queries first.
+3. **Root-cause** — tie slow metric to path:line or query.
+4. **Quantify expected gain** where possible (e.g. code-split route → −340KB initial JS).
+
+## Measurement commands (adapt)
+
+```
+npm run build -- --analyze   # or vite-bundle-visualizer
+npx lighthouse <url> --only-categories=performance
+npm audit bundle             # if configured
+```
+
+Supabase MCP: slow query logs, advisors. Sentry MCP: Web Vitals, slow transactions.
+
+## Research-backed fixes (propose, don't implement)
+
+**React:** React Compiler enabled; route `lazy()`, manual `memo`/`useCallback`/`useMemo` only with Profiler evidence, `react-window`, `startTransition`; SSR/hydration caveats.
+
+**RN:** Hermes, JSI for heavy work, lazy feature bundles, cold start <2s mid-tier.
+
+**Data:** verified indexes via EXPLAIN, projection-only selects, caching tiers, batched writes.
+
+## Prevention guardrails
+
+- Performance budgets: bundle size, image weight, third-party count, CWV — Lighthouse CI
+- RUM (web-vitals) for real-user distribution, not just lab
+- Re-measure after each fix (same tool, before/after)

package/skills/plan-perf-audit/references/output-templates.md

@@ -0,0 +1,33 @@
+# Output Templates
+
+## Measured baselines
+
+| Layer | Metric | Tool | Current | Target | `[NEEDS PROFILING]` |
+|-------|--------|------|---------|--------|---------------------|
+| Web CWV | LCP / CLS / INP | Lighthouse/RUM | … | … | |
+| Navigation | 2nd-page LCP p75 / bfcache hit rate | web-vitals + DevTools | … | … | |
+| Bundle | initial JS KB | analyzer | … | budget | |
+| RN | cold start ms | profiler | … | <2000 | |
+| API | p95 ms | Sentry/logs | … | … | |
+| DB | slow queries | EXPLAIN/advisors | … | … | |
+
+## Burndown
+
+| Layer | Issue | Metric/Evidence | Current | Target | Fix | Severity | Effort | Risk | Path/Query |
+
+P0 = user jank / >Xs load / N+1 on hot path · P3 = micro-opt
+
+## Phased optimization plan
+
+1. Measured P0 hot-path wins (N+1, oversized bundle, main-thread block)
+2. Structural (code-split, indexing, caching, async I/O)
+3. Polish (images, micro-memo)
+
+Each fix: expected gain + "what must keep working"
+
+## Guardrails checklist
+
+- [ ] Lighthouse CI performance budgets
+- [ ] RUM / web-vitals pipeline
+- [ ] Bundle size budget in CI
+- [ ] Re-measure gate on perf PRs

package/skills/plan-perf-audit/references/preservation-contract.md

@@ -0,0 +1,13 @@
+# Preservation Contract
+
+## Never do in this pass
+
+- **Behavior change disguised as optimization.** Output/contract/UX identical unless proposed + approved.
+- **Fabricate metrics.** No invented bundle sizes or query times. Not measured → "not yet measured" or `[NEEDS PROFILING]` + how to measure.
+- **Remove features/code** to speed up — dead code → proposal, not delete.
+- **Guess** — ground every claim in measurement or path:line.
+- **Optimize** in this pass. Fixes proposed with expected gain + risk on approval.
+
+## Before any change proposal
+
+One line: **what currently works here that must keep working.**

package/skills/plan-pricing/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: plan-pricing
+description: >
+  Plan-only pricing audit: value metric, tiers, price points, free-tier
+  boundary, annual and enterprise anchors, and a willingness-to-pay study. Use
+  when "pricing strategy", "what should I charge", or "are we underpriced".
+license: MIT
+effort: high
+---
+
+# plan-pricing — What to charge for, then how much
+
+**Degree of freedom: MIXED.** Repo inventory and the research-method order
+`[LOW freedom — run exactly]`; value-metric choice, tier design, and price
+corridor `[HIGH freedom]`. Stay **plan-only**: no price, plan enum, Stripe
+product, or copy edits until approved.
+
+**Role:** Pricing lead who reads billing code. The repo shows what is metered
+and gated today; the founder owns the number.
+
+**Task:** Inventory the current model, pick the value metric, design ≤3
+tiers, propose a price corridor with the research that would confirm it, emit
+`plan-pricing.md`. **Change nothing until approved.**
+
+## This skill vs neighbors
+
+| Skill | Owns |
+|---|---|
+| **plan-pricing** (this) | Value metric, packaging, price points, research plan |
+| `plan-gtm` | Chose freemium / trial / open-core; hands the model here |
+| `enhance-web-conversion` | The pricing *page* — copy, anchor, toggle, prompts |
+| `audit-payment-system` | Whether checkout, webhooks, proration actually work |
+| `audit-monetization-iap` | Mobile store prices and entitlements |
+| `plan-llm-cost-guardrails` | Caps and breakers when the metric is tokens |
+
+Do **not** fire for "fix the pricing page" → `enhance-web-conversion`.
+
+## How to reason (every proposal)
+
+1. **Metric** — which unit rises when the customer gets more value, and can they estimate it before signing?
+2. **Package** — which capabilities belong together for which segment; does one meter span all tiers?
+3. **Point** — where does the price sit against alternatives, cost, and the corridor the research gives?
+4. **Prove** — which method (Van Westendorp → Gabor-Granger → MaxDiff → conjoint) confirms it, and what would change the answer?
+
+## Worked example
+
+> **Metric:** a bug-report SDK meters `reports/month`; buyers think in
+> "apps monitored" and can estimate that before signing. Propose: primary metric
+> = apps, secondary overage = reports beyond an allowance.
+> **Package:** Free 1 app / 50 reports · Pro 3 apps · Team 10 apps + SSO;
+> Enterprise "from ¥…" with audit log. Three tiers, same CTA verb.
+> **Point:** Pro at ¥2,900/mo sits under the cheapest alternative's ¥4,800;
+> current ¥980 is inside the "too cheap" band two customers named in interviews.
+> **Prove:** Van Westendorp on the 40 free-tier accounts for a corridor, then
+> Gabor-Granger on Pro; keep the metric fixed for two years, revisit rates.
+
+## Self-critique before the burndown  [LOW freedom — do not skip]
+
+1. **one-metric-sentence** — "Our customer receives more value when ___ increases" is written and the metric is that blank
+2. **estimable** — a buyer can predict their bill before signing; usage meters show the unit, allowance, and a live estimate
+3. **anchor-present** — the enterprise or top tier shows a number or "from"; nothing is pure "Contact sales"
+4. **corridor-not-guess** — every price point cites a method run or planned, or a named alternative's price; otherwise **unmeasured**
+5. **plan-only** — no plan enum, Stripe product, price, or copy changed
+6. **right-owner** — page copy → `enhance-web-conversion`; billing correctness → `audit-payment-system`
+
+---
+
+## Step 1 — Inventory  [LOW freedom — run exactly]
+
+| Area | Grep / open | Records |
+|---|---|---|
+| Plans & gates | `plan`, `tier`, `isPro`, `entitlement`, feature flags keyed on plan; Stripe/Paddle/Lemon product IDs | current tiers, what each gates |
+| Metering | `usage`, `credits`, `quota`, `limit`, counters, metered prices, `usage_metered` events | what is counted today, what is billed |
+| Price points | pricing route, Stripe dashboard export, `prices` table | monthly / annual / currency per tier |
+| Trial & free | `trial_ends_at`, downgrade jobs, free-plan limits | model in force |
+| Cost | per-action cost (LLM tokens, storage, compute) | floor for any usage price |
+| Customers | plan distribution, upgrade/downgrade events, churn reasons, "too expensive" in support | willingness-to-pay evidence already owned |
+| Alternatives | the three the founder named in `plan-gtm`; their public prices and metrics, looked up now — recognizing a product is not knowing its current price | anchor context |
+
+## Step 2 — Value metric  [HIGH freedom]
+
+List candidate units (seats, projects, apps, transactions, rows, runs, revenue
+managed, outcomes). Score each 1–5 on: **value connection**, **fairness /
+familiarity**, **predictability** (buyer can forecast it), **scalability**
+(grows with the account), **billability** (you can meter it). Keep one primary
+metric; add a usage component only where a material variable cost is not
+covered by the primary. Simulate the metric on real historical accounts —
+prices that look absurd for a specific account reveal a missing segment or a
+weak proxy.
+
+| Metric | Works when | Watch for |
+|---|---|---|
+| Seats | value and cost grow with active people | seat friction throttles adoption |
+| Usage / transactions | each unit is meaningful work | usage without a matching result; bill shock (41% of buyers cite unpredictable cost as the top objection) |
+| Data volume | processing or storage is the value | business buyers cannot forecast bytes |
+| Scope (apps, sites, locations) | deployment breadth drives value | flat within a unit |
+| Outcomes | attribution is objective and agreed | disputes; measurement debt |
+
+Hybrid (base + usage) is now 41% of B2B SaaS; AI-native products price on
+outcomes 4× more often. A model name is shorthand for a metric choice — pick
+the metric first, then the cadence.
+
+## Step 3 — Packaging  [HIGH freedom]
+
+≤3 self-serve tiers good-better-best from the outside in (what the segment
+is trying to accomplish), recommended middle, higher tier on the right as the
+anchor, enterprise shows "from". Free-tier boundary sits just before the
+activation event's natural repeat — enough to reach value, not enough to
+live there. Annual = 15–25% off, stated as months free. Credits: unit,
+included amount, live estimate, and a hard cap the user sets.
+
+## Step 4 — Price corridor and research  [LOW freedom — order]
+
+1. **Van Westendorp** (four questions: too cheap / bargain / expensive / too
+   expensive) on current users → acceptable range. Directional only.
+2. **Gabor-Granger** on the recommended tier → revenue-maximizing point.
+3. **MaxDiff** when too many features compete for tier placement.
+4. **Conjoint** last, when redesigning bundles.
+Plus win/loss notes and one in-market test after approval. Underpricing "to
+reduce friction" attracts the curious, not the committed (one indie raise
+£9 → £19 moved month-3 retention 42% → 67%). Sources in
+`plan-gtm/references/benchmarks-2026.md`.
+
+## Step 5 — Emit `plan-pricing.md`, end the turn  [LOW freedom — run exactly]
+
+```markdown
+# Pricing Plan — <product>
+
+_Plan-only. Nothing changes until approved._
+
+## Current model (evidence)
+| Tier | Price | Gates | Metered | Source |
+
+## Value metric
+"Our customer receives more value when ___ increases."
+| Candidate | Value | Fair | Predictable | Scales | Billable | Verdict |
+
+## Proposed packaging
+| Tier | For whom | Includes | Limit | Monthly | Annual (months free) |
+Enterprise: from … · Free boundary: …
+
+## Price corridor
+| Tier | Floor (cost) | Alternatives | VW range | Proposed | Confidence |
+
+## Research plan
+| Method | Sample | Question | Decides |
+
+## Risks & keep-working
+- migration of existing customers (grandfather / notice period)
+- metering accuracy before any usage price ships (`audit-payment-system`)
+
+## Phased burndown
+- **Phase 1 — Research** → interviews + Van Westendorp survey (`docs-coauthor` for the script)
+- **Phase 2 — Page** → `enhance-web-conversion`
+- **Phase 3 — Billing** → `audit-payment-system`, Stripe products, proration, grandfathering
+- **Phase 4 — Measure** → `audit-analytics` (`pricing_viewed`, `plan_selected`, `checkout_*`), 60-day review
+```
+
+End the turn with a standalone recap in chat: the proposed metric in one sentence, the price corridor, and the first research step to approve. The file is the deliverable — write it before the recap.
+
+## Guardrails
+
+- **Plan only.** No prices, plan enums, Stripe objects, or copy.
+- **The number is the founder's.** Recommend a corridor and a method; log their decision.
+- **No bait.** Price shown before checkout; cancel and downgrade paths stay.
+- **Grandfather or notify.** Existing customers are a named row in the plan.
+
+## Chains with
+
+- **`plan-gtm`** → model decision in; pricing plan out.
+- **`enhance-web-conversion`** → the page after approval.
+- **`audit-payment-system`** → before any metered price ships.
+- **`plan-llm-cost-guardrails`** → when the metric is tokens or compute.