The wiring
One command and your agent publishes.
Into whatever you already use, without changing how you work — a plugin, an MCP connection, or a pipe from a CI job.
01
Install the plugin
One command sets up the agent side. It shows you a status table first, then asks before it touches anything — the config files it edits are yours.
- Claude Code, Codex and the rest — one run registers Claude Code, and Codex, Cursor, OpenCode, VS Code and Gemini CLI when they are on the machine. A missing one is reported, not treated as a failure.
- Status first, then consent — the ✓/✗ table comes before any question, and only the config-touching steps are asked about.
- Signed in once, not per repo — Claude Code and Codex register your deployment's /mcp once, at user scope, so one sign-in serves every repository on the machine. The repo commits vitrinka.config.json — the workspace and project it belongs to — plus project entries for Cursor, OpenCode, VS Code and Gemini CLI, so a clone on a set-up machine is already bound.
- From a public marketplace — the plugin lives in the vitrinka-kit repository on GitHub. vitrinka setup adds it for you; by hand it is claude plugin marketplace add henderson-tech/vitrinka-kit, then claude plugin install vitrinka@kit vitrinka-pm@kit vitrinka-qa@kit — four plugins, one per module, and the experimental one is opt-in.
- The apps beside it — the desktop app is all of vitrinka in a macOS window, opened by vitrinka:// links; Snap is the menu-bar helper for the diary, voice notes and meetings; the browser extension records journeys, and setup installs and updates it for you.
02
Any MCP client
Your deployment serves MCP over HTTP at one address, and the board becomes a tool your agent can call directly — read and write, not just read. That is the difference between an agent that reports to a board and an agent that answers one.
- Nothing runs locally — Claude Code, Codex, Cursor, OpenCode, VS Code, Gemini CLI and hosted assistants such as Claude Desktop or ChatGPT all register the same /mcp address and sign in with their own OAuth flow. One sign-in covers every workspace of your organisation that you belong to.
- Grants you can revoke — a connection acts as you, read-only or read and write, and never above your own role. Settings → Connected apps lists each one with when it was last used, and one click revokes it.
- Tools for every surface — boards and what goes on them, questions, the QA work queue and recorded sessions, tasks, sprints, milestones, intake and automation rules, project memory and templates — and a docs tool that teaches the agent the vocabulary. Each one a call, not a scrape.
- It can wait — wait_for_work blocks until a new annotation arrives, so a session parks on a board instead of polling it.
- It can ask — boards carry questions with options, so the agent can put a decision to a human and read the answer back.
03
The workflow comes with it
A set of skills ships alongside the tools. The agent gets the procedure — how to capture a journey, service a board's queue, cut a release — rather than an API surface it has to be taught from scratch. For Claude Code, the plugin also ships workflows that run a whole job unattended.
- Core — the vitrinka experience — artifact, publish, brainstorming, listen and resolve: author, capture, decide, and work through a board's queue.
- PM — the task engine and the work loop — pickup, handoff, tasks, release and me: pick a task up, hand it back, file and triage intake, cut the release, keep your own todos and reminders; the plugin also ships the session hooks.
- QA — the testing pipeline — usertest, review, sessions, pair and spot: explore an app on your own, run the AI review loop, work recorded sessions, pair live with a tester, file what you spot.
- Me — personal todos, reminders and milestones that ripen on their own trigger.
- Claude Code workflows (experimental, opt-in) — make-idea takes an idea to a draft pull request: it maps the terrain, runs the brainstorm with you, then builds and checks it once — you decide at the brainstorm and with the feature in front of you, when test runs the device pass you chose. cleanup checks a project's open tasks against the code, the pull requests and the QA record, applies what is proven and proposes the rest.
04
When it drifts
Editors move their config, registries change shape, machines get reimaged. The health check is a first-class command rather than a support article.
- vitrinka doctor — prints what is registered and what is not, wherever it lives.
- doctor --fix — repairs the parts it can decide safely and leaves the rest to you.
- vitrinka setup uninstall — removes everything it put there, for when the answer is no.
05
Just curl
Anything else — CI, a script, a machine with no plugin at all — publishes a whole set with a tar pipe. There is no SDK to adopt.
- A tar pipe is enough — one HTTP call from any CI job that can produce files.
- Tokens are mintable and revocable — and both events are recorded in the audit trail.