@virajp.dev/claude-plugins

vwf — Product → Blueprint → Plan → Execute for Claude Code

virajp-plugins is a plugin marketplace for AI coding agents, built around vwf: an opinionated workflow that turns a vague idea into a shipped, reviewed product through four disciplined phases.

• Product — pin the outcome contract: the problem, the users, measurable goals, and the order to build in. Everything downstream must trace to it.
• Blueprint — keep an always-current blueprint of the whole product, organized by flow (every flow serving a product goal, entities as the data contracts under them), closed by a whole-product coherence review.
• Plan — diff the blueprint against the real code for one slice, planning its unbuilt dependencies as their own chained plans first, and write the delta to apply.
• Execute — implement the plan autonomously under strict TDD, with code review, security review, E2E acceptance, and UX conformance per the rules, landing per the consent the plan recorded at approval — merged on green when consent says yes, stopped at the report otherwise — with post-deploy verification and a production-feedback intake closing the loop.

You drive it with slash commands. Claude does the work — asking one question at a time while authoring, running unattended while executing — and never merges until you approve. The whole manual, command by command, is the vwf manual. Journey-shaped guides — starting fresh, adopting vwf in a codebase that already works, and running a live product — are in the how-to guides. Both are published at claude-plugins.virajp.dev and authored under site/ in this repo.

Around it the marketplace ships one more plugin — stackgen, which materializes whatever stack you pin, right down to the repo's toolchain manager and its gates. It is a vwf dependency, so installing the workflow brings it. That is the point of the split: vwf owns the workflow and names no technology at all, and every concrete choice — the language, the framework, the cloud, the task runner — arrives as a stackgen pack landed in your own repo rather than as a plugin each collaborator has to install. They install through Claude Code's own plugin commands, straight from this repo — or through one small CLI, @virajp.dev/claude-plugins, which sequences those same commands.

These are Claude Code plugins, authored natively. Other agents are served by a prompt, not a bespoke build — see that section for what you do and do not get.

Caveats

vwf is deliberately heavyweight, and some of what it needs is a real adoption blocker rather than a preference. Know this before you install.

• It is built for the 1-million-token context window. The orchestrator holds the blueprint, the plan, the registry and each subagent's output at once. On the standard window a real cycle will degrade or overflow.
• It runs opus where judgment decides the outcome, and where nobody is watching — product, blueprint, plan, the blueprint review gates, and every subagent inside the unattended execute run. sonnet and haiku carry the rest. An execute cycle runs several opus subagents per step with fix loop-backs, so expect a meaningful token cost per slice. This is not a cheap workflow.
• It expects a testable, registry-described project. execute enforces non-negotiable TDD and a coverage gate; plan and execute map each slice to a project in an architecture registry you author first. It will not operate on an ad-hoc folder.
• Six binaries must be on your PATH — mise, graphify, uv, python, pnpm and rtk. pnpm is only the default Context7 runner; CONTEXT7_RUNNER overrides it, so a bun or npm user needs no pnpm — see the vwf manual. Nothing checks this at install time, and /vwf:doctor does not cover all six: it blocks on a missing graphify, and on a missing mise once any stack axis is pinned (and /vwf:setup and /vwf:execute halt on either), reports a missing language server as an ordinary finding, reports a missing rtk as a degradation — its hook is guarded, so the run is correct and merely costs more — and says nothing at all about the Context7 runner, while uv and python matter as graphify's runtime rather than on their own. Run /vwf:doctor first regardless, but install all six rather than relying on it to tell you. A seventh, gh, logged in, is needed by /vwf:backlog, which keeps the backlog in a GitHub Project and wants the project scope, by init's forge pass (the default branch and protection on develop and main on the repo scope, the backlog project on project — on a GitLab remote, glab), and by the doctor predicate that reads that forge state back; doctor reports its absence as a degradation with the remedy, and init prints the by-hand list and carries on.
• It is opinionated on purpose. One workflow, one set of conventions, sized for a solo developer or a small team — not a configurable framework for a large org.

The full discussion — how model and effort are tiered per surface, what delegating read-heavy work buys, and the rest of the fit questions — is in the vwf manual.

Install

One command, which registers the marketplace and installs the workflow — stackgen, its one dependency, comes with it:

pnpx @virajp.dev/claude-plugins --all

