Skip to main content

Advanced

📄️Wire Studio

Under the release director model, you direct a release in plain English and agents run the Wire commands. What you need to see is what is waiting on you, what can run next and what the lanes are doing. Today that means reading status.md, decisions.md, the execution log and each lane's state file. Wire Studio puts all of it on one page in your browser. This page covers what Studio shows, how to start it, how its "Run in Claude Code" button works, and why Studio never writes to the release record.

📄️Agent Architecture

When a release is running under Wire 4.0.0 there may be a person, a Claude Code session and several subagents all working in the same repository at once, and if you have to support, extend or simply trust that arrangement you need to know who does what, how the pieces talk to each other and where the record of the work lives. This note explains all three. It is based on the release/v4.0.0 branch of the Wire source repo at commit 9a8672e0 (6 September 2026) and on the installed build of the same release, and it was written on a live Looker to Omni migration engagement, which is where its examples come from.

📄️dbt Charts Boards

Since v4.0.0. dbt Charts is a dashboard layer written as YAML files that live in the dbt project next to the models. Each file is a board: named SQL queries that read models through ref(), charts that map a query's columns to a chart type, optional filter variables, and a layout. The dct command-line tool validates, renders and serves the boards, and dbtcharts.com can host them from the repository. Because a board is a text file, it gets the same pull-request review as the models it reads, which is the property Wire wants from a dashboard layer.

📄️Agents Schema

Since v4.0.0. Agents Schema is dbt Labs' standard for putting the context an AI agent needs to query a warehouse **inside that warehouse**, in a schema named AGENTS. One table, AGENTS.ROOT, lists which providers have published metadata and how to read their tables. The provider tables hold what the dbt manifest says about every model, column and dependency (AGENTS.DBTMODEL, AGENTS.DBTCOLUMN, AGENTS.DBTDEPENDENCY), what the semantic layer exposes (AGENTS.LOOKML, AGENTS.OMNI, AGENTS.OSI, AGENTS.SIGMA), and skills: markdown instructions for agents, stored as rows whose key starts with skill/. Anything that already runs SQL against the warehouse, Claude Code, Cursor, a notebook or an internal agent, reads that context with a SELECT, starting from ROOT, instead of guessing from INFORMATION_SCHEMA or a wiki.

📄️VS Code Extension

If you spend your day in Visual Studio Code, switching to a terminal to check which artifacts are approved and which are waiting on a validation fix is a small but constant interruption. The Wire VS Code extension brings Wire status and artifact management into Visual Studio Code, providing a sidebar panel, inline artifact decorations and quick-run command shortcuts, so that you can see and drive a release without leaving your editor. In this page we will look at what the extension provides, how you install it, how the Wire Explorer and the command shortcuts work, how you set the active release, and what the extension settings and gutter decorations do.

📄️Issue Tracking

If your client's delivery team lives in Jira or Linear, they will want to see the state of each Wire artifact where they already look for it, rather than having to ask you. Wire therefore integrates with Jira and Linear to sync artifact status as the engagement progresses. Each integration is optional, Wire works without either, and both can be active simultaneously. In this page we will look at the Jira integration first, then Linear, and finish with what happens when both are configured.

📄️Document Store

Once Wire has drafted a requirements document or a data model, the people who most need to read and comment on it are usually at the client, and they are unlikely to have Claude Code open or to want to read Markdown out of a Git repository. Wire can therefore replicate generated artifacts to Confluence or Notion for client review. Configured at engagement setup, every generate command publishes the artifact to the document store after writing it locally, and review commands surface the comments and edits made in the document store as additional review context, so that what the client says in Confluence or Notion comes back into Wire's own review rather than sitting in a separate channel.

📄️Extending Wire

Sooner or later an engagement will ask for something Wire does not yet do, whether that is a kind of release the existing definitions do not cover, an artifact nobody has written a spec for, a utility that only your team needs or a change to a template that every new engagement should pick up. Wire is designed to be extended in each of these directions, and new release types, new artifact types, new utility commands and project-specific customisations are all first-class. In this page we will look at each in turn, starting with the largest change, a new release type, and working down to the smallest, a template you override for a single engagement, before finishing with how you distribute your extensions to others.

📄️Business rules discovery

Anyone who has delivered a reporting platform will recognise the moment when a number on the new dashboard fails to match the number on the old one, and the investigation that follows turns up not a bug but two reasonable definitions of the same metric, neither of which anyone had written down. Before this phase existed Wire had no step that established what a metric means before the build started, and the two commands that came closest did not fill the gap: requirements-generate reads documents, and workshops-generate runs after requirements and only resolves the clarification markers already written into them, so that neither looked at the data and neither looked at the competing definitions sitting in the legacy systems.