VibeCodingAssistant keeps your original prompt as the source of truth and pairs each reviewer with a different vendor from its author

Your prompt stays the source of truth, and nothing rewrites it into a spec

The stated principle of this system is that the user's original prompt is the highest-priority source of truth, and the next sentence is the one that makes it a real constraint rather than a slogan. The system does not rewrite your request into a separate authoritative requirement document before planning.

That is worth pausing on, because generating a specification is what most orchestration layers do. A planner that emits a spec and then plans against the spec introduces a translation step, and every translation step is a place where your actual requirement quietly becomes something the planner found easier to decompose. By keeping the prompt authoritative and treating it as the thing every role reads, this design removes that failure mode.

The escape hatch is conversation. Any constraint you add later, through the `revise` command, the `restart` command, or by saying it in conversation, becomes new high-priority context entering the next workflow round. So the requirement evolves without being reified into a document that can drift out of date.

The orchestration shell itself, the role named VibeCodingAssistant, sits outside the four engineering roles and handles talking to you, creating tasks, advancing the workflow, displaying artifacts, recording state, and generating a final task record. That separation is deliberate: the role that tracks progress is not the role that writes code, so the state machine cannot be quietly optimised by the model doing the work.

The repository says all of this bilingually, Chinese and English side by side, and the whole README opens with a pre-release notice repeating that it is at an early stage and may contain bugs.

Five roles, and the Developer cannot start until you approve the plan

The team has four engineering roles and one coordinator, and each has a narrow job description.

The Architect understands the original request, produces the plan, and breaks large tasks into finer execution units or subtasks. The Plan Reviewer reviews that plan and looks specifically for risks, missing details, unclear boundaries, and insufficient verification. Those four categories are a useful review rubric rather than a general instruction to be critical.

The Developer is where the human gate sits. It enters the execution phase only after you approve the plan, and then modifies code according to the plan rather than according to its own reading of the original request. That is the single most consequential design decision here, because it is the difference between a system that plans and executes and one that proposes and waits.

The Final Reviewer works independently after execution. It reviews the code changes, the test results, and the implementation logs, then decides whether the task passes or goes back for more changes. Reading implementation logs alongside the diff is the detail that distinguishes this from a lint pass.

The four-step sequence is therefore plan, review the plan, execute, review the execution. Two review gates, and the second one can send work backwards.

What the roles do not do is worth noting too. There is no role that talks to you and asks clarifying questions during execution, and no role that decides the plan is wrong. A Final Reviewer can reject, which is not the same as being able to replan, and that constraint looks deliberate: a reviewer that could rewrite the plan would be a second Architect wearing a different hat.

Review should use a different model than the author, and the table is built around that

The project states the reason for splitting vendors across roles in one sentence: the Review stage should preferably use a different model to review the previous model's output, in order to avoid having the same model plan, approve, and execute its own work.

The recommended role assignment is a four-row table, one row per workflow level, and reading it across shows the principle being enforced rather than merely stated.

| Workflow | Architect | Plan Reviewer | Developer | Final Reviewer | | --- | --- | --- | --- | --- | | Low | Codex | Codex | Codex | Codex | | Medium | Codex | Claude | Codex | Claude | | High | Claude | Codex | Codex | Claude | | Extra High | Claude | Codex | Codex | Claude |

In Medium, the Architect is Codex and the Plan Reviewer is Claude, so the plan is judged by a model that did not write it. In High and Extra High, those two swap, so the judgement still comes from the other vendor while the more capable model moves to the Architect seat. The Developer stays on Codex across every row above Low, because execution is the one stage the project treats as execution-shaped work.

So the rule is not that bigger tasks get Claude everywhere. It is that the Architect and the Plan Reviewer are always different vendors, in both directions.

Low is the exception, and it is worth being blunt about that: in Low mode all four roles are Codex, which means the cross-model protection is absent and a single model can plan, approve, and execute its own work. The project accepts this deliberately for cost, and the justification given is that when the task is itself low-risk there is no need to involve Claude for extra review every time. That reasoning is sound for the class of task Low covers and would be wrong for anything else, so the mode boundary is doing real work rather than being a label.

Low is for colour changes, and Medium is the default recommendation

Four workflow modes are offered, and the definitions are about task risk rather than task size.

Low covers very small changes: copy, colours, styling, small bugs, and simple component adjustments. That is the whole justification for putting a single vendor in all four seats, and reading the mode against that list makes the cost saving defensible. Nothing in a copy edit is going to be caught by a second opinion that the first opinion missed.

Medium is the default recommended mode and is described as suitable for most daily web coding. It is the first mode where the plan gets reviewed by a different vendor, and it is where the cross-model rule starts paying for itself.

High and Extra High share the same role assignment, Claude as Architect and Codex as Plan Reviewer, so the difference between them is not visible in the table above. The documentation on those two modes is cut off partway through describing the Medium combination in the copy available here, so what separates them cannot be read and should be checked in the repository.

A practical profile configuration is given alongside the modes, and it pins the reasoning effort as well as the model names. Prompt polishing uses ChatGPT Plus, on the reasoning that if you already have the subscription you can keep that work inside it. The conversation and orchestration layer of the assistant uses DeepSeek with the model `deepseek-v4-flash`. Codex coding roles use `gpt-5.5` at `effort: xhigh`, and Claude planning and review roles use `claude-opus-4-7` at `effort: high`.

