add folders in plugins

This commit is contained in:
mohitagw15856
2026-04-02 09:19:07 +01:00
parent 7ad6ec62fa
commit f9b79a48b9
39 changed files with 2465 additions and 0 deletions
BIN
View File
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 36 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 36 (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 23 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:**
[23 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
[23 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):** [35 metrics — outcomes only]
- **Team view (daily):** [710 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 34 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
[13 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?"