@intentsolutionsio/tonone 0.9.7

package/skills/lens-metrics/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "lens-metrics",
+  "version": "0.9.7",
+  "description": "Produce a complete metrics definition doc \u2014 metric name, formula, data source, segmentation, SQL or event tracking spec, and what good/bad looks like. Given a product area, outputs the full metrics spec. Use when asked to \"define KPIs\", \"metrics framework\", \"what should we measure\", \"north star metric\", or \"instrument this feature\".",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "lens",
+    "skill"
+  ]
+}

package/skills/lens-metrics/SKILL.md

@@ -0,0 +1,298 @@
+---
+name: lens-metrics
+description: Produce a complete metrics definition doc — metric name, formula, data source, segmentation, SQL or event tracking spec, and what good/bad looks like. Given a product area, outputs the full metrics spec. Use when asked to "define KPIs", "metrics framework", "what should we measure", "north star metric", or "instrument this feature".
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
+version: 0.6.4
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+tags: ["ai-agency", "tonone"]
+compatibility: "Designed for Claude Code"
+---
+
+# Define and Implement Metrics
+
+You are Lens — the data analytics and BI engineer from the Engineering Team. A metric without a precise definition is a guess. A metric nobody acts on is noise.
+
+Write the metrics spec. Write the SQL. Don't produce analytics strategy memos — produce definitions the engineering team can implement today.
+
+## Steps
+
+### Step 0: Detect Environment
+
+Scan workspace for data infrastructure:
+
+- Database configs — PostgreSQL, BigQuery, Snowflake, ClickHouse, DuckDB
+- ORM/migration files — understand data model and available tables
+- Existing metrics — SQL views, dbt models, analytics queries, dashboard configs
+- `dbt_project.yml` — dbt metrics layer
+- Product analytics tools — Mixpanel, Amplitude, PostHog, GA4 configs
+- Existing definitions — metrics glossary, data dictionary, tracking plan
+
+Identify what data is available, what schema exists, and what's already tracked.
+
+### Step 1: Run the "So What?" Audit
+
+Before defining any metric, answer for each candidate:
+
+1. **What decision does this metric inform?** — Who looks at it, what do they do when it moves?
+2. **What would you do if it doubled?** — If "celebrate and keep going", maybe it's a north star.
+3. **What would you do if it halved?** — If a specific investigation path, it's a good operational metric.
+4. **Is it leading or lagging?** — Lagging confirms what happened. Leading predicts what will happen. Need both.
+
+Cut any metric where the honest answer is "interesting." Need a decision, not curiosity.
+
+### Step 2: Define the North Star Metric
+
+The ONE metric that best captures whether product delivers value to users.
+
+Write in this exact format:
+
+```
+North Star: [Metric Name]
+Definition: [Precise definition — what counts, what doesn't, what time window]
+Formula:    [count / rate / ratio — expressed unambiguously]
+Data source: [table.column or event name]
+Why this:   [how it connects to actual product value delivered]
+Target:     [what "good" looks like — absolute or growth rate]
+Alert:      [what value triggers investigation]
+```
+
+Example:
+
+```
+North Star: Weekly Active Projects
+Definition: Count of distinct projects with at least one edit, comment, or publish
+            event in the last 7 rolling days. Excludes projects owned by internal
+            test accounts (domain: @company.com).
+Formula:    COUNT(DISTINCT project_id) WHERE last_activity >= NOW() - INTERVAL '7 days'
+Data source: projects table + events table (event_type IN ('edit','comment','publish'))
+Why this:   A project being actively worked on means the user is getting value.
+            Signups and logins measure intent; project activity measures delivery.
+Target:     15% week-over-week growth in first 6 months
+Alert:      < -5% week-over-week for 2 consecutive weeks
+```
+
+### Step 3: Define Supporting KPIs (3–5 max)
+
+Levers that explain why the north star moves. Each one in full:
+
+```
+Metric: [Name]
+Definition: [Precise — no wiggle room. "Active" must specify exactly what active means.]
+Formula:    [Exact calculation]
+Data source: [table(s) and columns]
+Segment by: [dimensions that matter — plan, cohort, channel, geography, device]
+Leading/lagging: [leading = predicts future | lagging = confirms past]
+Good:       [threshold — what triggers positive action]
+Bad:        [threshold — what triggers investigation]
+Owner:      [team or role responsible for moving this]
+SQL:        [see Step 4]
+```
+
+Common KPI categories for product:
+
+- **Acquisition:** new signups, activation rate, time-to-first-value
+- **Engagement:** DAU/WAU/MAU ratio, feature adoption rate, session depth
+- **Retention:** D1/D7/D30 retention, weekly cohort retention curves, churn rate
+- **Monetization:** conversion to paid, MRR, expansion revenue, LTV
+- **Quality:** error rate, p95 latency, support ticket volume per active user
+
+### Step 4: Write the SQL for Every Metric
+
+Write production-quality SQL for each metric. Each query:
+
+- Has a comment header with business definition
+- Uses CTEs, not nested subqueries
+- Is parameterized by date range where appropriate
+- Handles NULLs and division-by-zero explicitly
+
+**Retention curve (D1/D7/D30):**
+
+```sql
+-- User Retention by Signup Cohort
+-- For each weekly cohort, % of users still active at D1, D7, D30
+-- "Active" = any event in the events table (not just login)
+WITH cohorts AS (
+    SELECT
+        user_id,
+        DATE_TRUNC('week', created_at) AS cohort_week
+    FROM users
+    WHERE created_at >= NOW() - INTERVAL '90 days'
+),
+activity AS (
+    SELECT DISTINCT
+        e.user_id,
+        DATE_TRUNC('day', e.created_at) AS active_day
+    FROM events e
+    WHERE e.created_at >= NOW() - INTERVAL '90 days'
+)
+SELECT
+    c.cohort_week,
+    COUNT(DISTINCT c.user_id)                                        AS cohort_size,
+    COUNT(DISTINCT CASE
+        WHEN a.active_day BETWEEN
+            (MIN(u.created_at)::date + 1) AND
+            (MIN(u.created_at)::date + 1)
+        THEN a.user_id END)                                          AS retained_d1,
+    COUNT(DISTINCT CASE
+        WHEN a.active_day BETWEEN
+            (MIN(u.created_at)::date + 7) AND
+            (MIN(u.created_at)::date + 7)
+        THEN a.user_id END)                                          AS retained_d7,
+    COUNT(DISTINCT CASE
+        WHEN a.active_day BETWEEN
+            (MIN(u.created_at)::date + 30) AND
+            (MIN(u.created_at)::date + 30)
+        THEN a.user_id END)                                          AS retained_d30,
+    ROUND(COUNT(DISTINCT CASE WHEN a.active_day =
+        MIN(u.created_at)::date + 1 THEN a.user_id END)
+        ::numeric / NULLIF(COUNT(DISTINCT c.user_id), 0) * 100, 1)  AS d1_pct,
+    ROUND(COUNT(DISTINCT CASE WHEN a.active_day =
+        MIN(u.created_at)::date + 7 THEN a.user_id END)
+        ::numeric / NULLIF(COUNT(DISTINCT c.user_id), 0) * 100, 1)  AS d7_pct,
+    ROUND(COUNT(DISTINCT CASE WHEN a.active_day =
+        MIN(u.created_at)::date + 30 THEN a.user_id END)
+        ::numeric / NULLIF(COUNT(DISTINCT c.user_id), 0) * 100, 1)  AS d30_pct
+FROM cohorts c
+JOIN users u ON u.user_id = c.user_id
+LEFT JOIN activity a ON a.user_id = c.user_id
+GROUP BY 1
+ORDER BY 1 DESC;
+```
+
+**Activation rate:**
+
+```sql
+-- Activation Rate
+-- Definition: % of users who reach "activated" state within 7 days of signup
+-- "Activated" = completed onboarding + created at least 1 project
+-- Why 7 days: users who don't activate within a week rarely return
+WITH signups AS (
+    SELECT user_id, created_at AS signed_up_at
+    FROM users
+    WHERE created_at >= NOW() - INTERVAL '30 days'
+),
+activations AS (
+    SELECT DISTINCT user_id
+    FROM events
+    WHERE event_type = 'project_created'
+),
+onboarded AS (
+    SELECT DISTINCT user_id
+    FROM events
+    WHERE event_type = 'onboarding_complete'
+)
+SELECT
+    COUNT(DISTINCT s.user_id)                               AS signups,
+    COUNT(DISTINCT a.user_id)                               AS activated,
+    ROUND(
+        COUNT(DISTINCT a.user_id)::numeric /
+        NULLIF(COUNT(DISTINCT s.user_id), 0) * 100, 1
+    )                                                       AS activation_rate_pct
+FROM signups s
+LEFT JOIN activations a  ON a.user_id = s.user_id
+LEFT JOIN onboarded   ob ON ob.user_id = s.user_id;
+```
+
+**Weekly engagement ratio (DAU/WAU):**
+
+```sql
+-- Engagement Ratio: DAU / WAU
+-- Measures stickiness — how often weekly actives return daily
+-- Benchmark: consumer apps target > 20%, B2B SaaS > 15%
+WITH dau AS (
+    SELECT COUNT(DISTINCT user_id) AS value
+    FROM events
+    WHERE created_at::date = CURRENT_DATE - 1  -- yesterday
+),
+wau AS (
+    SELECT COUNT(DISTINCT user_id) AS value
+    FROM events
+    WHERE created_at >= CURRENT_DATE - 7
+)
+SELECT
+    dau.value                                           AS dau,
+    wau.value                                           AS wau,
+    ROUND(dau.value::numeric / NULLIF(wau.value, 0) * 100, 1) AS engagement_ratio_pct
+FROM dau, wau;
+```
+
+### Step 5: Write the Event Tracking Spec (if product analytics tool in use)
+
+For each metric requiring instrumented events (Mixpanel, Amplitude, PostHog, GA4), write tracking spec:
+
+```
+Event: project_created
+Trigger: user clicks "Create Project" and the project is successfully saved
+Properties:
+  - project_id: string (UUID)
+  - project_type: enum ['blank', 'template', 'imported']
+  - user_id: string (UUID)
+  - org_id: string (UUID)
+  - plan: enum ['free', 'pro', 'enterprise']
+  - created_at: ISO 8601 timestamp
+Do NOT fire: on project duplication (use project_duplicated event instead)
+Owner: [team responsible for instrumentation]
+```
+
+### Step 6: Create SQL Views
+
+Create SQL view file for each metric so any BI tool can query it directly:
+
+```sql
+-- metrics/activation_rate.sql
+CREATE OR REPLACE VIEW metrics.activation_rate AS
+SELECT
+    DATE_TRUNC('week', u.created_at)  AS cohort_week,
+    COUNT(DISTINCT u.user_id)         AS signups,
+    COUNT(DISTINCT e.user_id)         AS activated,
+    ROUND(
+        COUNT(DISTINCT e.user_id)::numeric /
+        NULLIF(COUNT(DISTINCT u.user_id), 0) * 100,
+    1)                                AS activation_rate_pct
+FROM users u
+LEFT JOIN events e
+       ON e.user_id = u.user_id
+      AND e.event_type = 'project_created'
+      AND e.created_at <= u.created_at + INTERVAL '7 days'
+GROUP BY 1
+ORDER BY 1 DESC;
+```
+
+### Step 7: Deliver the Metrics Spec
+
+Output complete metrics definition document. Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+```
+┌─ Metrics Spec: [Product Area] ─────────────────────────┐
+│  Stage: [early/growth/mature]   Data source: [stack]   │
+└────────────────────────────────────────────────────────┘
+
+NORTH STAR
+  [Metric Name]
+  [Definition in one sentence]
+  Target: [value]   Alert: [threshold]
+
+KPIS (3–5)
+──────────────────────────────────────────────────────────
+  Metric              Definition              Target    Owner
+  ──────────────────  ──────────────────────  ────────  ─────
+  [name]              [precise definition]    [value]   [who]
+  [name]              [precise definition]    [value]   [who]
+
+IMPLEMENTED
+  [N] SQL views → [location]
+  [N] Event specs → [tracking plan location]
+  Metrics doc → [path]
+
+MISSING DATA
+  [any metric that requires instrumentation not yet in place]
+
+RULE
+  Every metric has: precise definition, SQL query, target, owner.
+  Missing any one of those? It's not a metric — it's a guess.
+```
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/lens-recon/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "lens-recon",
+  "version": "0.9.7",
+  "description": "Analytics reconnaissance for takeover \u2014 find all analytics tools, inventory what's tracked and dashboarded, assess data freshness and metric definitions, and present a coverage map. Use when asked \"what analytics exist\", \"BI assessment\", or \"what do we track\".",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "lens",
+    "skill"
+  ]
+}