The stated reason for putting the cheap model on the orchestration layer is volume rather than difficulty. It is described as very cheap and suitable for high-frequency work such as daily conversation, task routing, state explanation, and Lark message handling, where the most expensive model is not always needed. What that model is explicitly not trusted with is understanding a vague requirement, which is why the recommended workflow starts by polishing your prompt in ChatGPT before the task is created.

One runtime dependency, and a pinned axios override

The dependency list is one package. The runtime dependencies resolve to the Lark SDK for Feishu, which is not an accident: the whole system is delivered as a bot in that workspace, so the messaging platform is the only thing the orchestrator needs to talk to in order to do its job.

Alongside it sits an override that pins axios to a floor version. Overrides exist in package manifests for one reason, which is that something further down the dependency tree resolved to a version you do not want, and pinning it there is how you fix that without a fork. Seeing one here, rather than seeing axios listed as a direct dependency, suggests it was carried up from a transitive resolution rather than chosen.

The dev dependencies are the expected set for a TypeScript project: type definitions, a TS runner, the compiler, and a test runner. Tests run through vitest with a configuration file at the repository root, and there is a `tests/` directory.

One packaging detail does not quite add up, and it is the kind of thing that tells you how the project evolved. The package is marked private, yet it declares a binary entry pointing at the compiled CLI and defines a `prepublishOnly` script. A private package is never published to a registry, so that publish hook can only fire on a local operation, and the bin entry matters only when something links the directory rather than installing it from a registry. Both may well be deliberate for a tool people are expected to clone and link, but if you expected to `npm install` this by name, the manifest is telling you that path is not supported.

It runs as a Lark bot, and the config references env names rather than keys

The delivery mechanism explains several parts of the layout. There are two entry points: a script that runs the TypeScript CLI directly, and a second that runs a separate Lark CLI module. The published binary, for anyone who builds and links it, points at the compiled CLI.

Windows users get two launchers in the repository root, a batch file and a PowerShell script, both named for starting the assistant. There is also a `scripts/` directory containing the setup, preflight, and hygiene programs, plus a task-usage summariser, and an `assistant-skills/` directory at the top level, which suggests the assistant ships its own skills to the coding agents it drives.

Configuration is split in a way that is worth copying. The example config is a JSON file with a name that describes it as an example, and the environment template states plainly that you should copy values into a separate local file or set them in your shell, and that you should not put real secrets in the template.

More importantly, the template does not name keys. It names the variables that must exist and says the variable name must match a field inside the profile configuration, so the JSON holds the name of an environment variable rather than the value. That means you can commit the profile file, rotate a secret without editing it, and have the same config work across environments where the secrets differ. The optional pattern is the same: add only the environment names that the profiles you actually use reference.

The credentials themselves are minimal for what the system does. Lark or Feishu bot credentials, an application id and secret, plus one provider key for the assistant's own orchestration layer, and optionally one more for additional role profiles.

Preflight, doctor, setup, and hygiene, and publish is gated on preflight

The script surface is where the operational discipline shows, and there are five named maintenance commands rather than one.

There is a preflight program, a setup program, a doctor mode that runs the preflight with a diagnostic flag, a repository hygiene check, and a task-usage summariser for reporting. The start script chains the preflight before the Lark client, so the system will not begin serving without having passed it, and the publish hook runs the same preflight.

That last detail is the one that would matter most to a maintainer. Gating publish on preflight means a release cannot be cut from a tree that fails its own environment checks, which is a cheap guard against the class of problem where a working checkout stops working on someone else's machine.

Onboarding is documented twice, with a general start-here document and a separate one for beginners. Given the README's bilingual presentation, that pairing suggests the project expects a mix of experienced and new users, which is consistent with the pre-release notice inviting issues.

The status is worth stating precisely. This is a pre-release, described in both languages as still at an early stage with bugs expected and issues welcomed, and the maintainers say they will review reports promptly. The single tagged release is version 0.1.0, and its title names what it contains: the Lark integration. The licence is GPL-3.0-only, the default branch is master, and the last push to it was 11 August 2026, so the tree has not moved in the seven weeks since.

Editorial conclusion

VibeCodingAssistant fits someone already paying for two coding assistants who wants the plan reviewed before the code is written, rather than one more prompt wrapper. The refusal to rewrite your prompt into a generated specification is the part worth stealing regardless of whether you use it, since that is where multi-agent setups usually start losing fidelity to what you actually asked for. Two things to check first. Which mode you run, because Low uses one vendor for all four roles and accepts the loss of independent review to save money, so it is only appropriate for a colour change and not for anything touching auth. And the operational surface, since this is a Lark bot driven by start-assistant scripts and a preflight that also gates publishing, so it expects a Feishu workspace and an environment file wired to named variables. It is explicitly a pre-release with bugs outstanding, and the single tagged release is the Lark integration itself.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. PatrickStarVibe/VibeCodingAssistant-Connect-Your-Codex-And-Claude-Code on GitHub
4. README
5. Releases