CrewForge is a VS Code extension for building and running Kubemoot
crews. Create a crew, edit it as code, lint it, deploy it to a namespace, ask it questions,
and run its fitness scenarios, all from the editor.
It works through your kubeconfig, the same way kmctl does: any cluster your kubectl can
reach works, no crew needs a public address, and no extra credential is involved.
Install
Install CrewForge from the VS Code Marketplace. For other editors (Open VSX) and the
offline .vsix, see Install and connect.
You need VS Code 1.95 or later and a kubeconfig with access to a cluster that runs the
Kubemoot operator. Developing a crew also needs helm (deploy and lint), kubectl
(bundles of plain manifests), and a current kmctl
release (create). CrewForge reads the kubeconfig from the crewforge.kubeconfig
setting, else KUBECONFIG, else ~/.kube/config.
A 60-second tour
Click the Kubemoot mark (the round table) in the activity bar. Deployed Crews lists
the crews your kubeconfig can read, one row each with its namespace; Group by
Namespace in its title bar nests them instead. Crew Sources lists the crew charts
and bundles in your workspace. Each crew shows by its display name, such as "Help
Desk", with its Kubernetes name beside it.
Choose Ask on a deployed crew. A chat opens; type a question and press Enter. Each
agent reports as it works, then the crew's answer follows, with how long it took.
Expand a crew to see every part of it: Agents, Prompts, Skills, Models, RAG Sources,
MCP Servers, Tools, Policies, Notifications, Fitness, and Deployment. Objects the crew
shares with others, such as a cluster's ModelProvider, are marked shared. Click a
crew, deployed or in your workspace, for its dashboard: Overview, Source,
Live, and Diff tabs.
Right-click a folder in the Explorer and choose New Kubemoot Crew Here to scaffold
kmctl's starter crew with kmctl create --chart: a small, working crew that reads its
own namespace, with 1 to 5 specialists. Name it in plain words; CrewForge suggests the
Kubernetes name from it, and Rename... later changes either.
Edit it, or use Add ... on a group in Crew Sources to add an Agent, a
PromptModule, a Model, a RAG source, an MCP server, and more. The status bar says where
it stands against its deployment: not deployed, in sync, or changed. Lint checks
the chart against your cluster's schemas.
Choose Deploy to Namespace... to run it with Helm, then Ask, Run Fitness,
and Redeploy after each edit. A deployed crew carries its fitness scenarios: its
Fitness group runs all of them, a batch you pick, or one.
The status bar always shows the context CrewForge is connected to. If the cluster cannot
be reached, CrewForge says so in plain words and offers Select Kubernetes Context.
CrewForge writes only Kubemoot resources and Helm releases of them. It never deletes a
namespace or any other kind of object; the operator owns cleanup.
This section is for working on CrewForge itself; using it needs only the install above.
npm install
npm test # vitest
npm run test:coverage # the same, failing below the coverage thresholds CI enforces
npm run lint
npm run typecheck
npm run package # builds dist/ and crewforge-<version>.vsix
Before you push, run npm run lint, npm run typecheck, and npm run test:coverage.
SonarQube judges the code, and npm run lint runs the same TypeScript rules on src/
first: the eslint-plugin-sonarjs rules of the Sonar way profile, plus the
typescript-eslint and unicorn rules Sonar runs under its own keys (see
eslint.config.mjs). A finding there is very likely one SonarQube would report after
the push; the server stays the authority.
With this repository open in VS Code, F5 starts a second VS Code window (the Extension
Development Host) running your local build.
The tests replay discussion streams recorded from a live crew (test/fixtures/*.sse).
The VS Code glue runs against a small fake of the vscode module (test/vscodeFake.ts)
and a local stand-in for the Kubernetes API (test/fakeApiServer.ts); the chat page's
script runs in jsdom against the page the panel generates.
To record a new one:
Versions come from git tags; package.json keeps 0.0.0 and the workflows set the
version when they package. Every push to main tags a release candidate
vX.Y.Z-rc.N (the conventional commits since the last release decide X.Y.Z) and
packages its .vsix as a workflow artifact, publishing nothing. A maintainer promotes a
tested candidate with the Promote Release workflow, which tags vX.Y.Z and writes
the GitHub Release with the .vsix attached, and, only when asked, publishes the same
.vsix to the VS Code Marketplace and Open VSX (see CONTRIBUTING).
Community and contributing
Kubemoot is an independent open-source project under the Apache License 2.0. Contributing, support, governance, the code of conduct, security reporting, and releases are documented in one place: the Community section of kubemoot.org. Ask questions and share ideas in GitHub Discussions. Write to moot@kubemoot.org for anything else. Use security@kubemoot.org only to report a vulnerability, privately.