That is a thin wrapper over Claude Code's own two commands, which work just as well directly — the marketplace manifest is this repo's main either way:

# Register this repo as a plugin marketplace, once
claude plugin marketplace add virajp/claude-plugins

# Install the workflow
claude plugin install vwf@virajp-plugins

Restart your agent afterward so the skills, hooks and MCP servers load, then run /vwf:doctor. It is the closest thing to a preflight now that nothing is gated at install time — though see the caveat on what it does and does not check. On a repo that has never been shaped — empty, or already carrying source — run /vwf:setup: its Step 0 offers init, which lays down the config layout, the gates and the hygiene files the rest of the workflow assumes, in the base repo and every member repo it has, on one consent — a file already in the repo is offered, never overwritten. /vwf:setup reshape runs that pass alone — across every member — and is what /vwf:doctor prints when a shaped repo has fallen behind. You rarely have to remember it: setup re-checks the shape after its materialize pass, /stackgen:stackgen-sync after a re-sync, and /vwf:recall prints one drift line at session start — each offers the reshape, none runs it unasked. A repo is shaped when it carries .config/stackgen.yaml, the values file init writes through stackgen:tool-config; one still on the older mise layout (.config/mise/conf.d/tools.toml and its siblings) is named and left as it is until the reshape that moves it ships.

Once a repo is shaped, its own task library takes the plugin side over: mise run setup:ai:all checks that vwf is installed — at user scope, or at project or local scope for this repo — and only when it is not runs the command above to install it at user scope. Whether or not it installed anything, it then updates every registered marketplace and upgrades every plugin installed at a scope that serves the repo, at that scope. It never installs at project scope. The command above is the one-shot a person runs on a machine; that is what a checkout re-runs.

Scope is yours to choose: --user / --project on the wrapper, or --scope project on Claude's commands, keep a plugin to one repo instead of your user profile. Installing vwf is normally all you need, since stackgen follows it as a dependency at the same scope — but it can be installed on its own by name:

pnpx @virajp.dev/claude-plugins --project stackgen
# or
claude plugin install --scope project stackgen@virajp-plugins

Upgrading is claude plugin marketplace update followed by claude plugin update <name>. Both steps are needed: the first re-reads the manifest on main and picks up its new tag pins, the second fetches them. Skip it and plugin update re-reads the pins you already have and finds nothing.

Each plugin is served from its own <name>-v<version> git tag rather than from main, so plugins release independently — an upgrade moves only the ones whose tag actually changed, and work merged but not yet tagged never reaches you.

If you installed devtools, uninstall it by hand after upgrading. That plugin has dissolved into stackgen, and vwf no longer lists it as a dependency — but an upgrade only stops listing it. The plugin stays installed and enabled, its devtools-v1.5.0 tag still resolves, and its seven skills keep loading, now shadowing the stackgen packs the same doctrine moved into with a stale duplicate of each. Nothing detects that. One command settles it:

claude plugin uninstall devtools

The statusline used to ship here and no longer does — it has moved to claude-status, which is also where the caps hook that pauses a long /vwf:execute run now comes from. If you installed the bar from here, settings.json still names a script this toolkit no longer ships — brew install virajp/tap/claude-status re-points it.

Other tools

These are Claude Code plugins. Other agents — Cursor, OpenCode, Codex — have no common plugin format to render into, so instead of a bespoke build per tool, the route is to ask your agent to do the adaptation, pointing it at this repo. That works today, and it is how most non-Claude use of this toolkit already happens. The full manual is available to agents as markdown — https://claude-plugins.virajp.dev/llms.txt indexes it, every page also exists at its .md URL, and /llms-full.txt is the whole thing in one file.

Paste one of these, adjusting the plugin name:

One plugin, adapted for whatever you are running:

Install the vwf plugin from https://github.com/virajp/claude-plugins/tree/main/plugins/vwf into this project, adapted to the conventions of the agent you are running in. Read its .claude-plugin/plugin.json first — it declares the MCP servers and dependencies the plugin expects. Skills live in skills/<name>/SKILL.md with YAML frontmatter; hooks are declared in hooks/hooks.json with their scripts beside them. Port each of those to this tool's equivalent mechanism, and tell me plainly what has no equivalent rather than dropping it silently.

The whole marketplace, to pick from:

Read https://github.com/virajp/claude-plugins/blob/main/.claude-plugin/marketplace.json and list the plugins with their descriptions, so I can choose which to install here. Then install the ones I name, following the per-plugin instructions above.

