CrewForge for VS Code

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. VS Code started from the Dock or Start menu does not see a KUBECONFIG exported in a terminal, so point CrewForge at the file with CrewForge: Select Kubeconfig File. If the path is a folder or missing, CrewForge says so and names the command.

A 60-second tour

1. 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.
2. 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.
3. 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 ModelServer, are marked shared. A crew that ships no Models selects from the cluster's model catalog, so its Models group lists the ModelServers that publish the catalog, each with the models it offers. Click a crew, deployed or in your workspace, for its dashboard: Overview, Source, Live, and Diff tabs.
4. 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. It ships no models and names no model server: its scheduling policy states what it needs, a model that can call tools, and the cluster's model catalog supplies the models. Name it in plain words; CrewForge suggests the Kubernetes name from it, and Rename... later changes either.
5. Edit it, or use Add ... on a group in Crew Sources to add an Agent, a PromptModule, a RAG source, an MCP server, and more. Edit Scheduling Needs... on the Models group states what the crew needs for a phase, such as triage or mulling, in its CrewSchedulingPolicy: the abilities a model must have (tool-calling, reasoning, vision), the size it prefers (small, medium, or large, by parameter count), and how much it favors the model the cluster measured faster (preferFaster). It names no model; the cluster's model catalog supplies them. Add Crew-Local Model (Advanced)... is there for a crew that must bring its own: it writes the Model's parameters and abilities, and warns first that a crew with Models of its own stops using the catalog. The status bar says where the crew stands against its deployment: not deployed, in sync, or changed. Lint checks the chart against your cluster's schemas.
6. Choose Deploy to Namespace... to run it with Helm, then Ask, Run Fitness, and 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.

Documentation

The full documentation is on kubemoot.org:

• CrewForge overview
• Install and connect
• Develop a crew in VS Code, the whole loop step by step
• Views and dashboards, every view, tab, and action, and what each changes
• Fitness from the editor
• Settings and permissions
• Troubleshooting

Develop

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:

P=/api/v1/namespaces/<ns>/services/<crew>-discussion:80/proxy/api/v1/discussions/<crew>
ID=$(kubectl create --raw $P -f <(printf '{"message":"<question>","conversationId":""}') | jq -r .conversationId)
kubectl get --raw $P/$ID/stream > test/fixtures/<name>.sse

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 publishes a tested candidate with the Publish Release workflow, which tags vX.Y.Z and writes the GitHub Release with the .vsix, its Sigstore signature, and its build provenance 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 [email protected] for anything else. Use [email protected] only to report a vulnerability, privately.

License

Apache License 2.0. See LICENSE.