VibeWise: a Claude Code plugin that makes the model stop and ask

What the plugin actually changes about the loop

VibeWise describes itself in one line: you build, AI writes. The mechanism behind that slogan is a set of checkpoints inserted between the request and the code.

The claim in the README is that Claude asks for your approach first, helps you examine tradeoffs, and explains unfamiliar concepts, and that you shape the design and decide when it is ready to implement. After implementation, Claude explains what it changed and why.

That is a behavioural contract rather than a feature list, and it is enforced in the conversation rather than in configuration. The plugin has three checkpoint types, and the README gives each one a job in a table: a Build checkpoint where you reason through how to approach the problem, a Design checkpoint where you review the design and confirming records it while no code is written, and an Implementation checkpoint where you review the specific code changes and authorise them.

The naming is precise about authority. Confirm and continue records a design decision. Implement this step authorises Claude to write code. Those are different verbs for different permissions, and the plugin treats them as different actions.

The intended audience is stated plainly: aspiring engineers, junior developers, and experienced engineers exploring an unfamiliar stack. In all three cases the goal is the same, which is to practise planning how the pieces fit together, anticipating failures and checking the result while keeping ownership of the decisions.

Installing it as a marketplace plugin

Requirements are modest: Claude Code itself and Python 3, with no extra Python packages needed. The README is specific that Python is used to restore learning context and reset learning notes, which tells you the plugin stores state somewhere and manipulates it.

There is a wrinkle worth knowing before you start. VibeWise has been approved for Anthropic's Claude directory but is not listed in the public community marketplace yet, and the author expects it to appear. In the meantime it is installed through a GitHub marketplace, and the commands are run one at a time in Claude Code.

First, add the marketplace:

/plugin marketplace add nykooi1/vibe-wise

Then install the plugin from it:

/plugin install vibe-wise@vibe-wise

After that, one detail is easy to miss and matters later: automatic updates are disabled by default for third-party marketplaces. To enable them you open the plugin interface, go to Marketplaces, select vibe-wise and enable auto-update.

Finally, restart Claude Code in the project you want to work in and start the session:

/vibe-wise:learn

Setup asks one question at a time, with arrow keys and Enter for choices, and there is a Use defaults option for people who do not want to configure preferences first.

Two situations are covered: starting fresh, and joining an unfamiliar repository, where Claude inspects the code and sketches a small system map before you begin.

The checkpoint protocol, and how strict it is

The most important design decision in the plugin is that the checkpoints are not three mandatory stops, which is easy to miss and changes how you use it.

The README states this directly: when you are ready to code, the Implementation checkpoint also confirms the design, skipping a separate Design checkpoint. So the three-stage model is a scaffold, not a toll booth, and a user who already knows what they want can move in one step from discussion to authorised code.

What you get at each stage is different in kind. A Build checkpoint poses a reasoning problem, as in the worked example where a note belongs to several folders and you have to decide what happens to a shared note when one folder is deleted. A Design checkpoint presents a proposal with its reasoning and asks you to confirm or discuss. An Implementation checkpoint describes the specific change and asks you to authorise it.

Both confirmations offer Discuss, described as a way to ask questions, clarify anything confusing, or explore alternatives before deciding. That option is the escape hatch that makes the rest tolerable: a checkpoint you can talk your way out of is not a gate, it is a pause.

The README also explains a boundary that matters for how you phrase requests. Describing what you want sets the requirements, and a Build checkpoint asks you to work out how it should function, so stating a feature preference does not approve an architecture. That distinction is enforced by the plugin's structure rather than by politeness, which is what makes it more than a system prompt suggestion.

A worked session, and what the example is really showing

The README includes a condensed transcript adapted from a real learning session, and it is more useful than a feature list because you can see exactly what the plugin asks and what it refuses to assume.

The scenario is a notes application where users sign in, create and edit private notes and organise them into folders. The first turn is the user's statement that a note can be in several folders and that deleting a folder should delete its notes. Claude's reply is a Build checkpoint pointing out that a shared note is in two folders and asking what should happen to it in the other one when one folder goes.

The user answers: keep it in the other folder, and if a note has no folders left, keep it outside any folder. Claude then reframes that as separating deleting a folder from deleting a note, and asks how you would represent folder membership without copying the note.

The answer is a links table with note_id and folder_id. Claude draws the relationship as a small diagram, then produces a Design checkpoint proposing the schema and the deletion behaviour, with the reasoning that loading a folder's notes needs a lookup through the links, and offering Confirm and continue or Discuss.

Later, an Implementation checkpoint restates what will be added, including that tests will cover deleting a folder while preserving notes and their membership elsewhere. After the work, an implementation report lists the schema migration, the deletion operation, and the tests that were added and run.