What this does not promise

• Nothing verifies the result. There is no test for what Cursor or Codex produces from that prompt. It is your agent's best effort, and the honest expectation is that skills port well, hooks and MCP wiring port unevenly, and subagents port worst.
• Hook and MCP wiring vary most. vwf's hooks include a command rewrite (rtk) — a tool that can only allow or deny a command cannot express it, and the usual adaptation is a refuse-with-correction. MCP transport support differs per tool; vwf's memory server is HTTP, which is the more portable of the two it declares.
• Model-invocation restrictions may be approximated. Some skills are marked so the model cannot invoke them itself and you own the timing (disable-model-invocation: true). If your tool has no equivalent, that restriction is lost — the skill still works, but it may fire when you did not ask.
• Per-plugin dependencies are yours to follow. vwf depends on stackgen; nothing outside Claude Code will resolve that for you.

The plugins

Two plugins, each with its own guide. Installing the workflow brings the other, which is its dependency. The name in code at the end of each entry is what you pass to claude plugin install.

The workflow

vwf — the flagship. The /vwf: commands covering the whole arc: shape a bare repo — or a whole multi-repo product in one run — into the standard layout, onboard it, pin the outcome contract, model the system, sweep a whole-product blueprint to complete coverage, plan one slice as a reviewable diff, execute it unattended and land it per the consent the plan recorded, verify the deploy, and route what production teaches you back to the document that fixes it. It carries cross-session memory, a knowledge-graph layer, session handoff and recall, the Karpathy coding guidelines, and the Markdown and Context7 docs surfaces it absorbed. Both planners write the same plan folder — /vwf:plan for a blueprint slice, and beside that arc the ad-hoc /vwf:change-plan for work with no blueprint slice behind it (tooling, CI, docs, a refactor) — an index.md plus one file per unit, which each commits and pushes at hand-off with a row in docs/plans/index.md's one plan table, so the fresh session can see it. One executor runs both: /vwf:execute <folder> runs a folder of either kind unattended in a fresh context — a code unit through TDD and coverage, the code and security review at the plan's review rows, an edit unit through the wave review — and /vwf:execute next picks the runnable plan with the lowest Priority value from that table, of either kind, and runs it, running each after-landing step the plan recorded run and asking nothing at run time. /vwf:execute all runs every runnable plan in turn, highest priority first, each in its own execute-runner subagent, and stops at the first plan that stops — keeping one line per plan in the session, and asking its run-level questions (one shared worktree, deduped after-landing steps, one release at the end, landing a plan recorded not to merge) once, before the first plan. Beside both sits /vwf:backlog, the sole writer of the backlog project on the repo's forge — a GitHub Project named for the base repo, the prioritised list of work that cannot be picked up now, which every planning and landing command calls to move an item. It names no technology — no language, no framework, no cloud — which is what lets the rest of this list exist. vwf@virajp-plugins

Tooling, design and delivery