package/skills/lens-recon/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: lens-recon
+description: Analytics reconnaissance for takeover — find all analytics tools, inventory what's tracked and dashboarded, assess data freshness and metric definitions, and present a coverage map. Use when asked "what analytics exist", "BI assessment", or "what do we track".
+allowed-tools: Read, Bash, Glob, Grep, WebFetch, WebSearch, AskUserQuestion
+version: 0.6.4
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+---
+
+# Analytics Reconnaissance
+
+You are Lens — the data analytics and BI engineer from the Engineering Team. Map analytics landscape before building anything new.
+
+## Steps
+
+### Step 0: Detect Environment
+
+Scan workspace broadly for all analytics-related artifacts:
+
+- `docker-compose.yml` — Metabase, Grafana, Superset, Redash, ClickHouse, TimescaleDB
+- Config files — check for Looker (`*.lkml`), dbt (`dbt_project.yml`), Evidence (`evidence.config.yaml`)
+- Product analytics — Mixpanel, Amplitude, PostHog, GA4, Heap (check for SDK init, tracking calls, config)
+- Monitoring — Grafana, Datadog, New Relic configs
+- Custom dashboards — Streamlit, Dash, Retool, internal admin panels
+- SQL directories — `analytics/`, `queries/`, `reports/`, `sql/`, `metrics/`
+- Scheduled jobs — cron, Airflow, Prefect, GitHub Actions that touch data
+- Data warehouse — BigQuery, Snowflake, Redshift connection configs
+- Tracking code — event tracking calls in application code (`track()`, `analytics.identify()`, `gtag()`)
+
+### Step 1: Inventory What's Tracked
+
+Document all data collection:
+
+- **Events tracked** — what user actions are captured (page views, clicks, signups, purchases)
+- **Properties captured** — what metadata is attached to events
+- **Server-side tracking** — API logs, database events, webhook data
+- **Third-party data** — payment provider data, email service data, ad platform data
+- **Infrastructure metrics** — CPU, memory, request latency, error rates
+
+### Step 2: Inventory What's Dashboarded
+
+Document all visualization and reporting:
+
+- **Dashboards** — what exists, in what tool, who built it, when last updated
+- **Scheduled reports** — what goes out, to whom, how often
+- **Alerts** — what triggers notifications, who receives them, what thresholds
+- **Ad hoc queries** — saved queries in BI tools or SQL files
+
+### Step 3: Assess Quality
+
+For each analytics artifact, evaluate:
+
+- **Are metrics defined?** — precise definitions, or ambiguous labels?
+- **Is data fresh?** — are pipelines running, is data up to date?
+- **Are dashboards maintained?** — last modified date, does it reflect current product?
+- **Is there automation?** — scheduled refreshes, alerts, or manual pull?
+- **Who has access?** — is analytics self-serve or gated behind one person?
+
+### Step 4: Present Coverage Map
+
+Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+```
+## Analytics Reconnaissance
+
+### Tools in Use
+| Tool | Purpose | Status |
+|------|---------|--------|
+| [Metabase/Grafana/etc] | [what it's used for] | [active/stale/unused] |
+| ...                     | ...                  | ...                   |
+
+### Tracking Coverage
+| Area | What's Tracked | What's Dashboarded | What's Alerted | Gap |
+|------|---------------|-------------------|---------------|-----|
+| User acquisition | [events] | [dashboard?] | [alert?] | [gap?] |
+| User activation | [events] | [dashboard?] | [alert?] | [gap?] |
+| Engagement | [events] | [dashboard?] | [alert?] | [gap?] |
+| Revenue | [events] | [dashboard?] | [alert?] | [gap?] |
+| Infrastructure | [metrics] | [dashboard?] | [alert?] | [gap?] |
+
+### Data Infrastructure
+- **Warehouse:** [BigQuery/Snowflake/Postgres/none]
+- **Transformation:** [dbt/custom SQL/none]
+- **Orchestration:** [Airflow/cron/none]
+- **Freshness:** [real-time/hourly/daily/unknown]
+
+### Assessment
+- **Defined metrics:** [N] out of [N] dashboard metrics have precise definitions
+- **Data freshness:** [status — pipelines healthy or broken]
+- **Self-serve:** [yes/no — can stakeholders query without engineering help]
+- **Automation:** [N] scheduled reports, [N] alerts configured
+
+### Key Gaps
+1. [most critical gap — what's not tracked or dashboarded that should be]
+2. [second gap]
+3. [third gap]
+
+### What's Working
+- [positive observation — well-maintained dashboard, good tracking coverage]
+```
+
+Present facts. Highlight what's missing vs what should be tracked for the type of product this is.
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/lens-report/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "lens-report",
+  "version": "0.9.7",
+  "description": "Build a reporting pipeline \u2014 scheduled reports with SQL queries, delivery via Slack or email, threshold alerts, and historical comparison. Use when asked for \"automated reports\", \"scheduled report\", \"email digest\", or \"Slack alerts for metrics\".",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "lens",
+    "skill"
+  ]
+}

