Wire is a structured delivery system for data platform engagements, built on top of Claude Code and Gemini CLI. It encodes analytics engineering methodology as workflow specifications that the AI reads before generating anything so that output follows consistent patterns, traces back to requirements and can be validated automatically rather than having to be manually eyeballed.
Instead of prompting an AI to write a dbt model and hoping it follows your conventions, you run /wire:dbt-generate and the AI receives a specification that tells it exactly which upstream design decisions to read, which naming patterns to apply, which tests to include, and how to update the project status tracker when it's done.
Full documentation at docs.rittmananalytics.com
AI code generation can produce syntactically valid SQL. Where it falls down is methodology: consistent naming conventions across 15+ models, correct surrogate key patterns, relationship test coverage on every foreign key, traceability from business requirement to warehouse column. These failures are not knowledge failures, as the models typically do know the conventions. They are, however, context and control failures as without a structured methodology constraining generation, LLMs improvise and the accumulated inconsistencies across a project erode the value of using AI at all.
Wire closes this gap by encoding the methodology as workflow specifications that the AI reads before generating anything. Each specification tells the AI which upstream artifacts to read, which templates to follow, which validation checks to apply, and how to update the project state tracker. The result is of typically of an equivalent level of quality of a senior analytics engineer who has been on the project for months, because it was generated by an AI that read every design decision and requirement that a senior analytics engineer would have absorbed.
Wire does not replace consultants or developers. It gives them an AI that works quickly and consistently, freeing them to focus on client relationships, design decisions and the judgement calls that automation cannot make.
- Direct the work, don't memorise the commands (v4.0.0) — on Claude Code, say what you want done and Wire works out which command that is from the release type's own definition, runs it, reports what it did in plain words with the command named in the closing line, and stops where a decision is yours. Every step runs the real command, so
status.md, the execution log, the precondition gate and the artifacts on disk are identical to typing it. Reviews are never run without your ruling; parked decisions are listed at the start of every session; andorchestration.mode: manualin the engagement context restores the pre-4.0 behaviour exactly. Three tiers: one human directs, one session orchestrates, and the specialist agents run as flat lanes with their own state files - 341 slash commands covering the full delivery lifecycle: Discovery (Shape Up + RA Canonical SOP), Requirements, Design, Development, Testing, Deployment, Enablement, Platform Migration, Agentic Data Stack
- 12 release types matching common engagement shapes: Shape Up discovery, SOP / Canonical discovery (sponsor-facing Findings Playback), full platform builds, pipeline-only, dbt development, dashboard extensions, dashboard-first rapid dev, enablement, platform migration (BigQuery ↔ Snowflake), agentic data stack (governed self-service analytics with eval suite), droughty (schema introspection and base-layer generation from live warehouses), and custom (bespoke deliverables defined from SoW documents) — every release type is now backed by a machine-readable process definition (see Precondition Gate below), not just documentation
- Two-tier engagement structure separating long-running client context from individual scoped releases
- Generate / validate / review lifecycle for every artifact: structured generation, automated checks, stakeholder sign-off
- Precondition gate (v4.0.0) — every command blocks by default on an unmet prerequisite; overriding requires a recorded name and reason, so skipping a step on purpose is always a visible, attributable decision rather than something that silently happened
- Process and data model registries (v4.0.0) — release-type sequencing and command specs are sourced from a private, branch-protected
wire-process-registry; an optional, automatically-detected canonical data model registry (wire-data-model-registry) proposes industry-standard entity structures without ever bundling proprietary content into this public plugin — see docs.rittmananalytics.com/en/latest/docs/advanced/registries - Business rules discovery (v4.0.0) — an optional first step on any development release that establishes what a metric actually means before design starts. One register per business domain, holding every competing definition with the file it came from, what they disagree on, the decision and who approved it. A rule nobody has decided is recorded as
unknownrather than left out, and each rule with a legacy definition generates a reconciliation query that runs immediately rather than surfacing as a mismatch in testing - Modality models as a design input (v4.0.0) — where a client already models their data in Modality,
/wire:utils-modality-linkpoints the release at it and the conceptual model, logical model and pipeline design read entities, sources and cardinality from the existing.mmlfiles rather than deriving them. The requirements are still read, and the difference between the two is raised as a finding rather than resolved silently - Modelling-led discovery (v4.0.0) —
sop_discoverynow offers two routes through the same three pillars.diagnosticis the canonical playbook;modelling_ledreplaces the three analyses with a current-state appraisal and a signed-off conceptual and logical model, and produces the roadmap before the playback because it is one of the five things the sponsor signs off. Release types can now declare profiles that enable or disable phases and override a gate, so the ordering is enforced rather than requested - Logical model (v4.0.0) — the step between the conceptual and the physical model that Wire previously skipped: keys, cardinality, identity resolution with attributed precedence, normalisation, and attribution rules with their remainder handling. Those decisions were being made implicitly inside
data_model-generateand arriving already expressed as dbt models. Optional infull_platform, standard in a modelling-led discovery - Plain Language by default: the plugin ships a
Plain Languageoutput style that activates automatically while Wire is enabled, so every response is written in simple, concise, jargon-free English. Generated artifacts are unaffected (they follow their own templates and the reference-legibility convention); override per project in.claude/settings.local.jsonor by editing the style - Status reconciliation (
/wire:status-sync) for work done outside command runs: diffs recorded state against git history, files on disk, and the execution log, then repairs status files, sprint-plan story states, and session history with consultant confirmation - 27 ad-hoc development skills that activate automatically during coding work (dbt, LookML, Dagster, Python, Fivetran, Airbyte, Coupler.io, RudderStack, Segment, Looker, Snowflake, Hightouch, BigQuery, Cloud Run, gcloud) without any explicit invocation, plus 26 Amplitude product-analytics skills for working with an Amplitude instance
- Wire Agents — 13 specialist subagents (dbt developer, semantic layer developer, pipeline engineer, migration specialist, and 9 others) dispatched automatically on every generate and validate command.
/wire:delegatecomputes a full parallel/sequential execution plan across all pending work, with fan-out parallelism for large model sets (layers stay sequential; agents within each layer run in parallel). Under the director model they run as lanes: own tree, own state file rewritten after each completed item, and no writes tostatus.md— the orchestrating session is the single writer of the record - Release claim and parked decisions (v4.0.0) — a release records who is driving it, so a second session offers to join as reviewer or take over after a 30-minute stall rather than dispatching into work someone else is running. Decisions waiting on you are a list in
status.md, reported first thing every session - Attribution (v4.0.0) — execution-log rows carry
ByandSession(typed,orchestrator, a lane label, orautopilot), and telemetry carries the same asinvoked_by. Older four-column log rows stay valid and are never rewritten - Autopilot mode for autonomous end-to-end delivery
- Jira and Linear integration for issue tracking synced to the artifact lifecycle
- Confluence and Notion integration for client-facing document review
- Fathom integration for surfacing relevant meeting transcript context during reviews
- Runs on Claude Code (Anthropic) and Gemini CLI (Google)
Wire is distributed as a Claude Code plugin and a Gemini CLI extension. Installing the plugin embeds every Wire command inline — no framework files need to exist in your project repository.
Plugins provide the 261 /wire:* commands. Each command file contains its full workflow specification, so the AI receives complete instructions as context at invocation time.
Skills sit alongside commands but work differently. They activate automatically during ad-hoc coding work without any explicit invocation. When you start writing a dbt model, the dbt development skill provides naming conventions, SQL style rules, and testing patterns as background context. The following skills are included:
| Skill | Activates when… |
|---|---|
dbt-development |
Writing dbt models, tests, or documentation |
dbt-migration |
Migrating dbt projects across platforms |
dbt-fusion |
Resolving dbt Core to Fusion migration errors |
dbt-mcp-server |
Configuring the dbt MCP server |
dbt-analytics-qa |
Answering business questions from dbt data |
dbt-dag |
Generating lineage diagrams |
dbt-unit-testing |
Writing dbt unit tests |
dbt-semantic-layer |
Working with the dbt Semantic Layer |
dbt-troubleshooting |
Diagnosing dbt errors |
lookml-content-authoring |
Writing LookML views, explores, and dashboards |
looker-dashboard-mockup |
Generating HTML dashboard mockups |
dagster |
Writing Dagster asset definitions and pipelines |
dignified-python |
Writing production-quality Python |
fivetran |
Configuring Fivetran connectors via MCP |
airbyte |
Managing Airbyte connections and ingestion via the Airbyte Agent MCP server |
coupler-io |
Managing Coupler.io dataflows (ingestion and reverse ETL) via MCP |
rudderstack |
Managing RudderStack sources, destinations, and tracking plans via MCP |
segment |
Working with Twilio Segment sources, destinations, and tracking plans |
snowflake-development |
Writing queries, designing objects, auditing, and migrating Snowflake via MCP |
hightouch |
Auditing and migrating Hightouch reverse ETL syncs via the Hightouch REST API |
bigquery-basics |
Managing BigQuery datasets, tables, jobs, SQL, and BigQuery ML |
cloud-run-basics |
Deploying Cloud Run services, jobs, and worker pools for pipelines |
gcloud |
Running gcloud CLI commands safely, with validation and a safety denylist |
google-cloud-recipe-auth |
Authenticating to Google Cloud (ADC, service identities, secure access) |
google-cloud-waf-cost-optimization |
Cost-optimization review against the Google Cloud Well-Architected Framework |
google-cloud-waf-security |
Security-posture review against the Google Cloud Well-Architected Framework |
research |
Conducting technical research (findings auto-saved to .wire/research/) |
MCP servers connect Wire to external systems. Configure them once and all commands that need them use them automatically:
| MCP Server | Purpose |
|---|---|
| Atlassian | Jira issue tracking and Confluence document store |
| Linear | Linear issue tracking |
| Fathom | Meeting transcript search during reviews |
| Notion | Notion document store |
| Context7 | Up-to-date library documentation |
| Fivetran | Create, configure, and monitor Fivetran connectors and destinations |
| Airbyte | AI agent connector queries via the Airbyte Agent MCP server |
| Coupler.io | Dataflow management, dataset inspection, and reverse ETL |
| RudderStack | Event tracking, tracking plans, and data catalog management |
| Snowflake | Direct SQL execution against Snowflake via the Snowflake MCP server |
| Amplitude | Product analytics — charts, dashboards, experiments, session replay, instrumentation, and taxonomy |
Amplitude product analytics skills. Wire bundles the official Amplitude AI skills (MIT licence) for administering and working with an Amplitude instance through the Amplitude MCP server. They activate automatically when relevant and cover seven areas:
| Area | Skills |
|---|---|
| Core analytics | create-chart, create-dashboard, analyze-chart, analyze-dashboard |
| Product insights | analyze-experiment, monitor-experiments, analyze-feedback, analyze-account-health, discover-opportunities, compare-user-journeys |
| Session replay & debugging | debug-replay, replay-ux-audit, diagnose-errors, monitor-reliability |
| AI agent analytics | analyze-ai-topics, investigate-ai-session, monitor-ai-quality, review-agent-insights |
| Instrumentation | diff-intake, discover-event-surfaces, discover-analytics-patterns, instrument-events, add-analytics-instrumentation, taxonomy |
| Briefings | daily-brief, weekly-brief |
A typical instrumentation flow chains diff-intake → discover-event-surfaces → instrument-events, with discover-analytics-patterns keeping new tracking consistent with existing conventions. The taxonomy skill aligns naturally with Wire's existing CDP work (Segment, RudderStack).
- Claude Code (CLI or desktop app) or Gemini CLI
- Git
/plugin marketplace add rittmananalytics/wire-plugin
/plugin install wire@rittman-analytics
/reload-plugins
The /reload-plugins step activates the plugin in the current session — no Claude Code restart needed. All /wire:* commands are then available.
gemini extensions install https://github.com/rittmananalytics/wire-extensionCommands are available as /wire * with spaces rather than colons.
MCP servers are optional but enable issue tracking, document store sync, and meeting transcript context. Add whichever you need:
# Atlassian (Jira + Confluence)
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp
# Linear
claude mcp add --transport http linear https://mcp.linear.app/sse
# Fathom (meeting transcripts — requires a self-hosted or managed Fathom MCP server)
claude mcp add --transport http fathom https://your-fathom-mcp-server/mcp
# Notion
claude mcp add --transport http notion https://mcp.notion.com/mcp
# Fivetran (requires API key and secret from Fivetran dashboard → Account → Settings → API Config)
claude mcp add --transport http fivetran https://fivetran-mcp-server-r6jhgfswwa-nw.a.run.app/mcp \
-H "X-Fivetran-API-Key: YOUR_API_KEY" \
-H "X-Fivetran-API-Secret: YOUR_API_SECRET"
# Airbyte Agent MCP (OAuth — browser sign-in on first connect)
claude mcp add --transport http airbyte-agent https://mcp.airbyte.ai/mcp
# Coupler.io (Personal Access Token from Coupler.io app → Settings → MCP)
claude mcp add --transport http coupler-io https://mcp.coupler.io/mcp/ \
-H "Authorization: Bearer YOUR_COUPLER_TOKEN"
# RudderStack (OAuth via mcp-remote — requires Node.js / npx on PATH)
claude mcp add rudderstack --command "npx -y mcp-remote https://mcp.rudderstack.com/mcp"
# Snowflake (available via Claude.ai native connector, or self-hosted — see USER_GUIDE §MCP Tunnels)
claude mcp add snowflake --command "npx -y mcp-remote https://mcp.snowflake.com/mcp"Run /wire:mcp at any time to check connection status, update endpoints, or force re-authentication.
/wire:new
Wire asks for a client name, engagement type, first release type, and an optional Statement of Work path. It creates the .wire/ folder structure and, if you chose a discovery release, begins the scoping workflow.
Every Wire engagement uses a two-tier layout in .wire/:
.wire/
engagement/
context.md # client objectives, stakeholders, current-state architecture
sow.md # Statement of Work (copied at setup)
calls/ # meeting notes and call transcripts
releases/
01-discovery/ # problem definition, pitch, release brief, sprint plan
02-pipeline/ # data pipeline and dbt transformation
03-dashboards/ # client-facing reporting layer
research/
sessions/ # technical research findings (auto-saved by the research skill)
The engagement folder holds everything that spans the whole client relationship. Releases are scoped, time-boxed units of delivery, each with its own status.md tracking file and execution_log.md recording every command run against it.
Direct it. Say what you want done — "new engagement from this SOW", "run what's next", "approve it and carry on" — and Wire computes what is runnable from the release type's definition, runs it, tells you what it did (naming the command in the closing line), and stops at every review gate for your decision. This is the default on Claude Code from v4.0.0.
Type it. Every command still works exactly as before, and the command name is printed before each directed run so you learn them as you go. Set orchestration.mode: manual in .wire/engagement/context.md for a whole engagement, or say "you drive" for one session. Gemini CLI stays command-driven throughout.
Either way the same command files run and the record on disk is identical.
Every artifact follows the same three-step lifecycle:
Generate reads upstream artifacts (requirements, design decisions, prior models), applies Wire methodology templates, and produces the artifact. Output is written to the release folder and the status tracker is updated.
Validate runs automated checks against the generated artifact. For a dbt model this covers naming convention compliance, test coverage, and relationship validation. For a requirements document it checks completeness against the SOW. The result is a structured PASS/FAIL report with specific issues identified.
Review presents the artifact for stakeholder sign-off. Wire surfaces relevant meeting transcript context from Fathom, document store comments from Confluence or Notion, and any prior reviewer feedback. The reviewer approves, requests changes, or rejects. Approval gates the next phase.
Each command has a matching validate and review counterpart: /wire:requirements-generate, /wire:requirements-validate, /wire:requirements-review.
| Type | release_type |
Scope | Typical duration |
|---|---|---|---|
| Discovery (Shape Up) | discovery |
Problem definition, pitch, release brief, sprint plan | 1–2 weeks |
| Discovery (SOP / Canonical) | sop_discovery |
Two profiles. diagnostic: stakeholder interviews, three analyses, sponsor Findings Playback. modelling_led: current-state appraisal plus a signed-off conceptual and logical model in place of the analyses, with the roadmap signed off at the playback |
3–6 weeks |
| Full Platform | full_platform |
Pipeline through dbt, semantic layer, and dashboards | 2–3 weeks |
| Dashboard-First | dashboard_first |
Visual mocks drive the data model; seed data enables early dbt work | 1–2 weeks |
| Pipeline + dbt | pipeline_only |
New data pipeline and transformation layer | 1–2 weeks |
| dbt Development | dbt_development |
Analytics engineering on existing infrastructure | 1 week |
| Dashboard Extension | dashboard_extension |
New dashboards on an existing semantic layer | 3–5 days |
| Enablement | enablement |
Training and documentation for an existing platform | 2–3 days |
| Agentic Data Stack | agentic_data_stack |
Overlay for an existing data platform (warehouse + dbt + BI tool) — audits governance maturity, extends the semantic layer, generates per-domain knowledge skills and a CI-wired eval suite, delivers an installable agentic data stack skill. Requires an existing dbt project; not a platform build. | 4–6 weeks |
| Platform Migration | platform_migration |
Warehouse-to-warehouse migration (BigQuery ↔ Snowflake) with source audits, batched dbt translation, equivalency validation and a gated cutover. Also covers tenant carve-outs. | 6–12 weeks |
| Droughty | droughty |
Schema introspection against a live warehouse: entity-relationship diagrams, field documentation, data-quality reporting, and base LookML or dbt test generation. Standalone, or an optional phase inside another release. | 2–5 days |
| Custom | custom |
Bespoke deliverables derived from SoW — Wire generates project-scoped specs | Varies |
The following shows a typical command sequence for delivering a new data pipeline and dbt transformation layer.
1. Create the engagement and release
/wire:new
Select pipeline_only as the release type. Wire creates .wire/engagement/ and .wire/releases/01-pipeline/.
2. Begin work — context loads automatically
The engagement-context skill fires on your first message, reads the release status, surfaces any prior research, and outputs a brief context summary. No session command needed. Use /wire:plan for an optional structured planning ritual.
3. Extract requirements
/wire:requirements-generate
Wire reads the SOW and any call transcripts in engagement/calls/ and produces a structured requirements specification. Run /wire:requirements-validate to check it, then /wire:requirements-review for sign-off.
4. Design the pipeline architecture
/wire:pipeline_design-generate
Produces a pipeline architecture document covering source systems, replication strategy, and data flow. Validate and review as above before proceeding.
5. Generate the pipeline
/wire:pipeline-generate
For a Fivetran engagement, this configures connectors via the Fivetran MCP server and produces a pipeline_connections.md record. For a Python pipeline it generates the pipeline code.
6. Generate dbt models
/wire:dbt-generate
Wire reads the pipeline design and requirements and generates staging, integration, and warehouse dbt models following the three-layer naming convention, with tests and documentation.
7. Archive and complete
/wire:archive
Archives the completed release. Status and execution log are updated automatically throughout — no session-close command required.
Autopilot runs the full delivery lifecycle without step-by-step prompting.
/wire:autopilot
Wire starts with a complete discovery sprint (problem definition, pitch, release brief, sprint plan). From the approved sprint plan it determines which downstream release types are needed, creates them, and executes each in sequence, resolving each release type's artifact order dynamically from its wire/release-types/*.yaml rather than a hardcoded sequence. Every artifact goes through generate, validate, and self-review — Autopilot doesn't pause for human sign-off at review gates, it reads the artifact's real review criteria and decides itself, recording reviewed_by: "Wire Autopilot (self-review)". It still pauses at safety gates (activating pipelines, running SQL against real databases, deploying) for explicit confirmation, and at any precondition-gate block, since overriding that always requires a real person's name and reason.
It works best on well-scoped engagements where the SOW is clear and the release types are predictable.
A VS Code extension (wire-vscode/) is in early development. The intention is to surface Wire commands and project status directly inside the editor. It is not yet published to the VS Code Marketplace.
- Documentation site — full documentation with search, covering all release types, commands, skills, and MCP servers
- User Guide — full operational guide covering all release types, worked examples, Autopilot, and troubleshooting
- Command Reference — command catalog and conventions (run
/wire:helpfor the full, current list of all 341 commands) - Changelog
- Release Notes
- Framework Source README — internals, build process, package structure
Wire is maintained by Rittman Analytics.
Bug reports and feature requests can be filed as issues on this repository. Please include the Wire version (run /wire:help to check), the command you ran, and what you expected versus what happened.
Pull requests are welcome for bug fixes and documentation. For larger changes — new release types, new skills, changes to the generate/validate/review lifecycle — please open an issue to discuss the approach before submitting.
Building packages (for maintainers):
bash wire/scripts/build-packages.shOutput goes to wire/dist/. Push each package to its distribution repository:
wire/dist/claude-plugin/torittmananalytics/wire-pluginwire/dist/gemini-extension/torittmananalytics/wire-extension
Rittman Analytics — rittmananalytics.com — info@rittmananalytics.com