stackgen — the principles-driven stack materializer. A stack is a composition of components — the language, its package manager, each framework, the toolchain gates — and each one resolves on its own: a component a shipped pack covers is copied verbatim; an uncovered one is generated — researched via Context7 topic by topic, instantiated against vwf's principles catalog, gated by a reviewer agent and your explicit consent, so a covered language never regenerates because its framework is new. Every concrete third-party name a generated component emits — a package, a runner-invoked tool, a GitHub Action, a container image — is vetted first by stackgen-reputation against public registry, advisory and scorecard data, one verdict per name (pass, warn, block); a block halts that component until you name a replacement, and the same skill is yours to run on any name as /stackgen:stackgen-reputation <ecosystem>:<name> …. Both paths land mostly in the repo's committed .claude/ tree — skills, agents, hooks and rules only, shaped by a closed kind vocabulary whose per-kind topic bar fixes what the output must cover and how deep, recorded in a lockfile per component — so most of the result is plain files your collaborators get with a git pull and no plugin install. Two things cannot be repo files, and each carries its own consent line rather than riding the landing: an MCP server goes into the project's .mcp.json, and a language server is a plugin-manifest feature no project file can express at all, so stackgen writes one small local plugin on your machine — at the fixed path ~/.claude/plugins/local/stackgen-lsp/, holding the union across the repos you have materialized from — and prints the two registration commands for you to run rather than running them itself. That one is user-scoped and your collaborators get none of it, which is the same line your editor already draws; what makes it safe is that every generated server declaration carries an extension map, so it never starts in a repo with no matching files. Re-syncing against newer packs is an explicit, diffed decision — never a silent overwrite, never a settings.json edit without separate consent, and removal is by subtraction, dropping only the keys your repo's lockfile recorded. A pack may also declare repo config files it owns — a language gate's own config, a deploy target's own root config and the deploy task beside it, a project task a framework pack owns — the Astro pack's favicon rasterizer is the first — on the same merges-never-owns terms, behind their own consent line, and capped by a fixed allowlist of what may sit at a repo's root. The mise config, the file-based task library everything else runs through, the dprint, taplo, pre-commit, gitleaks, grype and house-linter configs, the ignore, attribute and graph-ignore files, the editor settings and the statusline config belong to no pack: they are written by /stackgen:tool-config, a skill you can also run yourself (/stackgen:tool-config preview all). A shipped node script copies its assets/ as they are and renders its templates/ from .config/stackgen.yaml — the repo's values, which the script alone writes — in four calls: all, pack, pack-remove and upgrade. Each list a pack once appended to — the ignore set, the exclusion set, the formatter's plugins — ships as a universal superset, every stack's entries whether or not your repo uses that stack; six files carry one # >>> tool-config marker pair, and every line outside it is yours and survives every render. Dev-only mise files pin latest; a file CI loads gets exact versions, save node and pnpm — there is no mise lockfile. Every change is shown as a numbered row before it writes, so a new repo's gate config needs no model judgement; it runs each tool only as mise x -- <tool>, the version your config pins, formats every file it wrote with the shipped dprint config and validates the hook config. Its all ends in a set-up repo: it lands every file, then runs MISE_ENV=dev mise run setup:all. Trusting the repo's mise config is yours to do first — typically its path in trusted_config_paths in your global mise config; the script checks it and never grants it. It also lands a repo-local mise skill, and a tool is never added with a bare mise use. A pack asks it for nothing: it ships config/ payload — its subtasks among it, which the rendered code:lint:all, code:format:all, code:check:all, setup:ai:all and setup:deps:<verb>:all tasks call — and a templates/ folder, its own conf.d/<slug>/ mise files and any file needing a value, which the script renders — each value the machine must answer declared in the pack's values: list with a detect command and a question, which /vwf:setup runs or asks as it lands the pack. Language manifests and CI workflow files stay outside that fence: they declare what the project is, and no pack decides either. The packs, bundles and kinds that ship are inventoried in stacks/inventory.md, generated from the tree itself; the newest kind is stylesheet, the one that answers vwf's seventh axis — how a web frontend's styles are authored, with tailwindcss, stylex and plain-css filling it and the design system's tokens staying the contract each of them realizes. The newest category is workspace, filled by notion — the place a team's docs, specs and tickets already live, wired for the agent to reach through one hosted MCP server the person authorises once, and nothing more: no part of the product runs against it. The newest design tool is the terminal itself — the claude-code pack, which vwf's architecture menu preselects on the design axis: the design system, the logo and a flow's screens are authored in session, through the taste-skill plugin a product pinning it declares, into a committed docs/design/<project>/ that vwf imports like any hosted canvas, and reviewed in a browser served from the repo on loopback — you click, comment, press Done, and the session applies the comments. stackgen is now the only stack plugin: its packs are the covered path, its generator the uncovered tail. A vwf dependency, because vwf's stack menu is the union of what the installed stack plugins offer — with none present it comes back empty, and the axes carry no free-text escape. You can defer an axis and keep defining the product, but /vwf:plan and /vwf:execute halt until it is answered. Having it installed commits you to nothing; it acts only once an axis is pinned. stackgen@virajp-plugins

Every plugin above is authored here. Nothing in this marketplace is re-listed from another repo any more: the last one that was — the Karpathy coding guidelines — is now a skill vendored inside vwf and installs with it.

claude plugin install vwf@virajp-plugins
claude plugin install --scope project stackgen@virajp-plugins

Statusline

The statusline has moved to its own project. It is not installed from here any more, and the CLI has no flag for it — --statusline is retired, like --platform, --upgrade and --force, and exits non-zero naming itself.

brew install virajp/tap/claude-status

