A package can plug into the build: run a step, transform a stage, or hand a task to an agent. This page explains how such plug-ins are declared, how a project turns them on, and how to see which ones ran and why.
The [lifecycle](../glossary/index.xml#lifecycle) exposes named *[extension points](../glossary/index.xml#extension-point)*, strings of the form `family:name`. The `phase:` family, the group of points that share one prefix, is the nine [phases](../glossary/index.xml#phase). The `slot:` family names places inside a phase where a stack or a discipline expects to plug something. The `compile:` family is the boot compiler's own pipeline, where a package may transform the text an agent will read. A *[contribution](../glossary/index.xml#contribution)* binds a [handler](../glossary/index.xml#handler) to a point and is declared in a [manifest](../glossary/index.xml#manifest) as an `[[extension]]` table, in a package or in the project itself.
A contribution carries an id, which is also the key a project uses to disable or replace it; the same handler may be bound several times under different ids with different configuration.
| Kind | What runs |
| `builtin` | a handler compiled into vibe, such as a logger |
| `script` | a shell or PowerShell script shipped by the package, resolved by platform |
| `binary` | a program the package delivers and vibe builds on install |
| `native` | a dynamic library loaded in process through a C ABI, from an exact prebuilt for the platform |
| `agent` | a prompt: work handed to the hosting agent, or to a configured model provider when a person runs vibe at a terminal |
Every handler receives one context envelope, a versioned JSON document that names the project, the phase, the artifacts produced so far and the configuration of the contribution, and answers with a reply envelope that may declare new artifacts. The envelope is how phases talk to each other.
A native handler is a dynamic library with exactly four C symbols; the request and the reply cross that boundary as versioned JSON, one family per library, and the `vibe-ext` crate gives an author safe macros so that no `unsafe` is ever written by hand. A closed-source handler ships prebuilt for each platform; the exact prebuilt wins, declared source may build instead, and absence refuses rather than skips. A `compile:` transform runs inside lane regeneration, so it may only be a builtin or an admitted native handler, never a script, a binary or an agent. A contribution that wants the low-level pass tier says so with `compiler_internals = true`, and then still needs the host's activation.
Installing a package is the consent to run its contributions: a dependency's phase and slot contributions are active as soon as the package is installed. The consuming manifest can activate a contribution that is not automatic, disable one by its id, or [override](../glossary/index.xml#override) its configuration. There are no consent dialogs at run time; there is total transparency instead.
Within one point, contributions run in a fixed order: the built-in bindings of the effective preset first, then the packages' contributions in dependency order, then the project's own; the order is derived, never negotiated.
`vibe extensions` lists every declared contribution in the installed world with its point, handler and origin; `--json` gives the same to a scanner. Everything a contribution can do is declared, so a scanner needs no execution to audit a project. Every run prints the contributions it will execute before it starts, and a run can be traced pass by pass with `--trace-compile` into `.vibe/trace/`.
`vibe tools` lists the binaries and servers the installed packages brought, which is the [registry](../glossary/index.xml#registry) of what a contribution of kind `binary` may name.
A contribution of kind `agent` needs someone to run its prompt. Under an agent host, vibe parks the task for that agent and resumes when the declared outputs exist. At a terminal, vibe can call a configured model provider, the first one being any OpenAI-compatible endpoint, and it reads the provider's credentials only when a non-fresh agent step actually reaches the point of calling it. Every model-enhanced feature declares whether it is off, assisting or required, and off is the default.
A contribution may carry a selector that limits it to matching files or targets, so a formatter binds to one language's sources and not to the rest of the tree.
A native handler crosses a C-and-JSON boundary, never the Rust ABI, so a library built by another toolchain version still loads.
Enabled model work carries per-run ceilings on calls and tokens; a step that would exceed them stops rather than spends.