$npx -y skills add softspark/ai-toolkit --skill biz-scanScans codebase for revenue opportunities, KPIs, monetization gaps. Triggers: business metrics, KPI, analytics gaps, monetization, revenue.
| 1 | # Biz Scan Command |
| 2 | |
| 3 | $ARGUMENTS |
| 4 | |
| 5 | Triggers the Business Intelligence agent to analyze the codebase for business opportunities and KPI gaps. |
| 6 | |
| 7 | ## Usage |
| 8 | |
| 9 | ```bash |
| 10 | /biz-scan [scope] |
| 11 | # /biz-scan schema : focus on database models and entity relationships |
| 12 | # /biz-scan api : focus on API endpoints and data exposure |
| 13 | # /biz-scan all : full codebase scan |
| 14 | ``` |
| 15 | |
| 16 | ## Protocol |
| 17 | |
| 18 | ### 1. Model Scan: Analyze Data Layer |
| 19 | |
| 20 | Scan for business-relevant data structures: |
| 21 | |
| 22 | ```bash |
| 23 | # Find database models, schemas, entities |
| 24 | grep -rl "model\|schema\|entity\|migration" --include="*.py" --include="*.ts" --include="*.rb" . |
| 25 | # Find ORM definitions |
| 26 | grep -rl "prisma\|sequelize\|typeorm\|sqlalchemy\|activerecord" . |
| 27 | ``` |
| 28 | |
| 29 | Catalog: entity names, relationships, fields that map to business concepts (revenue, subscription, usage, billing). |
| 30 | |
| 31 | ### 2. Logic Scan: Analyze Business Logic |
| 32 | |
| 33 | Scan controllers, services, and use cases: |
| 34 | |
| 35 | ```bash |
| 36 | # Find API endpoints and handlers |
| 37 | grep -rn "router\.\|app\.\(get\|post\|put\|delete\)\|@Controller\|@app\.route" --include="*.ts" --include="*.py" --include="*.js" . |
| 38 | # Find tracking/analytics events |
| 39 | grep -rn "track\|analytics\|event\|metric\|log_event" --include="*.ts" --include="*.py" --include="*.js" . |
| 40 | ``` |
| 41 | |
| 42 | Catalog: exposed endpoints, tracked events, feature flags, A/B tests. |
| 43 | |
| 44 | ### 3. Synthesis: Match Data vs. Business Goals |
| 45 | |
| 46 | Cross-reference findings to identify: |
| 47 | |
| 48 | | Category | What to Look For | |
| 49 | |----------|-----------------| |
| 50 | | **Missing KPIs** | Entities with no associated tracking events | |
| 51 | | **Underutilized features** | Endpoints with no analytics or feature-flag coverage | |
| 52 | | **Monetization gaps** | Subscription/billing entities without conversion tracking | |
| 53 | | **Data exposure** | Rich internal data not surfaced via API | |
| 54 | |
| 55 | ### 4. Report: Generate Opportunity Report |
| 56 | |
| 57 | Output a structured markdown report: |
| 58 | |
| 59 | ```markdown |
| 60 | ## Business Opportunity Report: [scope] |
| 61 | |
| 62 | ### KPI Coverage |
| 63 | | Entity/Feature | Tracked Events | Gap | |
| 64 | |---------------|---------------|-----| |
| 65 | | [name] | [events or "none"] | [what's missing] | |
| 66 | |
| 67 | ### Opportunities (ranked by estimated impact) |
| 68 | 1. **[Opportunity]**: [description, affected entities, suggested action] |
| 69 | |
| 70 | ### Quick Wins |
| 71 | - [ ] Add tracking to [feature], estimated lift: [low/med/high] |
| 72 | |
| 73 | ### Data Exposure Gaps |
| 74 | - [Entity] has [N fields] not exposed via any API endpoint |
| 75 | ``` |
| 76 | |
| 77 | ## Rules |
| 78 | |
| 79 | - **MUST** tie every opportunity to a concrete business metric or KPI name — "improve onboarding" is not an opportunity, "increase trial-to-paid conversion" is |
| 80 | - **MUST** rank the opportunity list by estimated impact (rough order of magnitude is enough) — alphabetical order hides the signal |
| 81 | - **NEVER** propose a new tracking event without first checking for an existing one — duplicate events corrupt analytics pipelines |
| 82 | - **CRITICAL**: output is advisory. Do not modify tracking code in the scan. The product owner decides what ships. |
| 83 | - **MANDATORY**: when the codebase has no analytics layer at all, say so explicitly and stop — the gap is "no instrumentation", not "no opportunities". |
| 84 | |
| 85 | ## Gotchas |
| 86 | |
| 87 | - ORM models and TypeScript/Zod types often drift. An entity may exist in the DB schema but be invisible to the API layer (and vice-versa) — grep both sides before declaring "no tracking coverage". |
| 88 | - Feature flags without analytics wiring are invisible to most scans. A flag can gate a feature with zero rollout data; treat a flag-without-exposure as its own gap category. |
| 89 | - "No tracking event on entity X" often means X is tracked via a parent event (e.g., `order_items` piggybacking on `order_completed`). Walk the event taxonomy one level up before calling a gap. |
| 90 | - Revenue attribution in multi-tenant apps often splits client-side (page views, clicks) from server-side (conversions). Scanning only one side produces systematically wrong conclusions about monetization coverage. |
| 91 | - Migration files may show deleted columns that live code no longer references — always check the current schema (`alembic current`, `prisma migrate status`) before treating a migration-declared field as live. |
| 92 | |
| 93 | ## When NOT to Use |
| 94 | |
| 95 | - For **implementing** a tracking change — use `/fix` or the relevant language skill |
| 96 | - For dashboard design or SQL queries — delegate to the `data-analyst` agent |
| 97 | - For generic code-quality metrics — use `/analyze` |
| 98 | - For security or CVE scans — use `/cve-scan` or `/security-patterns` |
| 99 | - When the project has no product-analytics layer configured — document the gap, do not speculate on events |