// When the user needs to define KPIs, set up a metrics framework, choose what to measure, or says 'what should we track,' 'define our metrics,' 'KPIs,' 'north star metric,' 'how do we measure success,' 'OKRs,' 'dashboard metrics,' or is starting a new product/feature and needs to decide what data matters.
| name | metrics-framework |
| description | When the user needs to define KPIs, set up a metrics framework, choose what to measure, or says 'what should we track,' 'define our metrics,' 'KPIs,' 'north star metric,' 'how do we measure success,' 'OKRs,' 'dashboard metrics,' or is starting a new product/feature and needs to decide what data matters. |
You are designing a metrics framework that drives better decisions — not a dashboard that looks impressive.
Before choosing any metric, answer:
If there's no action tied to the metric, it's a vanity metric. Skip it.
One metric that best captures the value your product delivers to users:
| Business Type | Example North Star |
|---|---|
| SaaS | Weekly active workspaces |
| Marketplace | Transactions completed |
| Media/Content | Time spent reading |
| E-commerce | Purchases per month |
| Developer Tool | Builds triggered |
The north star must be:
Break the north star into a tree of input metrics:
North Star: Weekly Active Workspaces
├── New workspace activations
│ ├── Signups
│ ├── Signup → Activation rate
│ └── Time to activation
├── Returning workspaces
│ ├── D7 retention
│ ├── D30 retention
│ └── Feature engagement score
└── Resurrected workspaces
├── Re-engagement emails sent
└── Re-engagement conversion rate
For each metric:
Three tiers:
## Metrics Framework: [Product/Feature]
### North Star
[Metric name]: [Current value] → [Target] by [Date]
### Input Metrics
| Metric | Current | Target | Owner | Update Frequency |
|--------|---------|--------|-------|-----------------|
| ... | ... | ... | ... | ... |
### Alerts
- [Metric] drops below [threshold] → notify [team]
### What We're NOT Tracking (and why)
- [Metric] — [reason it's not useful right now]
Learn from corrections, mistakes, and discoveries during conversations. When the user corrects you, when something fails unexpectedly, or when you discover a project-specific pattern worth remembering — record it as a learning so future sessions benefit automatically.
When the user wants to draft tweets, plan threads, post to Twitter/X, or manage their Twitter presence
When reviewing UI/UX for quality, consistency, and polish. Use when the user says 'review the design,' 'check the UI,' 'does this look good,' 'design audit,' 'UX review,' or 'polish the frontend.' Also use after implementing any user-facing feature to catch visual and interaction issues before shipping.
Red-green-refactor cycle for test-driven development
When reviewing product decisions, feature scope, or user-facing changes from a founder/CEO perspective. Use when the user says 'does this make sense,' 'should we build this,' 'review the product,' 'is this good enough,' 'founder review,' 'product sense check,' or before any significant launch. This is the strategic taste layer — not engineering quality, but product quality.
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.