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,
behind one final merge gate — 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
docs/plugins/vwf.md. Journey-shaped guides —
starting fresh, adopting vwf in a codebase that already works, and running a
live product — are in docs/how-to.
Around it the marketplace ships twelve more plugins — languages, clouds,
capabilities, tooling and design. That is the point of the split: vwf owns the
workflow and names no technology at all, so every concrete choice lives in a
plugin you install only if your product uses it. They install through Claude
Code's own plugin commands, straight from this repo; the
statusline is separate, and ships through one small CLI,
@askviraj/ai-plugins.
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.
- Five binaries must be on your
PATH — mise, graphify, uv, pnpm
and rtk. Nothing checks this at install time, and /vwf:doctor does not
cover all five: it blocks on a missing mise or graphify (and /vwf:setup
and /vwf:execute halt on either), reports a missing language server as an
ordinary finding, and says nothing about pnpm or rtk — rtk's hook is
guarded so its absence only degrades, and uv matters as graphify's runtime
rather than on its own. Run /vwf:doctor first regardless, but install all
five rather than relying on it to tell you.
- 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
docs/plugins/vwf.md.
Install
One command, which registers the marketplace and installs the workflow —
devtools, its one dependency, comes with it:
pnpx @askviraj/ai-plugins --all
That is a thin wrapper over Claude Code's own two commands, which work just as
well directly — the marketplace is this repo's main either way:
claude plugin marketplace add virajp/ai-plugins
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.
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. Everything beyond vwf is installed by name, because which
language, cloud and capability plugins you want is a question about your product
rather than about the toolkit:
pnpx @askviraj/ai-plugins --user typescript --user gcp
claude plugin install typescript@virajp-plugins gcp@virajp-plugins
Upgrading is claude plugin marketplace update followed by
claude plugin update <name> — the marketplace is served from this repo's
main, which every push validates in CI.
The statusline is the one piece that is not a plugin, because
no plugin mechanism can install a status bar. It comes from npm; see that
section.
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.
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/ai-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, LSP 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/ai-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 devtools;
nothing outside Claude Code will resolve that for you.
- The statusline is Claude-only. The OpenCode and Oh-My-Pi status surfaces
were discontinued; see Statusline.
The plugins
Thirteen plugins, each with its own guide. Install the workflow, then whichever
ones match the product you are building. The name in code at the end of each
entry is what you pass to claude plugin install.
The workflow
vwf — the flagship. Sixteen /vwf: commands
covering the whole arc: onboard a repo, 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 behind one merge gate, 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. It names no technology — no
language, no framework, no cloud — which is what lets the rest of this list
exist. vwf@virajp-plugins
Languages
typescript — the TypeScript language plugin,
covering TypeScript and JavaScript. A typescript router skill plus an effect
one for Effect-TS, and opinionated standards for package.json, pnpm, tsconfig
and the lint/format gate. It bundles the TypeScript language server, the
npm→pnpm/bun normalizing hook, and every TypeScript stack template vwf can offer
— service, service+webapp, site, worker, CLI, IaC and shared packages, plus the
npm-package and repo-level choices. typescript@virajp-plugins
flutter — Flutter and Dart done to one
standard: dart and swift router skills plus kotlin, pubspec,
analysis-options and internationalization, with Dart, Kotlin and SourceKit
(Swift) language servers bundled. It owns the dart-flutter stack template for
a frontend project. --project flutter from the app's own repo, or
flutter@virajp-plugins if you build them often enough for it to be a habit.
Clouds
gcp — Google Cloud, as the judgment an SDK
reference cannot give you: which service to pick, when it stops being the
answer, how each one bills, which have local emulators, and what least-privilege
IAM looks like. It supplies Firebase and Cloud SQL as backing choices and Cloud
Run and GKE as deploy targets. gcp@virajp-plugins
cloudflare — deliberately parked at Zero
Trust Access: a private plane in front of a project that must not be publicly
reachable, whichever cloud hosts it. Workers, Pages, R2, D1, KV and the rest are
not offered here and arrive under their own plan; the menu says so out loud
rather than coming back quietly short. cloudflare@virajp-plugins
Capabilities
A capability plugin holds the neutral contract — what your product must
guarantee, regardless of who provides it — and, where one exists, the provider
that belongs to no cloud. Managed flavours come from your cloud plugin. The
capability states the requirement; the provider states the mechanism.
datastore — the datastore contract: write
versioning, atomic multi-record writes, server-authoritative time, the
services-layer access rule, and a deterministic local stack. Ships Postgres.
datastore@virajp-plugins
identity — the identity contract: verification
per route, the claims carry status, never roles rule, revocation, and the
operator plane. Ships any OIDC issuer. identity@virajp-plugins
observability — the telemetry contract:
your product emits OTLP and never a vendor SDK, signals correlate,
cardinality is a design decision, retention is chosen. Ships the self-hosted
OpenTelemetry → Grafana OTel-LGTM sink; a managed backend is a destination,
not an import. observability@virajp-plugins
orchestration — the contract for work
that happens later: at-least-once delivery and the idempotency it forces,
bounded retry, the poison path, work-in-flight visibility, and when a queue
beats a bus beats a scheduler beats a workflow engine. Ships Temporal.
orchestration@virajp-plugins
object-storage — contract-only by
design: buckets, lifecycle as a bucket policy, signed access, prefix-scoped
credentials, the never-proxy-bytes rule, egress cost. Every object store is some
cloud's, so the flavour comes from gcp or cloudflare — and this plugin says
that explicitly rather than returning an empty menu, which would be
indistinguishable from a broken adapter. object-storage@virajp-plugins
Tooling, design and delivery
devtools — the developer-machine toolchain in
one plugin: mise (the three-file MISE_ENV split, tool placement, the
file-based task library) with a /devtools:scaffold skill, Doppler for
development secrets, Docker/OCI and the provider-neutral container-generic
deploy target, and the repo gates the stack templates name — dprint, ESLint,
gitleaks, grype, pre-commit. A vwf dependency, because /vwf:setup
orchestrates its scaffold skill. devtools@virajp-plugins
design-tools — the design adapter vwf
imports screens, design systems and design review conversations through. Three
skills resolve the design tool per project — claude-design, lovable or
stitch — so a product can design its website in one and its app in another.
Only some tools have a review conversation at all; the ones that do not say so
plainly rather than returning empty. Ships the Claude Design MCP server.
Deliberately not a vwf dependency: an adapter is chosen, not inherited.
design-tools@virajp-plugins
cicd — one /cicd:workflow skill that resolves
the repo's CI system from config and generates its delivery pipeline: every tool
installed through mise, both multi-repo and monorepo layouts, conforming to
vwf's tag-triggered, branch-validated, tested-before-release contract. GitHub
Actions is the one implementation today; adding a CI system is a single
reference file. Independent — vwf states the contract, this implements it.
cicd@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 typescript@virajp-plugins
claude plugin install --scope project flutter@virajp-plugins
Statusline
A standalone, powerline-style statusline (main two-line bar + subagent panel),
fully data-driven from JSON and themeable across three config layers (defaults →
~/.config/statusline.json → <repo-root>/.config/statusline.json). It
installs through the same CLI — not the plugin marketplace — copying the script
to ~/.claude/scripts/ and writing the chosen key(s) into
~/.claude/settings.json. Requires a Nerd Font.
Claude Code is the only surface. An OpenCode TUI bar and an Oh-My-Pi
configuration existed and were discontinued in the Claude-first release; if you
have either, pnpx @askviraj/ai-plugins --uninstall reads the old receipt and
removes it cleanly. Cursor exposes no status surface at all, and never did.

