Everything vibe installs is a package: a folder with a small description file and the text or tools it delivers. Packages come in eight kinds, and the kind tells you what a package is for before you open it: a way of working, a feature, a technology, a tool, a language guide, an agent server, documentation, or an application.
A package is a project made installable. It has the same layout as a project, with its own `vibe.toml` and its own `vibevm/vibespecs/`, and it may carry code beside them. When a project installs it, the package's published tree is copied verbatim into the project's dependency tree; nothing is extracted, rewritten or merged.
A package is named by a *[coordinate](../glossary/index.xml#coordinate)*: a group, a slash, and a name, as in `org.vibevm.world/wal`. The group looks like a reversed domain name and says who publishes; the name is unique within the group. A version completes the address when one is needed: `org.vibevm.world/wal@1.0.0`. The kind is not part of the name. It may be written as a prefix on the command line, `flow:org.vibevm.world/wal`, and then vibe checks that the package really is of that kind.
The group is a claim, not a credential: nothing checks that the publisher of `com.google/x` owns that domain, and nothing ever will, because vibe has no central verifier to ask. The name is unique within its group, so the coordinate alone is the identity. On the command line the kind prefix and the group are both optional; in a [manifest](../glossary/index.xml#manifest) the coordinate is always written in full. In a [registry](../glossary/index.xml#registry) the repository is named by joining group and name with a dot, `org.vibevm.world.wal`, which is itself a valid reversed domain name.
Wherever a package is named in a project, the full coordinate stands: `group/name` in a requirement, `group.name` as a repository name, `group/name` as the first segment of a `spec://` address. Short names survive only as what a person types once at the command line.
| Kind | What it delivers | Example |
| `flow` | a way of working: commit rules, session notes, review conventions; usually a [boot snippet](../glossary/index.xml#boot-snippet) the agent reads every session | `org.vibevm.world/wal` |
| `feat` | a description of what to build, without saying how | a welcome page, e-mail sign-in |
| `stack` | a technology context that says how a feature is built with it, or a bundle of a family's members at one version | `org.vibevm.ai-native/rust-ai-native` |
| `tool` | a script or utility a build step can invoke | a formatter wrapper |
| `lang` | guidance on how to write in a language or notation | `org.vibevm.ai-native/rust-ai-native-lang` |
| `mcp` | a server an agent talks to, built from the package's own code | `org.vibevm.ai-native/rust-ai-native-mcp` |
| `doc` | documentation of other packages: read, never installed | `org.vibevm.core/vibevm-docs` |
| `app` | a standalone product with its own deployment | `org.vibevm.doc/web` |
The set is closed and grows only by an amendment to the [specification](../glossary/index.xml#specification); a [manifest](../glossary/index.xml#manifest) with an unknown kind is rejected rather than guessed.
The kind is metadata about the package, not part of its identity: it decides where content is placed, what the `--kind` filter of `vibe list` and `vibe search` shows, and whether a kind-prefixed name is accepted. Two packages of different kinds may not share a coordinate, because the coordinate alone is the identity.
An `app` differs from a `tool` mechanically: a tool lives in a project and runs through `vibe bin exec` by the lock file, while an app runs in no consumer project and is built and deployed on its own.
Some [capabilities](../glossary/index.xml#capability) arrive as several packages that share a name stem: the language guide, the server that serves its tools, and a small bundle that pins both at one version. This is a *family*. Requiring the bundle installs the family, and a change to any member bumps every member to one shared version, so the pieces can never drift apart.
The bundle itself is the smallest package there is: a manifest and a README, no code and no [boot snippet](../glossary/index.xml#boot-snippet). Its one job is to name the family's members at one version.
Documentation is the exception. A package's manual is its *[companion](../glossary/index.xml#companion)*, named with the suffix `-docs` in the same group, and it keeps its own version line. A fixed typo in the manual does not release the tools, and a new tool version does not demand a new manual. The manual says which versions of its [subject](../glossary/index.xml#subject) it describes, and the site picks the newest manual that fits.
`[package].materialization` says how a package arrives in a consumer's tree. `copy` is the default and all an ordinary package needs; `hardlink` is the same content sharing bytes with the [store](../glossary/index.xml#store). Both are vendored: the folder is committed with the project and restores offline from it. `in-place` keeps a live git checkout with its own `.git`, ignored by git and restored by a fresh clone at the locked commit, so it needs the network and a [git source](../glossary/index.xml#git-source). Anything destructive on such a slot, an uninstall, a forced reinstall or a version switch, asks first, or needs `--force` when nobody can answer.
Changing a package's group or name creates a new package, not a rename: versions do not carry across, and old coordinates are never reused for different content.
A documentation package cannot be installed into a project. `vibe install` refuses it and names the command that fetches it for reading instead.
A short name without a group, such as `wal`, is accepted on the command line and resolved through the [registry](../glossary/index.xml#registry) [index](../glossary/index.xml#index-registry); it is convenience, and the manifest always records the full coordinate.
Resolving a short name needs the index, one lookup per registry; a registry without one offers no short names, and the full coordinate is required. If the lock file already pins a package of that name, the short name means the locked one. When two registries offer different packages under one name, vibe stops with exit code 7 and lists the candidates, and you repeat the command with the group. A kind prefix checks the result and never disambiguates, because two packages of different kinds cannot share a coordinate.