v0.5.0 — The Minimalism Guard

vibekit v0.5.0 — The Minimalism Guard

vibekit's pipeline has always governed process — brainstorm → plan → isolate → exec → verify → review → integrate, with hard guardrails so work is designed, verified, and reviewed before it ships. But nothing in the pipeline pushed back on over-engineering. A fully verified vibe run could still ship a 404-line date picker that a native <input type="date"> covers, or a hand-rolled validator the standard library already ships.

v0.5.0 closes that gap. It weaves an anti-over-engineering minimalism guard through the existing pipeline — the discipline of a lazy senior dev who replaces fifty lines with one — without adding a single new skill or breaking any existing contract.

The best code is the code never written. Lazy means efficient, not careless.

---

✨ What's new

The guard is 5 additive edits to existing skills. No new skill, no new command, no manifest/hook/runtime changes beyond the version bump. The minimalism rule lives in one canonical place (brainstorm-lean) and propagates downstream through the spec/plan artifacts the pipeline already passes along — so there is no duplicated rule text to drift across runtimes.

1. brainstorm-lean — the Laziness ladder

A new Laziness ladder is applied when generating the 2–3 candidate approaches. Before proposing anything, walk the ladder and stop at the first rung that holds:

1. Does this need to exist at all? Speculative need → skip it. (YAGNI)
2. Stdlib does it? → use it.
3. Native platform feature covers it? → <input type="date"> over a picker lib, CSS over JS, a DB constraint over app code.
4. Already-installed dependency solves it? → use it; never add a new dep for what a few lines do.
5. Can it be one line? → one line.
6. Only then: the minimum code that works.

At least one presented approach must be the laziest rung that still meets the requirement, so you can choose it. Ships with a hard never-cut carve-out: input validation at trust boundaries, error handling that prevents data loss, security, accessibility, and anything explicitly requested are never on the chopping block.

2. plan-write — the Minimalism constraint

Plans now constrain how much to build, not just what: prefer stdlib/native over new code, no unrequested abstractions, fewest files, shortest working diff, deletion over addition. Deliberate shortcuts are planned with their marker comment, not just the shortcut.

3. exec-dispatch — the vibekit: comment convention

Two new RTCO brief constraints push implementers toward stdlib/native and forbid unrequested scaffolding. Plus a documented convention for marking intentional simplifications inline:

# vibekit: global lock, per-account locks if throughput matters

The comment names the shortcut's ceiling and its upgrade path, so a simplification reads as intent rather than ignorance. A shortcut with no upgrade path is a rot risk.

4. review-pack — over-engineering review lens

The existing Pass 4 (simplicity) is extended (not duplicated) with a tag vocabulary so the cut is unambiguous:

• delete: dead code / speculative feature → replacement: nothing
• stdlib: hand-rolled thing the stdlib ships → name the function
• native: dependency/code the platform already does → name the feature
• yagni: abstraction with one implementation, config nobody sets
• shrink: same logic, fewer lines → show the shorter form

Each pass ends with the only metric that matters: net: -<N> lines possible. This lens hunts complexity only — correctness, security, and performance stay with the other review passes.

5. memory-dual — the debt-ledger operation

A new read-only operation harvests every vibekit: comment in the tree into a tracked ledger, so deferrals don't rot into "later means never":

grep -rnE '(#|//) ?vibekit:' .

Each marker becomes one row (file:line, what was simplified, ceiling, upgrade trigger); any marker with no upgrade trigger is flagged no-trigger — those are the ones that silently rot. Output ends with <N> markers, <M> with no trigger. Persists to a file only when you ask.

---

🧭 The guard end-to-end

The result is a single thread of minimalism running through the whole pipeline:

lazy approach chosen (brainstorm-lean) → planned minimally (plan-write) → shortcuts marked in code (exec-dispatch) → residual over-engineering caught at review (review-pack) → deferred debt tracked over time (memory-dual).

🪶 What was deliberately left out

In keeping with the guard's own philosophy, several ideas were considered and rejected as bloat:

• Intensity levels (lite/full/ultra) — unnecessary configurability.
• A standalone over-engineering review/audit skill — review-pack already owns the review surface; a new skill would be the exact bloat this guard prevents.
• Restating the full ladder in every skill — four near-identical copies would be precisely the cross-runtime drift vibekit's portability layer exists to prevent.

✅ Compatibility

• Non-breaking. All changes are additive Markdown inside existing SKILL.md bodies (5 files, 83 insertions, 0 deletions).
• No new skills — still a 15-skill plugin. Skill names, frontmatter, trigger map, manifests, and hooks are unchanged.
• Cross-runtime parity preserved — the same skill bodies ship to Claude Code, Codex, Gemini, opencode, and Pi. vibekit-doctor is clean (C1/C2/C3/C8 pass).
• Fully verified — the change was taken through vibekit's own pipeline (brainstorm → plan → exec → two-stage review → verify-gate); verdict ready, surgical-diff pass clean.

📜 Changelog (since v0.4.0)

• feat(skills) weave anti-over-engineering minimalism guard into pipeline (32909d7)
• chore bump version to 0.5.0 (minimalism guard) (c8e62ee)

⚠️ Known issue

plugins/vibekit/.codex-plugin/plugin.json (a tracked vendored copy) remains pinned at 0.3.2 — pre-existing drift that predates this release. The 7 canonical manifests are all at 0.5.0.

Full diff: v0.4.0...v0.5.0