The example demonstrates a specific discipline: the plugin declines to treat the user's first statement as a specification. It finds the contradiction in it, forces the edge case to be resolved, and only then proposes an implementation. The small diagrams are part of that: they are how a relationship gets checked before it becomes a table.

Levels, and what stays yours at each one

The plugin offers three support levels, and the framing is careful: experience changes the support you get, not your ownership of decisions.

At Beginner level, Claude explains unfamiliar pieces, uses diagrams and asks smaller reasoning questions. At Intermediate, there is less introductory context and more exploration of interactions and tradeoffs. At Advanced, it probes difficult constraints, failure modes and design assumptions.

The second half of that sentence is the load-bearing part. Across all three levels, everyone reasons first, which means the checkpoints do not disappear for an experienced user and the plugin does not decide anything on your behalf.

That distinction matters because the usual objection to scaffolding is that experienced developers do not need it. Here the answer is that the scaffolding is about who makes the decision rather than about how much explanation you get, and the Advanced level exists for people who want the questions to be hard rather than absent.

Two related behaviours are worth noting alongside the levels. When Claude proposes implementation details beyond what you asked for, it separates them from your decisions in a short list or table with a note on why each addition matters, and you can question or change any item. And after implementation, the report covers what changed, how the key code works, why it fits your decision, any tests added or updated with what they cover, and which checks ran with their results.

Under the hood: skills, hooks and why Python is there

The repository layout is small and tells you how a Claude Code plugin is put together.

At the top level there is a .claude-plugin directory with an icon, a LICENSE file, a README, and then assets, docs, hooks, skills and tests directories. That is the conventional shape for a plugin: declarative metadata, skills that define behaviour, hooks that tie into the host tool's lifecycle, and tests.

The hooks directory is where Python earns its place. Python is used to restore learning context and reset learning notes, and requires no extra packages, which points at a script run at session boundaries: one that reads back state so a session resumes where the last stopped, and another that clears it on request. Since no third-party packages are needed, it is a standard library script, which keeps installation to a Python 3 runtime.

The tests directory is the interesting one for an evaluator. A plugin whose behaviour is prompt text is testable in the way that matters: you can assert that a checkpoint appears, that a confirmation records a decision, or that implementation does not start without authorisation. Whether those tests exist is not stated in the README, so the directory's contents are the thing to look at rather than its presence.

The docs directory holds the documentation that does not fit in a README, and assets the images. The project is MIT licensed, and nothing was committed to the repository after 2026-10-01.

Where VibeWise is the wrong tool

It is built for a specific relationship with an assistant, and that relationship has costs and requirements.

The first cost is velocity. Every design decision becomes a round trip, and the plugin's premise is that this is a good trade. On a well-understood change, a team with a shared codebase and a clear plan, it is overhead paid for a benefit that person does not need. The README does not hide this: the checkpoints are presented as something you can skip, and skipping them is the escape hatch for exactly this case.

The second requirement is a model willing to stop. The plugin works by making the assistant ask rather than act, which means its behaviour depends on an agent that follows instructions at that level of detail. Plugin behaviour is version-coupled to Claude Code too, since the plugin interface, the marketplace commands and the slash command namespace all come from the host tool, and a host change in any of the three breaks a plugin that has not been updated.

The third is provenance and support. It is one author's plugin, not listed in the public community marketplace yet, with a single install path through a GitHub marketplace. The README states the expectation that it will appear in the public marketplace, which is a plan rather than a fact, and until then you are installing from a personal repository.

The fourth is that the teaching value depends on engagement. If you confirm every proposal without thinking, the checkpoints become clicks and the plugin produces ceremony instead of learning. Nothing in the plugin can fix that, and the README's own instruction to answer in plain English and ask for help is aimed at a user who wants the questioning to be real.

Editorial conclusion

Adopt VibeWise if you are learning an unfamiliar stack while building in it, or if you are a junior developer who wants the assistant to explain rather than produce. The design checkpoint recording your decision before any code exists, and the implementation report explaining what changed and which checks ran, are the two behaviours that make it different from a prompt template. Do not adopt it on a deadline feature, because every additional step is a round trip you have chosen to pay for, and the plugin's own documentation treats skipping checkpoints as legitimate rather than something to optimise around. Verify four things. Install it correctly, since the public community marketplace does not list it yet and the author expects that to change, so check where your plugin came from before trusting it. Turn auto-update on deliberately, because it is off by default for third-party marketplaces and a plugin that changes how your assistant behaves should be updated on your terms. Pick your level honestly, since Beginner, Intermediate and Advanced change the teaching depth and not your authority over decisions, so choosing Advanced for a familiar language only costs you time. And confirm the Python dependency, because the plugin uses Python to restore learning context and reset learning notes, so a machine without it will fail at the least convenient moment. Start with /vibe-wise:learn on a small feature, answer the setup questions with Use defaults, and read the first build checkpoint before you answer it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nykooi1/vibe-wise on GitHub
4. README