Skills
Four plugins ship nineteen skills for Claude Code and Codex — core, PM, QA and an opt-in experimental one — so an agent arrives already knowing what a board is and what to do with one: a workflow, not an API it has to be taught.
Getting them
The skills come as plugins, and the plugins come from the public vitrinka-kit marketplace on GitHub. vitrinka setup installs the core, PM and QA plugins into Claude Code and Codex (--experimental adds the fourth; --modules picks); Gemini CLI, OpenCode, Cursor and VS Code get the MCP endpoint — and Gemini CLI and OpenCode the work listen host — but no skills. The manual route is the same commands the CLI runs for you. Every skill reads the same under both harnesses: the listening skills pick their wake-up rung from one shared ladder (see Listening) instead of naming one harness's tool; the workflows the experimental skills launch run in Claude Code only.
vitrinka setup # plugins, skills, MCP, tokenclaude plugin marketplace add henderson-tech/vitrinka-kit
claude plugin install vitrinka@kit vitrinka-pm@kit vitrinka-qa@kitCodex installs one bundle (codex plugin add vitrinka) that carries every module. Skills are never copied into a personal skills directory — the plugins are the one distribution, and vitrinka update refreshes every installed one with everything else; a machine set up before the split gets the PM and QA plugins once, on its next update.
Invoking one
Each skill is a slash command. Most are also triggered by describing the job in plain words — you rarely have to remember the name.
/listen
/resolve testing-11-7
/publishThe bare name resolves unless another command claims it; the qualified form — /vitrinka:publish, /vitrinka-pm:pickup, /vitrinka-qa:review, /vitrinka-experimental:test — always works. Codex spells them $publish, $pickup.
Auto-scoping, and why it matters
A skill given no board infers its scope from the repository and the current git branch — the project name comes from the main worktree, the same derivation vitrinka board push uses.
- Several sessions can work at once — each holds its own project+branch scope without stepping on the others.
- The global queue is never the default — an unscoped listing is a firehose containing other sessions' work; skills scope before they read.
Four plugins
The nineteen skills ship in four plugins, each the install unit of its modules. Core is always on and cannot be hidden; a plugin you do not install costs a session nothing, so a repository that only needs boards is never offered sprint automation. The PM plugin also ships the session hooks of the work loop for Claude Code, and the MCP registration lists the modules of the plugins you have (/mcp?modules=…), so the tool catalogue shrinks with them. Codex installs one bundle with every module and has no per-skill setting. Every skill's description is on the generated skills reference.
| Plugin | Modules | Skills | For |
|---|---|---|---|
vitrinka | core | publish, artifact, brainstorming, listen, resolve | The vitrinka experience — boards, capture, authoring, the annotation loop. |
vitrinka-pm | pm, me | pickup, handoff, tasks, release, me | The task engine and the work loop — picking work up and handing it back, intake, triage, rules, the release board, personal todos and reminders. |
vitrinka-qa | qa | usertest, review, sessions, pair, spot | The testing pipeline — exploratory testing and runner results, AI review, recorded sessions to fixes, live pairing, filing what you spot. |
vitrinka-experimental | experimental | build-idea, make-idea, test, cleanup | Flows still proving themselves, Claude Code only, opt-in — an idea to a draft PR, the ask-first device pass, the backlog cleanup. |
vitrinka setup modules list # every module, its plugin, where it is installed
vitrinka setup modules enable experimental # installs the plugin that ships it
vitrinka setup modules disable qa # uninstalls it; core is always on
vitrinka setup skills hide release # ONE optional skill, via Claude Code's skillOverridesThe pages
| Page | What it covers |
|---|---|
| Capture and publish | publish and usertest — getting work onto a board in the first place, and runner results onto the QA record. |
| Working the queue | listen, resolve, review, pair — answering what people drew. |
| Sessions to fixes | sessions — a recording into shipped changes and tests, and your own transcripts kept behind their tasks. |
| Authoring | artifact, brainstorming — documentation, diagrams, pages and decisions. |
| Running the project | tasks, release, pickup, spot, handoff — filing, triage, releases and the work loop without leaving the session. |
| Workflows | make-idea, test, cleanup — the experimental plugin's skills and the unattended Claude Code workflows they launch. |
| Todos, reminders and time | me — the personal module and the vitrinka me verbs under it. |