vibecode-pro-max-kit: a plan-first harness that writes its own progress notes

The failure mode this kit is built around

The README opens with a blunt claim: your AI forgets. That is the problem statement. A coding agent working on a feature across several sessions loses the thread. It re-reads files it already understood, contradicts a decision it made an hour ago, or drifts into code that does not match what you asked for. The kit's answer is to move the plan out of the conversation and onto disk, then gate each step so the agent cannot skip straight to writing code.

The target user, per the README, is the vibecoder, the product owner, the CEO and the real builder. That phrasing matters. This is not a library you import. It is a set of markdown-defined agents, skills and hooks that shape how an existing agent behaves. If you are an engineer who already keeps a tight spec in your head, the ceremony will feel like overhead. If you hand a feature to an agent and come back to find it built the wrong thing, the phase gates are aimed at exactly that.

RIPER-5: seven gates between you and the code

The workflow is called RIPER-5 and it runs seven gated phases: Research, Spec, Innovate, Plan, Validate, Execute, Update-Process. The stated purpose is to stop the agent jumping straight to code. Each gate is a checkpoint, and the SPEC phase is the one the README singles out as the cheapest place to catch a misunderstanding, because you state what to build in plain user stories before any design work starts.

Two loops run inside that structure. PVL is plan-check-fix, EVL is test-check-fix, and the README says each can cycle up to 10 times. A separate skill, vc-autoresearch, exposes the same find-gaps then fix then repeat pattern as something you can point at plans, tests, specs, docs or evals. There is also a feasibility probe that returns a VIABLE or NOT-VIABLE verdict before the agent commits to a design approach.

The design choice worth noting is the strategy picker. Before each phase the kit weighs one agent against many against a coordinated team, attaches cost estimates, and picks the cheapest that fits. That is a real constraint on runaway token spend, and it is the kind of decision most harnesses leave to the model's own judgement. The README also states that the expensive model only writes code while a cheaper model handles everything else. Treat both claims as design intent rather than measured savings; the material does not include numbers.

Getting it installed and what the one-liner does

The README describes a one-command install via a curl line that drops the kit into any project. It detects new versus returning users and, in the README's words, never overwrites your files. The lifecycle is four commands, one each for install, setup, update and publish. The update command is vc-update.

The honest part of the story is in the release notes. v3.2.4 is titled "install.sh data-loss fix (defer content dirs to vc-update)". That tells you a previous install path could touch content directories it should have left alone, and the fix was to defer that work to vc-update. v3.2.3 made vc-update run an adaptive migration even on version-equal installs, which is the kind of change that matters when you re-run an installer over an existing project. v3.2.5 adds Windows install guidance.

Three consecutive patch releases in two days, all touching installation or migration. That is a maintenance signal, not a maturity signal. Before you run the curl line on a repository you care about, read install.sh and confirm which directories it writes to. The kit is MIT licensed, so you can fork and patch the installer yourself, but the licence says nothing about whether the installer is safe on your tree.

/goal, autopilot and the case for leaving it alone

The /goal token is the kit's run-until-done mechanism. The README describes it as one copy-pasteable block that keeps the agent running phase after phase without stopping, and that resumes the run in a fresh session. That resumption is the interesting part. Progress notes are written to disk every phase, so a run survives a memory reset and picks up where it left off. Autopilot comes in three lanes, quick, fast and full, and the README frames them as matching ceremony to risk.

Here is the trade-off the README does not resolve. It advertises autopilot loops with zero need for human gate. But the same document says the SPEC phase exists so you can sign off in plain language before design starts, and that every later phase measures back against your SPEC. Those two positions sit awkwardly together. A run that never stops for a human is a run where the SPEC was written once and never re-checked by the person who owns the requirement.

Phase programs are the other structural piece. Large projects are split into independent phases with quality gates between them, and the README says the agent can insert new phases, reorder work and skip blocked steps as it learns. Self-reshaping plans are useful on long work and hard to audit afterwards. If you need a fixed, reviewable plan for compliance reasons, this is the wrong tool.

The 36 validators and what they actually check

The kit ships 36 validators, described as mechanical correctness checks rather than opinions, guarding the kit's own structure and catching drift before it ships. The README also lists 15 agents, 33 skills and 10 hooks wired together out of the box, with skills organized in layers and discovered automatically.

Read the scope carefully. The validators guard the kit's own structure. They are not a test suite for your application, and nothing in the material suggests they lint your product code. That distinction matters when you evaluate the kit: it improves the reliability of the workflow layer, not the correctness of the software the workflow produces. Your own tests still have to exist. The 10 hooks are described as safety hooks, but the README does not enumerate what each one intercepts, so treat that count as a claim to verify by reading the hook definitions in the repository rather than a guarantee about what gets blocked.

Where a single CLAUDE.md file beats this

The obvious alternative is the plain instruction file that Claude Code and Codex already read: a CLAUDE.md or AGENTS.md at the repository root, plus a short spec document you keep updated by hand. That approach has no installer, no hooks, no migration step, and no risk of a curl command touching your content directories. It also has no phase gates. The agent reads your conventions and starts working.

The difference in approach is memory location. A CLAUDE.md is static context the agent reads at the start of a session; vibecode-pro-max-kit writes progress notes to disk every phase and claims to keep its own shared notes current after each feature ships. If your work fits in one session, the static file wins on every axis: setup cost, auditability, and the number of things that can break. The kit's value only appears when a feature spans sessions and the agent's recall is the bottleneck. The README's own compatibility list is broad (Claude Code, Codex, Cursor, Windsurf, Copilot and more), but the material does not document per-tool behaviour differences, so a non-Claude tool is an untested path from the reader's point of view.

Maintenance cost and the licence boundary

Running this kit means tracking its releases. The three most recent entries are all installer or migration fixes, and v3.2.3 explicitly changed vc-update to run adaptive migration on version-equal installs. Skipping updates leaves you on an installer with a known data-loss bug, which is a poor place to sit. The kit also writes files into your project, so every update is a merge question: which of those files are yours and which belong to the kit. The v3.2.4 fix, deferring content directories to vc-update, is the maintainers drawing that line, and it is worth confirming it holds for your directory layout.

The MIT licence permits commercial use, modification and redistribution. It provides no warranty, and it says nothing about the safety of running install.sh against your working tree. This is not legal advice; if the kit writes into directories that hold client code or licensed assets, read the licence text and your own obligations rather than assuming MIT settles the question.

Editorial conclusion

Adopt it if you already drive Claude Code or Codex on multi-session features and you want the phase gates and the on-disk progress notes that a single CLAUDE.md cannot give you. Do not adopt it for one-line fixes, for a codebase you have not committed, or if you are unwilling to read install.sh before running it. Verify three things first: that vc-update defers your content directories instead of overwriting them, that your agent tool is one of the seven the kit claims to support, and that the autopilot lanes (quick, fast, full) map to work you are willing to leave unattended.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. withkynam/vibecode-pro-max-kit on GitHub