A feat says what to build without saying how; a stack says how a technology does it. This page writes one of each and connects them through the abilities one needs and the other provides.
The agent creates both slots with `vibe init package`, sets their kinds in the [manifests](../glossary/index.xml#manifest), writes the feat's specification, acceptance criteria and [capability](../glossary/index.xml#capability) requirement, writes the stack's description, conventions and the capability it provides, and checks each. When a project later installs the feat, the resolver looks for a package providing `ui:page-host` among the project's stacks; the stack satisfies it, and the two are matched without either naming the other.
A feat describes what a feature does for its user, in terms any stack can implement: purpose, behaviour, acceptance criteria, data it needs, what happens when things go wrong. It never names a framework. Its [manifest](../glossary/index.xml#manifest) declares the abilities it needs from a stack as capabilities, `namespace:name@constraint`, and nothing else about technology.
| Path | Purpose |
| `vibevm/vibespecs/feats/<name>/SPEC.md` | what the feature does, for whom, and why |
| `vibevm/vibespecs/feats/<name>/acceptance.md` | observable criteria a build must meet |
| `vibevm/vibespecs/feats/<name>/data-model.md`, `api.md`, `ui-flows.md`, `failure-modes.md` | the parts that apply, one topic per file |
In the manifest: `[requires] capabilities = ["ui:page-host@^1"]` and, for a feat that needs a stack at all, `[compatibility] requires_kinds = ["stack"]`.
A stack is a technology context: it says how the abstract abilities a feat asks for are realised with one set of tools, and it may bind the [lifecycle](../glossary/index.xml#lifecycle)'s build and test [phases](../glossary/index.xml#phase) to that toolchain. Its manifest declares what it provides, `[provides] capabilities = ["ui:page-host@1.0"]`, and its specification documents describe each provided capability in a file of its own, plus conventions, tooling and deployment.
| Path | Purpose |
| `vibevm/vibespecs/stacks/<name>/STACK.md` | what the stack is and when to choose it |
| `vibevm/vibespecs/stacks/<name>/capabilities/<capability>.md` | one file per provided ability: how it is realised |
| `vibevm/vibespecs/stacks/<name>/conventions.md`, `tooling.md`, `deployment.md` | naming and layout, the build and test commands, how a build ships |
| `vibevm/vibespecs/boot/<name>.xml` | an optional snippet that surfaces the active stack at session start |
A stack may also bind lifecycle [contributions](../glossary/index.xml#contribution) in its manifest, so that `vibe build` and `vibe test` in a consuming project run the stack's toolchain without further configuration.
A capability is an abstract interface: a namespace, a colon, a name, and optionally a [version constraint](../glossary/index.xml#version-constraint). A feat requires; a stack provides; the resolver matches them at install time, and refuses a project whose feats need an ability no installed stack provides. Choose names by what the ability does for the feature, not by the technology: `ui:page-host`, `db:relational`, `auth:oauth-callback`.
The word `stack` also names a [family](../glossary/index.xml#family) bundle: a package of kind `stack` with nothing but exact pins of a language family's members. Both are stacks in the register; the description tells them apart.
A feat's acceptance criteria are what the agent checks after a build; write them as observable [facts](../glossary/index.xml#fact), not as wishes.
Two feats requiring the same capability may be satisfied by one stack; a project with several stacks marks one as active for a build.