Be the driver, not the passenger. Skills that make you decide first — packaged as a Claude Code plugin — and the conventions and guard rails that keep it honest.
AI made writing code cheap. The work that matters — deciding what to build, designing it, proving it right — didn't change. NoVibe makes you do it first.
Vibe coding: describe it, ship it, audit what the machine made. Trapped in review hell. NoVibe: spec-driven — you author the spec and the design; the machine builds to them, and the executable spec proves it. The
.featurefile isn't documentation of the code; the code is an implementation of the spec.
| The plugin | a guided flow for your coding agent, and the specialists it runs — a Claude Code plugin; the skills are plain SKILL.md |
| Conventions | the rules that keep an agentic workflow honest |
| Guard rails | git hooks that enforce them, every time |
Alongside: cockpit — the driver's view of the spec, what the tests proved and the plan; agentbox to run sessions.
| Invoke | What it does for you |
|---|---|
novibe |
drives a change end to end — spec → design → tests — one step at a time |
requirements-engineer |
asks you, round by round, until the feature file holds what to build |
architect |
asks you the same way until the C4 model holds the design; an ADR only when it matters |
developer |
builds it test-first — red → green — until the spec's scenarios pass |
/plugin marketplace add novibe-org/novibe
/plugin install novibe
Ask Claude to build something the NoVibe way (or invoke novibe). It walks the flow one
step at a time and pauses for your call between steps — the spec and the model are the
contract; code is their consequence. Give each slice its own session:
- Specify it as business scenarios.
- Design it in the LikeC4 model, its views layered after
arc42. A complex design decision? Visualize and review it with
npx likec4 serve docs/architecture. - Build it test-first — point it at the spec, the model and the ADRs; don't restate the decisions in your prompt, or it builds what you wrote instead of what was reviewed.
- Ship it — turn on agent merge in the GitHub Copilot app: it answers review comments, fixes failing checks and merge conflicts, and merges once GitHub allows. Turning it on is your decision to merge.
Only need one part? Invoke requirements-engineer, architect, or developer directly.
Skip NoVibe for trivial edits.
Where your agents run is your choice — locally, in a container, or in the cloud. One slice per session keeps slices apart; isolating them, with worktrees or separate sessions, is up to you. We use agentbox: one container per session.
Feature files live in the repository, grouped by domain — what the system does, never an epic.
The plan doesn't: epics, priorities and how a slice is split change all the time, so they
belong in a planning tool — Jira, cockpit, whatever you
already use. Tag a feature, or a scenario planned on its own, with its ticket as its id
(@id:<ticket>) and the tool keeps the rest.
The vision, the epic and why it matters usually come first, in that tool; NoVibe splits it down
into slices. Ask requirements-engineer to create the slice's ticket under the epic — or the epic
itself — when your tool is connected. More of this will be automated.
| cockpit | a whole project built the NoVibe way — its features, its architecture model, its ADRs, the guard rails, and every change committed spec → design → tests |
A skill is guidance: an agent follows it most of the time, not every time. What has to hold every time is enforced by a git hook instead — deterministic, whatever the agent made of its skill, and just as much for fast merges and machine-written diffs. These are the guards this repository uses itself; take the ones you want:
| Refuses | |
|---|---|
| git | a push to a merged or closed pull request, and a branch stacked on another open one |
| code | a diff that is mostly added comments |
| security | a commit of a file whose path looks like a credential — the one guard without an override |
| gherkin | a feature file without an @id:, with an unknown tag, with comments, or naming a click, a button or an endpoint |
| likec4 | an architecture model that does not validate |
| phases | a spec: commit touching more than the spec, an arch: commit more than the model and ADRs, and any other commit touching either |
| copilot | — instructions that keep agent merge off the spec and the design, and review skills that flag code contradicting the architecture or creating a security problem |
Claude sessions turn the hooks on themselves, wherever they run, through
.claude/settings.json. Pushing without Claude? Once per clone:
git config core.hooksPath .githooks
Adopting them means copying from where each file already lives:
| Copy | For |
|---|---|
.githooks/ |
the entry hooks, and the guards in pre-push.d/ and pre-commit.d/ |
.gherkin-lintrc |
the feature-file lint |
.claude/settings.json |
the hook that turns the guards on, and the plugin |
.github/copilot-instructions.md, .github/skills/ |
Copilot's instructions and review skills |
docs/conventions/ says what each rule is for.
Learn more at novibe.org · be the driver.