vibecode-pro-max-kit: the release before this one was an install.sh data loss fix

The release before this one was an install.sh data loss fix

The feature table opens with the install promise:

> One curl line drops it into any project. It detects new vs. returning users and never overwrites your files.

Three claims in one cell. The detection of new versus returning users, and the promise that nothing is overwritten.

Now the release history. Three tags are visible, all in June 2026. v3.2.3, published 2026-06-20, is titled as running adaptive migration on version-equal installs. v3.2.4, published the same afternoon, is titled an install.sh data-loss fix, with the fix described as deferring content directories to the update command. v3.2.5, published 2026-06-21, is Windows install guidance.

So the second-newest release exists because the install script lost data. And the sentence promising that it never overwrites your files sits on a page published after that fix.

That is not a contradiction in the strict sense, since a fixed script can make a true promise. It is a reason to read the changelog before running an install script as a user into a directory you have not backed up, particularly since the documented path is a remote script fetched and executed in one line and the exact command is not printed in the visible text.

The fix itself is informative: content directories are now deferred to the update step rather than being handled during install. Which means the question of what happens to your content moved, it did not disappear.

RIPER-5 names five phases and the table lists seven

The workflow is labelled with a name and then described with a list, and the two disagree on length.

> RIPER-5 plan-first workflow. 7 gated phases (Research, Spec, Innovate, Plan, Validate, Execute, Update-Process) stop the agent from jumping straight to code.

The name says five. The parenthetical says seven, and then names seven: Research, Spec, Innovate, Plan, Validate, Execute, and a seventh that is a process update rather than a stage of work.

The five-stage version of this name is a well-known methodology in which the phases are Research, Innovate, Propose, Execute and Review. What this kit lists is not that set. It substitutes Spec for Propose, adds a Validate stage and an Update-Process stage, and drops Review.

None of that is wrong on its own; a plan-first harness can have whatever stages it needs. But a reader who searches for RIPER-5 to understand the phases will find a different five, and the name on the card is doing less work than it appears to.

The seventh stage is the interesting one for anyone planning a large piece of work. Update-Process is where the kit records what it learned, which connects to the claim that project memory is written and kept current after every feature ships, so the process stage is where the plan and the memory are supposed to converge.

Gated phases and no human gate are both on the page

The repository description advertises autopilot loops with no need for a human gate. The feature table advertises seven gated phases and a run-until-done token that keeps the agent going phase after phase without stopping.

Both statements appear in the project's own material. Reconciling them requires knowing what the word gate means here, and the table answers that in a card of its own: 36 validators, described as mechanical correctness checks rather than opinions, guarding the kit's own structure and catching drift before it ships.

So a gate is a validator, not a person. The agent runs a phase, the validators run, and a failure is fixed and re-checked without anyone approving anything.

Two related cards make the loop mechanics concrete. The self-healing loops are a plan-check-fix pass and a test-check-fix pass, each running up to ten cycles on their own. And the feasibility probes give a verdict of VIABLE or NOT-VIABLE before the agent commits to a design approach, so the harness is capable of telling you that the approach you asked for is not going to work.

Whether that is what you want is the real decision. If you want a run that can rewrite phases, reorder work and skip blocked steps without asking, this delivers that. If you want approval before a phase lands, nothing on this page promises it.

The epigraph above the title is a line from a commercial anime character

Directly above the project name, the page carries an epigraph in italics, attributed to a named character from a commercial anime franchise.

It is a fan-written line for that character rather than a quotation from the source, which is the usual way these get used, and it is presented as the project's motto above the title rather than as decoration further down the page.

This is not a technical problem and it will not affect anything you install. It is a rights question about what a public repository puts at the top of its front page, and it is the kind of thing that is easy to miss when you arrive at a repository through a search result rather than a recommendation.

The rest of the page's positioning is commercial in tone as well. A line above the title credits the kit to engineers at a named company and describes that company as building AI agents with computers for go-to-market work, and another line describes the toolkit as built by world-class engineers. Those are self-assessments rather than claims you can check, and they sit in the same visual band as the feature cards, which makes it easy to read marketing as documentation.