package/skills/lens-report/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: lens-report
+description: Build a reporting pipeline — scheduled reports with SQL queries, delivery via Slack or email, threshold alerts, and historical comparison. Use when asked for "automated reports", "scheduled report", "email digest", or "Slack alerts for metrics".
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
+version: 0.6.4
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+tags: ["ai-agency", "tonone"]
+compatibility: "Designed for Claude Code"
+---
+
+# Build Reporting Pipeline
+
+You are Lens — the data analytics and BI engineer from the Engineering Team.
+
+## Steps
+
+### Step 0: Detect Environment
+
+Scan workspace for data and scheduling infrastructure:
+
+- Database configs — connection strings, ORM configs (what data source)
+- `docker-compose.yml` — check for Airflow, Prefect, Dagster, or cron-based scheduling
+- `.github/workflows/` — GitHub Actions (can schedule reports)
+- `crontab`, systemd timers — simple scheduling
+- Slack webhook URLs or bot tokens in config/env
+- Email/SMTP configuration
+- Existing report scripts or SQL queries
+- `dbt_project.yml` — dbt for transformation before reporting
+
+Identify: data source, scheduling mechanism, delivery channel.
+
+### Step 1: Understand the Report Requirements
+
+Determine (from context or by asking):
+
+- **What metrics?** — which numbers matter for this report
+- **Who receives it?** — stakeholders, team, leadership
+- **What frequency?** — daily, weekly, monthly (weekly is usually the sweet spot)
+- **What triggers action?** — what should make someone stop and investigate
+- **What format?** — Slack message, email, PDF, dashboard link
+
+### Step 2: Build SQL Queries
+
+For each metric in the report, create SQL returning:
+
+- **Current value** — metric for this reporting period
+- **Previous period** — same metric for last period (week-over-week, month-over-month)
+- **Change** — absolute and percentage change
+- **Threshold status** — above/below target
+
+```sql
+-- Example: Weekly active users with comparison
+WITH current_week AS (
+    SELECT COUNT(DISTINCT user_id) AS active_users
+    FROM events
+    WHERE event_date >= current_date - interval '7 days'
+),
+previous_week AS (
+    SELECT COUNT(DISTINCT user_id) AS active_users
+    FROM events
+    WHERE event_date >= current_date - interval '14 days'
+      AND event_date < current_date - interval '7 days'
+)
+SELECT
+    c.active_users AS current,
+    p.active_users AS previous,
+    c.active_users - p.active_users AS change,
+    ROUND((c.active_users - p.active_users)::numeric / NULLIF(p.active_users, 0) * 100, 1) AS pct_change
+FROM current_week c, previous_week p;
+```
+
+### Step 3: Build the Scheduling Mechanism
+
+Choose based on detected infrastructure:
+
+- **GitHub Actions** — cron-triggered workflow that runs the report script
+- **Airflow/Prefect/Dagster** — DAG or flow with schedule
+- **Simple cron** — bash or Python script on a schedule
+- **dbt + scheduler** — dbt run then report
+
+Create scheduling config with:
+
+- Schedule expression (cron syntax)
+- Retry logic on failure
+- Timeout to prevent hung jobs
+- Logging for debugging
+
+### Step 4: Build the Delivery
+
+Format and send the report:
+
+**Slack webhook:**
+
+```
+Weekly Report — [Date Range]
+
+Active Users: 1,234 (+12% vs last week)
+Revenue: $45,678 (-3% vs last week) [BELOW TARGET]
+Conversion: 4.2% (stable)
+
+[Link to full dashboard]
+```
+
+**Email:** HTML table with metrics, sparklines optional, link to dashboard.
+
+Include:
+
+- **Historical comparison** — this week vs last week, this month vs last month
+- **Threshold alerts** — highlight metrics that crossed boundaries (above/below target)
+- **Trend indicator** — up/down/stable arrows or text
+- **Link to detail** — always link to full dashboard for drill-down
+
+### Step 5: Add Threshold Alerts
+
+For critical metrics, add separate alerts (not just in the report):
+
+- **Threshold definition** — what value triggers an alert
+- **Alert channel** — Slack DM, channel mention, PagerDuty for critical
+- **Cooldown** — don't alert again for N hours after firing
+- **Context** — include enough data in alert to understand the issue
+
+### Step 6: Present Summary
+
+Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+```
+## Reporting Pipeline Built
+
+**Metrics:** [N] | **Schedule:** [frequency] | **Delivery:** [Slack/email/both]
+
+### Report Contents
+| Metric | Comparison | Threshold |
+|--------|-----------|-----------|
+| [name] | vs last [period] | [target] |
+| ...    | ...              | ...      |
+
+### Pipeline
+- Query: [SQL files location]
+- Schedule: [cron expression / scheduler config]
+- Delivery: [Slack webhook / email / both]
+- Alerts: [N] threshold alerts configured
+
+### Files Created
+- [path to report script]
+- [path to SQL queries]
+- [path to schedule config]
+
+### Next Steps
+- [ ] Set up [Slack webhook / email credentials]
+- [ ] Test with current data
+- [ ] Confirm report recipients
+- [ ] Adjust thresholds after first week of data
+```
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/lumen/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: lumen
+description: Product analyst — metrics architecture, funnel analysis, A/B test design, retention, and growth measurement.
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
+version: 0.9.1
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+tags: ["ai-agency", "tonone"]
+compatibility: "Designed for Claude Code"
+---
+
+# Lumen — Product Analytics
+
+You are Lumen — the product analyst. Design measurement systems, analyze funnels, and run experiments.
+
+The user gave you: `{{args}}`
+
+Read the request and invoke the right skill with the Skill tool.
+
+## Skills
+
+| Skill              | Use when                                                                  |
+| ------------------ | ------------------------------------------------------------------------- |
+| `lumen-abtest`     | Design an A/B experiment — hypothesis, metric, MDE, sample size, run time |
+| `lumen-funnel`     | Funnel analysis — map drop-off points and diagnose conversion issues      |
+| `lumen-instrument` | Instrumentation plan — event taxonomy, property schema, tracking plan     |
+| `lumen-metrics`    | Metrics architecture — North Star, input tree, instrumentation spec       |
+| `lumen-recon`      | Scan existing event tracking, metric definitions, and dashboards          |
+
+Default (no args or unclear): `lumen-recon`.
+
+Invoke now. Pass `{{args}}` as args.

package/skills/lumen-abtest/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "lumen-abtest",
+  "version": "0.9.7",
+  "description": "A/B test design \u2014 produce an experiment spec with hypothesis, primary metric, MDE, sample size, run time, and decision rule. Also determines when NOT to A/B test and what to do instead. Use when asked to \"design an A/B test\", \"should we test this\", \"experiment design\", \"how do we know if this works\", \"what's the sample size\", or \"set up an experiment\".",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "lumen",
+    "skill"
+  ]
+}