add folders in plugins
This commit is contained in:
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,122 @@
|
||||
---
|
||||
name: dashboard-brief
|
||||
description: "Convert a business question into a complete dashboard specification. Use when asked to design a dashboard, create a dashboard spec or brief, plan a BI report, or define what charts and metrics a dashboard should include. Produces a structured spec with metrics, dimensions, chart types, filters, and layout guidance."
|
||||
---
|
||||
|
||||
# Dashboard Brief Skill
|
||||
|
||||
This skill converts a business question or monitoring need into a complete, implementation-ready dashboard specification. The output gives a data engineer or BI developer everything they need to build without a follow-up meeting.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The business question this dashboard should answer** (e.g. "How is our activation funnel performing this week?")
|
||||
- **Primary audience** (exec / product team / operations / customer success / engineering)
|
||||
- **Refresh cadence** (real-time / hourly / daily / weekly)
|
||||
- **Data sources available** (e.g. Postgres, BigQuery, Mixpanel, Salesforce, Jira)
|
||||
- **BI tool being used** (Looker / Metabase / Tableau / Power BI / Grafana / Custom / Unknown)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Dashboard Brief: [Dashboard Name]
|
||||
|
||||
**Business Question:** [The question this dashboard answers — verbatim from inputs or refined]
|
||||
**Audience:** [Who uses this]
|
||||
**Refresh Rate:** [Real-time / Hourly / Daily / Weekly]
|
||||
**Data Sources:** [List]
|
||||
**BI Tool:** [Tool or Unknown]
|
||||
|
||||
---
|
||||
|
||||
## Section 1: Key Metrics (KPI Cards)
|
||||
|
||||
List the headline numbers that should appear at the top of the dashboard as KPI cards.
|
||||
|
||||
| Metric | Definition | Data Source | Comparison |
|
||||
|---|---|---|---|
|
||||
| [Metric name] | [How it's calculated] | [Table/source] | [vs. last week / vs. target / MoM] |
|
||||
|
||||
Aim for 3–6 KPI cards. More than 6 is noise.
|
||||
|
||||
---
|
||||
|
||||
## Section 2: Charts & Visualisations
|
||||
|
||||
For each chart, specify:
|
||||
|
||||
### Chart [N]: [Chart Title]
|
||||
|
||||
- **Chart type:** [Line / Bar / Stacked bar / Pie / Funnel / Heatmap / Table / Scatter]
|
||||
- **Why this chart type:** [One sentence — why this type suits this data]
|
||||
- **X-axis / Rows:** [Dimension — e.g. Date, User segment, Product]
|
||||
- **Y-axis / Values:** [Metric — e.g. Count of active users, Revenue]
|
||||
- **Breakdown/colour:** [Optional secondary dimension — e.g. by Plan tier, by Channel]
|
||||
- **Data source:** [Table or source]
|
||||
- **Filters:** [Any default filters applied — e.g. "Exclude internal test accounts"]
|
||||
- **Key insight to surface:** [What pattern or signal this chart should help the viewer spot]
|
||||
|
||||
---
|
||||
|
||||
## Section 3: Filters & Controls
|
||||
|
||||
Global filters available to dashboard viewers:
|
||||
|
||||
| Filter | Type | Default | Options |
|
||||
|---|---|---|---|
|
||||
| Date range | Date picker | Last 30 days | Custom |
|
||||
| [Segment filter] | Dropdown | All | [List relevant values] |
|
||||
| [Other filter] | Multi-select | All | [List relevant values] |
|
||||
|
||||
---
|
||||
|
||||
## Section 4: Layout Recommendation
|
||||
|
||||
Describe the dashboard layout in plain terms:
|
||||
|
||||
```
|
||||
[ROW 1 — KPI Cards]: [Metric 1] | [Metric 2] | [Metric 3] | [Metric 4]
|
||||
[ROW 2 — Primary chart, full width]: [Chart name]
|
||||
[ROW 3 — Two charts side by side]: [Chart A] | [Chart B]
|
||||
[ROW 4 — Supporting table, full width]: [Table name]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Section 5: Data Requirements
|
||||
|
||||
List any data transformations, joins, or derived fields needed:
|
||||
|
||||
| Derived Field | Logic | Source Tables |
|
||||
|---|---|---|
|
||||
| [Field name] | [How it's calculated] | [Tables involved] |
|
||||
|
||||
Flag any fields that may not exist in current data infrastructure.
|
||||
|
||||
---
|
||||
|
||||
## Section 6: Access & Ownership
|
||||
|
||||
- **Dashboard owner:** [Leave for user to fill]
|
||||
- **Who can edit:** [Leave for user to fill]
|
||||
- **Who can view:** [Leave for user to fill]
|
||||
- **Review cadence:** [When should this dashboard be reviewed for relevance?]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every chart has a stated "key insight to surface" — not just "show the data"
|
||||
- [ ] KPI cards are 3–6 (not more)
|
||||
- [ ] Chart types are justified
|
||||
- [ ] Layout follows visual hierarchy (summary → detail)
|
||||
- [ ] Data requirements section flags any missing fields
|
||||
- [ ] Filters are practical and don't require IT to configure
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Design a dashboard to track [business process]"
|
||||
- "Give me a spec for a [team] performance dashboard"
|
||||
- "What should go on a [topic] dashboard?"
|
||||
- "Write a dashboard brief for our [metric] monitoring"
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: metrics-framework
|
||||
description: "Build a metrics framework for any product, team, or business. Use when asked for a metrics tree, KPI framework, North Star metric, AARRR funnel, HEART framework, or OKR metrics. Produces a structured metrics hierarchy from North Star down to leading indicators, with measurement guidance."
|
||||
---
|
||||
|
||||
# Metrics Framework Skill
|
||||
|
||||
This skill builds a complete metrics framework tailored to a product or business. It connects the North Star metric to actionable leading indicators, making it clear which metrics to track, which to optimise, and how they relate to each other.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product or business description** (one paragraph is enough)
|
||||
- **Business model** (SaaS / Marketplace / E-commerce / Consumer app / B2B / Other)
|
||||
- **Stage** (Pre-PMF / Growth / Scale / Mature)
|
||||
- **Framework preference** (if they have one): North Star + Metric Tree / AARRR / HEART / OKRs / Custom
|
||||
- **Primary goal this quarter** (e.g. grow activation, reduce churn, increase revenue)
|
||||
|
||||
If no framework preference is given, recommend the best fit based on stage and business model.
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Framework Recommendation (if not specified)
|
||||
|
||||
Explain in 2–3 sentences why you're recommending this framework for their context.
|
||||
|
||||
---
|
||||
|
||||
### 2. North Star Metric
|
||||
|
||||
**[Metric Name]:** [Definition — exactly what is measured and how]
|
||||
|
||||
**Why this is the right North Star for this business:**
|
||||
[2–3 sentences. It should reflect customer value delivered, not just revenue or activity. Explain what behaviour it captures and why maximising it correlates with long-term business health.]
|
||||
|
||||
**How to measure it:** [Formula or data source]
|
||||
**Current baseline:** [Leave as [ADD BASELINE] for user to fill]
|
||||
**Target:** [Leave as [ADD TARGET] for user to fill]
|
||||
|
||||
---
|
||||
|
||||
### 3. Metric Tree
|
||||
|
||||
Show how supporting metrics roll up to the North Star. Format as a hierarchy:
|
||||
|
||||
```
|
||||
[North Star Metric]
|
||||
├── [Driver 1: e.g. Acquisition]
|
||||
│ ├── [L2 metric: e.g. Organic signups / week]
|
||||
│ └── [L2 metric: e.g. Paid CAC by channel]
|
||||
├── [Driver 2: e.g. Activation]
|
||||
│ ├── [L2 metric: e.g. % users completing onboarding within 7 days]
|
||||
│ └── [L2 metric: e.g. Time to first value action]
|
||||
└── [Driver 3: e.g. Retention]
|
||||
├── [L2 metric: e.g. Day 30 retention rate]
|
||||
└── [L2 metric: e.g. Feature adoption depth]
|
||||
```
|
||||
|
||||
For each L2 metric, provide:
|
||||
- **Definition:** [What exactly is measured]
|
||||
- **Why it matters:** [How it connects to the North Star]
|
||||
- **Leading or lagging?** [Leading = predictive / Lagging = outcome]
|
||||
- **How to measure:** [Data source or calculation]
|
||||
|
||||
---
|
||||
|
||||
### 4. Counter-Metrics
|
||||
|
||||
[2–3 metrics to watch that prevent optimising the North Star in ways that damage the business. E.g. "If we optimise for signups, we need to watch spam account rate. If we optimise for engagement, we need to watch support ticket volume."]
|
||||
|
||||
---
|
||||
|
||||
### 5. Dashboard Recommendation
|
||||
|
||||
Suggest a 3-tier dashboard structure:
|
||||
- **Exec view (weekly):** [3–5 metrics — outcomes only]
|
||||
- **Team view (daily):** [7–10 metrics — leading indicators + outputs]
|
||||
- **Diagnostic view (on demand):** [Metrics to drill into when something looks wrong]
|
||||
|
||||
---
|
||||
|
||||
### 6. Metric Health Check Questions
|
||||
|
||||
[5 questions the team should ask in their weekly metrics review to turn numbers into insights. e.g. "Is our activation rate improving while retention stays flat? That suggests onboarding quality issue, not a product-market fit problem."]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] North Star reflects customer value, not just business activity
|
||||
- [ ] Metric tree has 3–4 distinct drivers (not all one category)
|
||||
- [ ] Each L2 metric is classified as leading or lagging
|
||||
- [ ] Counter-metrics are included to prevent perverse incentives
|
||||
- [ ] Dashboard tiers are tailored to the product stage
|
||||
- [ ] All metric definitions are unambiguous (formula or clear description)
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a metrics framework for [product]"
|
||||
- "What should our North Star metric be?"
|
||||
- "Create a KPI tree for [business]"
|
||||
- "Give me an AARRR breakdown for [product]"
|
||||
- "What metrics should our [team type] team track?"
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
name: sql-query-explainer
|
||||
description: "Explain, optimise, or translate SQL queries into plain language. Use when asked to explain a SQL query, optimise slow SQL, write a data dictionary, translate SQL to plain English for non-technical stakeholders, or review a query for correctness and performance. Works across PostgreSQL, MySQL, BigQuery, Snowflake, and standard SQL."
|
||||
---
|
||||
|
||||
# SQL Query Explainer Skill
|
||||
|
||||
This skill explains SQL queries in plain language, identifies optimisation opportunities, and helps communicate data logic to non-technical stakeholders. It also writes and documents new queries from natural language descriptions.
|
||||
|
||||
## Modes
|
||||
|
||||
Detect which mode the user needs based on their request:
|
||||
|
||||
1. **Explain** — Translate existing SQL into plain English
|
||||
2. **Optimise** — Review SQL for performance issues and suggest improvements
|
||||
3. **Write** — Generate SQL from a natural language description
|
||||
4. **Document** — Produce a data dictionary or query documentation
|
||||
|
||||
---
|
||||
|
||||
## Mode 1: Explain
|
||||
|
||||
When given a SQL query, produce:
|
||||
|
||||
### Plain English Summary
|
||||
[1–3 sentences. What does this query do? What data does it return? Write as if explaining to a business analyst, not a developer.]
|
||||
|
||||
### Step-by-Step Walkthrough
|
||||
|
||||
Break the query into logical sections. For each section:
|
||||
- Quote the SQL clause
|
||||
- Explain what it does in plain English
|
||||
- Flag any complexity (e.g. window functions, subqueries, CTEs)
|
||||
|
||||
### What the Result Looks Like
|
||||
|
||||
[Describe the shape of the output: "Returns one row per user, with columns for X, Y, Z. Ordered by [field] descending."]
|
||||
|
||||
### Potential Issues to Flag
|
||||
|
||||
- [Gotchas, edge cases, or implicit assumptions in this query]
|
||||
- [e.g. "This will include NULLs in the user_id column if the LEFT JOIN finds no match"]
|
||||
|
||||
---
|
||||
|
||||
## Mode 2: Optimise
|
||||
|
||||
When asked to optimise a query, produce:
|
||||
|
||||
### Performance Assessment
|
||||
|
||||
Rate overall: 🟢 Well-optimised / 🟡 Some improvements possible / 🔴 Significant issues
|
||||
|
||||
### Issues Found
|
||||
|
||||
For each issue:
|
||||
|
||||
**Issue [N]: [Short name, e.g. "Missing index on join column"]**
|
||||
- **What it is:** [Plain explanation]
|
||||
- **Why it matters:** [Performance impact — e.g. "Full table scan on a 10M row table"]
|
||||
- **Fix:**
|
||||
```sql
|
||||
-- Before
|
||||
[original snippet]
|
||||
|
||||
-- After
|
||||
[improved snippet]
|
||||
```
|
||||
- **Expected improvement:** [Estimate if possible]
|
||||
|
||||
### Optimisation Checklist
|
||||
|
||||
- [ ] SELECT * used? (Replace with specific columns)
|
||||
- [ ] Implicit type conversions on JOIN/WHERE columns?
|
||||
- [ ] Missing indexes on JOIN or WHERE columns?
|
||||
- [ ] N+1 patterns (queries inside loops)?
|
||||
- [ ] DISTINCT used where GROUP BY would be faster?
|
||||
- [ ] Window functions used where a subquery would be clearer/faster?
|
||||
- [ ] CTEs re-used or materialised unnecessarily?
|
||||
- [ ] Large IN() lists that could use a JOIN instead?
|
||||
|
||||
---
|
||||
|
||||
## Mode 3: Write
|
||||
|
||||
When given a natural language description, generate the SQL query and then explain it using Mode 1.
|
||||
|
||||
Ask the user to confirm:
|
||||
- **Database/dialect** (PostgreSQL / MySQL / BigQuery / Snowflake / SQLite / Standard SQL)
|
||||
- **Table and column names** (if known; otherwise use descriptive placeholder names like `users`, `orders`, `user_id`)
|
||||
- **Any filters, sorting, or aggregation requirements**
|
||||
|
||||
Produce:
|
||||
1. The SQL query with inline comments
|
||||
2. Plain English explanation (Mode 1 format)
|
||||
|
||||
---
|
||||
|
||||
## Mode 4: Document
|
||||
|
||||
When asked to create documentation for a query or table:
|
||||
|
||||
### Query Documentation
|
||||
|
||||
```
|
||||
Query: [Name]
|
||||
Purpose: [One sentence — what business question this answers]
|
||||
Author: [If provided]
|
||||
Last reviewed: [If provided]
|
||||
|
||||
Inputs:
|
||||
- Table: [table_name] — [what it contains]
|
||||
- Filter: [any WHERE conditions and their business meaning]
|
||||
|
||||
Output columns:
|
||||
| Column | Type | Description |
|
||||
|--------|------|-------------|
|
||||
| [name] | [type] | [plain English description] |
|
||||
|
||||
Assumptions:
|
||||
- [Any implicit assumptions the query makes]
|
||||
|
||||
Known limitations:
|
||||
- [Edge cases not handled, data quality dependencies, etc.]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Plain English explanation avoids SQL jargon
|
||||
- [ ] Optimisation suggestions include before/after SQL
|
||||
- [ ] Written queries include inline comments
|
||||
- [ ] Output shape is described (columns, row grain, ordering)
|
||||
- [ ] Dialect-specific syntax is flagged when non-standard
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Explain this SQL query: [paste query]"
|
||||
- "Optimise this slow query: [paste query]"
|
||||
- "Write a SQL query that [natural language description]"
|
||||
- "Document this query for my non-technical stakeholders"
|
||||
- "Why is this query returning unexpected results?"
|
||||
Reference in New Issue
Block a user