Skip to main content

Introduction

📄️Installation and Setup

Before Wire can set up an engagement it needs two things from you: a git repository to hold the record of the work and one of the two AI coding agents it runs inside. Everything else that Wire needs travels with the plugin or extension itself, since each command carries its own full workflow specification, so there are no framework files to copy into the repository and nothing to keep in step by hand. In this page we will look first at what needs to be in place before you start, then at the two steps of installing and verifying, and finally at how upgrades reach you once you are up and running.

📄️Engagements and Releases

A client relationship rarely consists of a single piece of work. A discovery phase leads to a data foundation, which leads to reporting and then to training, and along the way the team gathers a Statement of Work, call transcripts, org charts and a picture of the client's current systems that every later piece of work needs to see. Wire therefore uses a two-tier structure, with precise terminology, to keep the two apart: the engagement holds what spans the whole relationship, and each release holds one scoped piece of delivery inside it. Understanding these two concepts is essential before using the framework, so we will define them first, then look at the folder structure they produce, at how you set one up and at what happens when a session starts.

📄️Release Types

Every engagement has a shape, and the shape decides which documents get written, in what order and who signs off each one before the next begins. A discovery that ends in a pitch is a different piece of work from a warehouse migration, and a framework that treated them alike would either bury the first in ceremony or leave the second short of the checks it needs. Wire therefore encodes its delivery methodology as twelve release types, each defining a different ordered set of in-scope artifacts and the commands that apply to them, and when you run /wire:new and select a release type the framework instantiates that process definition into the release's status.md file. In this page we will look at the twelve types side by side, at how the choice between them is made since 4.0.0 and at the distinctions that most often decide it.

📄️Core Concepts

Whichever release type you run, and however you drive Wire, the same small set of ideas turns up in every session say what you want done and Wire works out which command that is from the release-type definition, runs it, tells you what it did and stops where a decision is yours. Or you can type the commands yourself, on Claude Code or Gemini CLI, exactly as in 3.x. Part 1 of this guide shows the first way through four worked releases and a ticket worked inside one of them; this page and the rest of the Technical Reference describe the machinery both ways share, and the commands are named throughout because that is what runs in either case.

📄️How Wire Works: Inside a Command

When a tool generates code for you, sooner or later you will want to know exactly what it is going to do and why, and to be able to read the answer rather than take it on trust. Wire is not a black box. Every /wiredbt-generate runs, Claude Code reads that file as a set of natural-language instructions and executes the steps exactly as written. There is no hidden logic, no compiled binary and no server call, just structured prose that the model treats as a workflow specification.