The update command migrates even when the version has not changed

The release titled v3.2.3 does something that most update commands avoid: it runs adaptive migration on version-equal installs.

A version-equal install is one where the kit you are running is the version you already had. The ordinary expectation is that nothing happens. Here, migration runs anyway.

The reason is visible in the next release's title, which defers content directories to the update command. The two changes are the same change seen from two sides: the install step stopped touching content, and the update step took over doing it. Which means the migration that now runs on an equal-version install is the thing that owns your content directories.

So the update path is not a no-op for an unchanged kit, and the changelog is the place that says so. Three releases over two days in June 2026, all three titles about update mechanics rather than features, is a sequence worth reading in order before running the update on a project you care about.

The repository is a JavaScript project with three Node scripts at the top level, a manifest file, an install shell script and an end-to-end test file for kit flows. There is also a migration document and a security policy, both of which are the right places to look before an update.

Fifteen agents, thirty-three skills, ten hooks and thirty-six validators

The counts are worth listing precisely because they appear in two places and do not match.

The repository description says 15 agents and 33 skills. The feature card says 15 agents, 33 skills and 10 hooks. A separate card, on its own, says 36 validators.

So the kit comprises four named populations: 15 agents, 33 skills, 10 safety hooks and 36 validators. The description mentions two of them, the card mentions three, and the validators are only in their own card. Nothing contradicts itself, but the headline number in search results is not the full inventory.

The tree explains the layout. Three agent-tool directories sit at the top level, alongside an agents directory, which is what you would expect for a kit that installs configuration for Claude Code, Codex and the agent-agnostic convention the other tools read. The features card claims the skills are layered and auto-discovered so the agent finds the right one for the current step.

Two routing behaviours are described and neither is quantified. A strategy picker weighs one agent against many against a coordinated team before each phase, with cost estimates, and picks the cheapest that fits. A model router keeps the expensive model to writing code and gives everything else to the cheaper one.

Both are sensible defaults and both are unverifiable from the page, because no figure appears for what any of this costs. There is no token count, no run cost and no comparison anywhere in the README.

Ten README languages and a documented lifecycle of four commands

The documentation effort is real and worth noting separately from the features.

There are ten README files. English is the default and the other nine live under a translations directory: Simplified Chinese, Japanese, Korean, Vietnamese, Brazilian Portuguese, Spanish, German, French and Hindi. Translations maintained by a project this size are unusual and useful, though they carry the risk of drifting from the English original.

The lifecycle is four commands, described as install, setup, update and publish, each one command. The update command is the one with the migration behaviour described earlier. The publish step is the least documented of the four on this page, which is a little surprising for a kit whose selling point includes sharing.

The workflow entry points are `/goal` for a run that continues phase after phase and resumes in a fresh session, `agent-team` for a coordinated group, and `workflow` for the loop. The `/goal` card makes the resumability claim explicit: one copy-pasteable block keeps the agent running without stopping and resumes the run in a fresh session, which pairs with the claim that progress notes are written to disk every phase so a run survives losing its context.

That last property is the most defensible claim on the page. Writing state to disk every phase is what makes a long run survivable, and it is the behaviour a reviewer can check by looking at the project after a run rather than by reading a card.

Editorial conclusion

This kit suits someone who keeps losing an agent's place mid-task and wants the plan written down before any code appears, and the phase program structure is the part that will survive contact with your project. Two things to check before you install it into something you care about. Read the release notes rather than the readme's reassurance: the version immediately before the current one is titled an install.sh data-loss fix, which means the install script has already destroyed content once, whatever the current claim of never overwriting your files. And decide whether you want human checkpoints. The page promises both gated phases and autopilot with no human gate, and those are not in conflict only if you accept that the 36 validators are the gate. There are no cost figures anywhere, so the cost-saving claims are unquantified.

Frequently asked questions

Official sources

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