It requires macOS on Apple silicon. The formula declares both, so Homebrew refuses an Intel Mac rather than installing a binary that cannot run, and there is no Linux build — see the caps-hook consequence below.

That is also where the context & rate-limit caps hook now comes from — the PostToolUse hook that pauses long /vwf:execute runs at budget thresholds (context over 65%, 5-hour over 90%, 7-day over 80%) by triggering a handoff. Its sensor is the bar: those figures reach a session only on the statusline payload, never on hook stdin, which is why the two travel together. vwf cannot detect its absence, so install it before a long autonomous run rather than after — without it the pause never fires. On any platform the formula refuses, that is not a step you can complete: the pause is simply unavailable, and a long autonomous run has to be sized accordingly.

If you installed the bar from here, --uninstall no longer tidies up after it. pnpx @virajp.dev/claude-plugins --uninstall still reads and reverts the old receipt like any other, which removes the script files it recorded — but nothing unwires the statusLine and subagentStatusLine keys or the context-caps hook entry, and no receipt is known to have recorded them. So the key is left naming a script that is gone; installing claude-status re-points it. The discontinued OpenCode TUI bar and Oh-My-Pi configuration are still restored from their receipts.

The installer CLI

@virajp.dev/claude-plugins is a small CLI with two jobs: install plugins (--all, --user, --project — a thin wrapper driving Claude's own commands, shown under Install above), and remove what this toolkit put on your machine. graphify is not its job — the plugins' own skills set it up.

It used to be published as @askviraj/ai-plugins. That package is sunset: it stays on npm, deprecated, and running it only prints a pointer to the new name and exits non-zero.

The installer manual is the full reference — usage for the flag surface, targets for what lands where, and internals for the maintainer's map.

Using it

npm is the only distribution channel, so it needs Node — on every platform, Windows included. There is no standalone binary and no Homebrew tap.

# Install the default set (vwf, plus stackgen as its dependency)
pnpx @virajp.dev/claude-plugins --all

# See exactly what a run would do, without writing anything
pnpx @virajp.dev/claude-plugins --all --dry-run

# Versions: this CLI against npm, and each plugin on main
pnpx @virajp.dev/claude-plugins --version

# List everything the toolkit installed, and remove what you do not deselect
pnpx @virajp.dev/claude-plugins --uninstall

Two things worth knowing before you run it; everything else is the usage page, which is the one place the flag surface is described.

• It writes nothing of its own. Every install goes through the tool that owns it — claude plugin install — so running the CLI and running those commands yourself leave the same machine. That is also why it keeps no receipt: what is on disk belongs to a tool that already tracks it.
• --uninstall shows you a list and removes what you do not deselect. Each piece goes through whatever owns it, and anything an older version installed — the discontinued OpenCode and Oh-My-Pi surfaces — is restored from its receipt rather than deleted, so what you had before comes back. graphify's hooks, graph, .graphifyignore and Claude wiring an earlier version left are no longer listed — they are yours or your repo's to remove. --dry-run is the scriptable way to just look.

Credits & acknowledgements

This project is a thin layer over a lot of excellent work. It would not exist — or would be far poorer — without these. Thank you to their authors and maintainers. 🙏

• Claude Code by Anthropic — the host these plugins and hooks plug into.
• MemPalace — the AI memory system that powers vwf's cross-session recall. Its two skills are vendored into vwf under MIT; see plugins/vwf/vendor/mempalace/.
• andrej-karpathy-skills by forrestchang — behavioral coding guidelines derived from Andrej Karpathy's observations. Its karpathy-guidelines skill is vendored into vwf; see plugins/vwf/vendor/andrej-karpathy-skills/.
• Context7 by Upstash — the MCP docs server vwf declares.
• mise by Jeff Dickey — resolves the toolchain the plugins and hooks depend on.
• pnpm — the default package manager the normalizing hook rewrites to, and the default runner behind the Context7 server.
• typescript-language-server, the Dart SDK, kotlin-lsp, and SourceKit-LSP — the engines behind the language servers stackgen's packs declare.
• rtk (Rust Token Killer) — the token-saving proxy vwf's Bash hook shells out to (installed via brew install --formulae rtk).
• graphify — the knowledge-graph tool vwf integrates with.
• tsup — bundles the installer CLI for publication. Argument parsing is Node's own util.parseArgs; the CLI carries no parser dependency.