From wire
Proactive skill for answering business analytics questions using dbt's Semantic Layer, Discovery API, or direct SQL. Auto-activates when a user asks a data or metrics question against a dbt project (e.g. "What were total sales last quarter?", "Show me top customers by revenue"). Uses a 4-level escalation: Semantic Layer first, modified compiled SQL, model discovery, manifest analysis. Always exhausts all options before saying "cannot answer."
npx claudepluginhub rittmananalytics/wire-plugin --plugin wireThis skill uses the workspace's default tool permissions.
Answer business data questions using the best available method. Users asking "What were total sales last month?" or "How many active customers do we have?" should always get an answer if the data exists in the dbt project — even without a full Semantic Layer setup.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Answer business data questions using the best available method. Users asking "What were total sales last month?" or "How many active customers do we have?" should always get an answer if the data exists in the dbt project — even without a full Semantic Layer setup.
Use for:
Not for:
dbt-development skill)dbt-unit-testing skill)Keywords: "total sales", "how many", "show me", "top customers", "revenue by", "what is our", "give me a breakdown", "active users", "KPI", "metric", "trend", "last quarter", "last month", "year to date"
Activate when a user asks a question that sounds like a business analytics question in the context of a dbt project or a Wire-built data platform.
| Priority | When to use | Method | Tools needed |
|---|---|---|---|
| 1 | Semantic Layer is active | Query metrics directly | list_metrics, get_dimensions, query_metrics |
| 2 | SL has the metric but needs adjustment | Modify compiled SQL | get_metrics_compiled_sql, execute_sql |
| 3 | No SL, Discovery API available | Explore models, write SQL | get_mart_models, get_model_details, execute_sql |
| 4 | No MCP at all, in a dbt project | Analyse manifest/catalog, write SQL | Read target/manifest.json, target/catalog.json |
Never say "cannot answer" without trying all 4 levels.
When list_metrics and query_metrics are available:
list_metrics — find the relevant metricget_dimensions — verify required dimensions existquery_metrics — execute with filtersIf the Semantic Layer can answer, do so. If it can't (missing dimension, custom filter, different aggregation), move to Level 2 rather than giving up.
When the Semantic Layer has the metric but can't answer directly:
get_metrics_compiled_sql — get the resolved SQL (table names, not {{ ref() }})execute_sql — run the modified SQL-- Adding a dimension (sales_rep) not in the semantic model
WITH base AS (
-- [compiled metric SQL returned by get_metrics_compiled_sql]
)
SELECT base.*, reps.sales_rep_name
FROM base
JOIN analytics.dim_sales_reps reps ON base.rep_id = reps.id
GROUP BY base.period, reps.sales_rep_name
-- Adding a custom filter
SELECT * FROM (compiled_metric_sql) WHERE region = 'EMEA'
-- Custom categorisation
SELECT
CASE WHEN amount > 1000 THEN 'large' ELSE 'small' END AS deal_size,
SUM(amount) AS total
FROM (compiled_metric_sql)
GROUP BY 1
When no Semantic Layer but get_mart_models / get_model_details are available:
get_mart_models — always start with mart models, not staging (marts have business logic applied)get_model_details for the relevant model — understand the schema{{ ref('model_name') }}dbt show --inline "..." or execute_sqlWire naming conventions to look for: _dim / _fct suffix models are marts; stg_ are staging; int_ are integration. Prefer _fct and _dim models for analytics queries.
When in a dbt project directory but no MCP server:
target/manifest.json and target/catalog.json# Find mart models
jq '.nodes | to_entries | map(select(.key | startswith("model.") and (contains("_fct") or contains("_dim")))) | .[].value | {name: .name, schema: .schema, database: .database}' target/manifest.json
# Get column info for a specific model
jq '.nodes["model.PROJECT_NAME.MODEL_NAME"].columns' target/catalog.json
After answering (or when unable to answer), always suggest semantic layer improvements if in a dbt project:
| Gap | Suggestion |
|---|---|
| Metric doesn't exist | "Add a <metric_name> metric to your semantic model" |
| Dimension missing | "Add <dimension> to the dimensions list in the semantic model" |
| No Semantic Layer at all | "The /wire:semantic_layer-generate command can scaffold a dbt Semantic Layer for this project" |
Stay at the semantic model level — do not suggest database schema changes, ETL pipeline modifications, or "ask your data engineering team."
| Mistake | Correct approach |
|---|---|
| Saying "cannot answer" without trying Level 2–4 | Work through all 4 levels |
| Writing SQL before checking the Semantic Layer | Always check Semantic Layer first |
Querying staging models (stg_) | Use mart models (_fct, _dim) |
Reading full manifest.json without filtering | Use jq to extract just what you need |
| Suggesting ETL changes for a missing metric | Suggest adding it to the semantic model |
DATE_TRUNC, DATE_SUB, TIMESTAMP_TRUNC, etc.)orders_fct, customers_dim, products_dim. Staging: stg_<source>__<entity>. Integration: int_<entity>.dbt-mcp-server skill) unlocks Levels 1–3. Without it, Level 4 (manifest parsing) is the fallback./wire:semantic_layer-generate produce LookML (Looker) by default. If the project has also set up dbt Semantic Layer (MetricFlow), the dbt-semantic-layer skill covers that path.