pnpx @askviraj/ai-plugins --statusline
Installing it also wires a context & rate-limit caps hook — it 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 that bar, which is why
the two travel together.
The script reports its own version, so --version tells you what is actually
installed rather than what the package you just ran happens to contain:
pnpx @askviraj/ai-plugins --version
The Claude bar also carries a monthly spend segment — the budget from
claude.ai → Settings → Usage, e.g. $75.93/$150 (51%). It sits in the default
layout but draws only for team and enterprise seats, whose limit is a monthly
spend cap rather than the 5-hour and 7-day windows; the figure is refreshed in
the background into a machine-wide cache, so a render never waits on a request.
See docs/plugins/statusline.md for setup and
the full configuration reference.
The installer CLI
@askviraj/ai-plugins is
a small CLI with four jobs: install plugins (--all, --user, --project
— a thin wrapper driving Claude's own commands, shown under Install
above), install the statusline, wire up graphify, and remove what
this toolkit put on your machine.
docs/cli/ is the full reference —
usage for the flag surface,
targets for what lands where,
statusline for why the bar ships here rather than as
a plugin, 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.
pnpx @askviraj/ai-plugins --statusline
pnpx @askviraj/ai-plugins --statusline --dry-run
pnpx @askviraj/ai-plugins --version
pnpx @askviraj/ai-plugins --uninstall
Two things worth knowing before you run it; everything else is
docs/cli/usage.md, which is the one place the flag
surface is described.
- A statusline you already have is never replaced without your say-so.
--statusline is the flag that counts as consent, and with no terminal to ask
in (a setup script, CI) the run fails rather than guessing in either
direction. A refusal is remembered, and --statusline clears it.
--uninstall shows you a list and removes what you do not deselect. Each
piece goes through whatever owns it — claude plugin uninstall for plugins,
and for the statusline a restore from its receipt, so the bar you had before
comes back rather than nothing. It also finds the discontinued OpenCode and
Oh-My-Pi surfaces from an older install, so nothing is orphaned. --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, hooks, and
statusline 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 and the Context7 server rely on.
- typescript-language-server,
the Dart SDK,
kotlin-lsp, and
SourceKit-LSP — the engines
behind the language-server plugins.
- 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.
- Nerd Fonts — the glyphs that make the
statusline render, and the Gruvbox
palette it ships by default.