vibe-coding-toolkit: the most important piece is a plugin from a marketplace, and the repository ships no code

The tool the author rates highest belongs to somebody else

The most emphatic recommendation in the repository is not the author's work. It is a plugin called Superpowers, installed from a marketplace maintained by the model vendor, and the author argues in an important callout that it is the single most capable tool in the whole toolkit and the one thing to configure if you configure only one thing. The reason given is a discipline rather than a feature: it is what makes an agent explore the intent of a request, plan, and only then write code, instead of committing to the first plausible reading of something under-specified. Everything else in the repository is framed as supporting that piece, with subagent orchestration and lint gates named as the chassis. The onboarding teaser shows the whole dependency chain in four commands:

npm install -g @anthropic-ai/claude-code
/plugin marketplace add anthropics/claude-plugins-official
/plugin install superpowers@claude-plugins-official
cp templates/CLAUDE.md.template CLAUDE.md

The first installs a vendor CLI, the second and third add a marketplace and a plugin from it, and the fourth copies this repository's only real artefact, an instruction template, into your project. So the practical dependency chain is that a curated toolkit rests on an externally maintained plugin, which means the method is portable and the tool is not.

There is no installer, except there is one, from somewhere else

The onboarding section is unusually candid about this. It says plainly that there is not, yet, an installer that detects your stack and writes everything for you, and that the flow is copy the right file and type the right command. Then, a couple of paragraphs later, it tells you to skip ahead to an init command from a different tool that sets the base up by itself, and describes the rest of this repository as material for understanding what was assembled rather than for assembling it from scratch. Both statements are true and they point in opposite directions. The first describes what this repository ships, which is documents and one template. The second acknowledges that a third-party tool has taken over the bootstrapping. What is not said is where that tool comes from, who maintains it, or whether the setup it produces matches what the playbook documents.

The one-line path asks your agent to execute instructions fetched from a moving branch

For readers who do not want to install anything from the toolkit, there is a shortcut: paste two lines into your agent that tell it to read a document at a raw file URL on this repository's main branch and execute the prompt inside it, with a line cap passed as a parameter. The agent fetches three already written lint rules, adapts them to the real structure of your project, and reports which files exceed the cap. It changes nothing, and the document is explicit that measuring and fixing are separate jobs. The trust model is the thing to notice. An instruction to fetch and execute a file from a branch that can change at any moment is the agent equivalent of piping an install script into a shell, and it is the recommended path for the audience that wanted to avoid installing anything. Reading that prompt file in a browser before letting an agent run it costs one minute.

One hard number governs the whole quality gate: 350 lines per file

Across a repository of methods and opinions, exactly one number is enforced rather than suggested. The file-length ceiling is 350 lines, passed to the lint prompt as a parameter and described as part of the rules that apply whether or not you install the toolkit. Two documents carry it: one that installs and measures, one that breaks large files apart. The refactoring document states its rule explicitly, that files should be split by responsibility rather than by line count, into business logic, interface components and data access, one file per commit, with tests and type checking run between each step. That is a genuinely better rule than a line limit, because a limit that is checked without a splitting strategy produces files that satisfy the number and none of the intent.

The source project is under NDA, which is why this history is short

One paragraph explains the shape of the repository better than any feature list. The practices come from a real private production project in fintech under a non-disclosure agreement, so the source code cannot be shown, and what is published is the method extracted and genericised rather than a public record of that project. The document then draws the conclusion about itself: the history of this repository is short because this is where the method is documented, not where it was built. That is an honest frame and it explains several facts at once. There is one commit's worth of context to learn from, there are no releases to pin, and there is no way to check a claim about how something behaves in production, because the production instance is not visible. Read the method as a set of opinions from one experienced developer, applied to a codebase you cannot see.

The repository root has no source directory, and the project records its language as JavaScript

The top-level listing is five entries: a gitignore, a licence file, the readme, a documentation folder and a templates folder. There is no source directory, no test directory, no build configuration, no continuous integration, and no package manifest. The primary language, however, is recorded as JavaScript, which means whatever code exists lives inside the documentation tree or inside the templates, most plausibly as the plugin definitions, hooks or scripts that the documented workflow expects to exist in your own project rather than here. That is consistent with the delivery model: the repository does not run, it instructs. It is also why the quality claims cannot be checked from the outside, since there is nothing here to lint, type-check or test, and the only executable artefact named in the visible text is a template you copy into your project as your own agent instructions.

The documentation is Portuguese, with one readme and no English version

The entire document is written in Brazilian Portuguese, from the subtitle through the section anchors, which are themselves Portuguese words, to the inline explanations of technical terms. The author says he explains any technical term the first time it appears, and the text does exactly that in passing, defining lint warnings as notices from a tool that analyses code for risky patterns without needing to run it. Only one readme exists in the repository listing, so there is no English translation to compare against, which means an English-speaking reader is relying entirely on this article's description or on a translation layer. The documentation tree itself is well organised by number, with a numbered installation document, an onboarding playbook, a tools directory with numbered entries for the third-party plugin, subagent orchestration and the lint gates, and a prompts directory holding the two executable lint documents.

Editorial conclusion

Take the method, not the dependency. What is genuinely useful here is unglamorous: a fixed cap on file length, a rule that measuring and fixing are separate jobs, a protocol for running parallel agents without colliding on files or commits, and an explicit list of the ways sessions go wrong. Those are decisions you can adopt whether or not you install anything. Two things to know before you follow the onboarding path. The centrepiece is a third-party plugin installed from a marketplace, so the toolkit's value depends on a component you do not control, and the repository ships no releases, so the version you get is whatever the branch holds. And the one-line shortcut asks your agent to download and execute a prompt from a moving branch, which is the same trust decision as piping a script into a shell, made with an agent instead of a terminal. Read the prompt file yourself first. The documentation is also entirely in Portuguese, with no English version in the tree.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. soumatheusgomes/vibe-coding-toolkit on GitHub