vibekit

A guardrailed pipeline for coding agents. It turns a one-line intent into a design you approved, a plan you approved, code written by an agent that never saw the plan being written, and a verdict backed by output you can read. Dependency free: bare Node and whichever agent CLI you already use.

The problem it solves is not bad code. It is the claim of being done. vibekit puts a gate in front of every such claim and makes the evidence part of the answer.

How it works

Six skills, each one a gate. Every stage hands to the next, and no stage can skip the one before it.

/vibekit:vibe "add a dark mode toggle"
        │
        ▼
  brainstorm ──► plan ──► exec ──► verify ──► merge or PR
   (design)    (tasks)  (agents)  (evidence)
        ▲                   │         │
        └───── debug ◄──────┴─────────┘
              (a check failed)

• brainstorm asks questions one at a time, pushes back on your framing once, offers alternatives, and writes a spec with observable success criteria. No code before you approve it.
• plan turns the approved spec into numbered tasks. Every task carries a → verify: clause that is checkable before anything runs, and a plan may not state a value nobody has observed.
• exec dispatches one fresh agent per task. The author of a plan reads past its own contradictions. A fresh context reads it literally and stops. Every plan defect this project has found was found by a dispatched agent.
• verify runs the checks no single task could: the whole suite, the scope of the diff, every goal against its evidence. It returns ready or not ready, and unmeasured counts as not satisfied.
• debug takes over on a failed check. It finds one falsifiable cause, sends a read-only agent to refute it, and stops after two refutations rather than guessing a third time. It never edits.
• lazy and terse stay on once invoked. One governs how much you build, the other how much you say.

Two rules run through all of it. Evidence or it did not happen, because a check with no output to show is not a check. You may not write a value you have not observed, because a guess in a plan is a defect a later agent pays for.

Features

| Skill | What it does | Gate | |---|---|---| | brainstorm | Use before any creative or implementation work: features, components, behavior changes. Hard gate, no code before an approved design. | hard | | debug | Use when a check fails: a red test, a broken build, a failed clause, or a bug you can point at. Finds a root cause and gets it refuted before anything is fixed. Diagnosis is the product. This skill never edits. | hard | | exec | Use when a plan is approved and implementation has not started: dispatches one fresh subagent per task, runs each task's verify clause, and routes failures back instead of repairing them. One task, one commit. | hard | | lazy | Use at the start of any coding work: writing, adding, refactoring, fixing, designing. The laziness ladder, stdlib and native features before new code, one line before fifty. Stays on after. | none | | plain | Use before writing any text, in chat or into a file. Three typography rules that hold in every string you emit, including code comments, commit messages, PR bodies and docs. No em dash, no semicolon, no hard wrapping inside a paragraph. Stays on after. | none | | plan | Use when a spec is approved and implementation has not started: turns it into a task-by-task plan with exact paths and checkable verification. No code here. | hard | | quick | Use when the user types /vibekit:quick: writes the change immediately under lazy's ladder, no spec, no plan, no subagents. Reports what it skipped. | none | | terse | Use at the start of every session. Compress narration, never artifacts. Questions, evidence, specs, plans and warnings stay verbatim. Stays on after. | none | | using-vibekit | Use when starting any conversation: establishes the auto-trigger discipline so guardrail skills fire instead of being silently skipped. | none | | verify | Use before claiming a change is done, fixed or passing: checks the whole change against its spec, runs the checks no single task could, and returns ready or not ready. Evidence or it did not happen. | hard | | vibe | Run a short intent through the pipeline. Invoked as /vibekit:vibe. Hands off to brainstorm and does nothing else. | none |

A hard gate refuses to proceed until its condition is met. none means the skill shapes behaviour without blocking anything.

Skills are discovered by globbing skills/*/SKILL.md. There is no registry anywhere in the repo, which is what makes registration drift impossible rather than merely detectable. Every derived file, including the runtime manifests, the command files, the trigger tables and this table, is generated by npm run generate and verified by npm run check.

Install

Each runtime installs separately. Installing for one does not affect any other.

Claude Code

/plugin marketplace add rizukirr/vibekit
/plugin install vibekit@vibekit-marketplace

Codex

codex plugin marketplace add rizukirr/vibekit
codex plugin add vibekit@vibekit

Verify with codex plugin list.

opencode

Add it to the plugin array in your opencode.json, global or project level:

{
  "plugin": ["vibekit@git+https://github.com/rizukirr/vibekit.git"]
}

Verify with opencode debug skill.

Gemini CLI

gemini extensions install https://github.com/rizukirr/vibekit

Pi

pi install git:github.com/rizukirr/vibekit

What has actually been checked

| Runtime | Emitter | Verified | |---|---|---| | Claude Code | runtimes/claude-code.mjs | SessionStart hook smoke-tested in CI on Linux and Windows | | Codex | runtimes/codex.mjs | installed and listed as enabled by codex plugin list, against codex-cli 0.147.0 | | opencode | runtimes/opencode.mjs | all skills listed by opencode debug skill, against opencode 1.18.16 | | Gemini | runtimes/gemini.mjs | not verified, tool not installed | | Pi | runtimes/pi.mjs | not verified, tool not installed |

Two runtimes were probed against the real CLI and two were not. That distinction is kept per row because unit tests assert what we decided to emit, which says nothing about whether a host accepts it. That gap hid four integration defects until they were probed.

Evals

Skills are behaviour-shaping prompts, so the only way to know one works is to watch it fire in a real session.

npm run eval                                       # candidate only, deterministic
npm run eval -- --baseline v2 --candidate HEAD     # A/B two refs
npm run eval -- --dry-run                          # print the plan and cost, spawn nothing
npm run eval -- --judge                            # also grade whether the skill was followed

Variants are git refs materialised as throwaway worktrees, so there is never a second skills/ tree to drift. Sessions run in a disposable temp directory.

Run A/B rather than candidate-only whenever a rate is the point. A candidate rate of 1.00 once looked like a new rule working. Its baseline arm was also 1.00, because the model already did it.

This costs real money and needs an authenticated claude CLI, so it is a manual gate, not part of the free CI (check, test, check:hook).

Development

npm run generate    # regenerate every derived file
npm run check       # fail if any generated file is out of date
npm test            # unit tests

Adding a skill is creating one directory under skills/ with a SKILL.md, then running npm run generate. Never hand-edit a generated file.

License

MIT. Copyright (c) 2026 Rizki Rakasiwi. See LICENSE.