# Capture and publish (https://docs.vitrinka.ai/dev/skills/capture)



## /vitrinka:publish [#publish]

One skill, four intents — the single entry for everything that captures and publishes UI work on vitrinka. You pick the intent inside:

* **Sticky screenshot sessions** — capture UI visually as it is built — iOS simulators, Android emulators, browsers, any local UI — and publish it as a set; web shots at 2× device scale unless the repo turns it off ([web captures at 2×](/dev/cli/sets#hidpi)).
* **Branching journey maps** — screens wired in the order somebody walks them, branches rendered as signposts.
* **Client-facing walkthroughs** — a board arranged to be read by someone outside the team.
* **Board and testing-suite organization** — boards created deliberately, with the right slug, type, project and subgroup from birth rather than renamed later.

<Callout type="warn">
  If you are not sure which capture intent you want, this is still the one skill to invoke — routing is its job. Authored documents, pages, diagrams and docs boards are the [artifact skill](/dev/skills/authoring).
</Callout>

## /vitrinka:usertest [#usertest]

Tests like a user and lets vitrinka keep the record, in two lanes that land in the same place:

* **Runner-backed** — `vitrinka qa run -- <your test command>` runs the suite untouched and publishes what it leaves behind — JUnit, Playwright JSON, allure, wdio or a manifest, plus screenshots — as the feature's QA record: the qa task, one journey per spec, the qa board and a bug draft per failing case.
* **Exploratory** — `vitrinka qa usertest start`, `case "<title>"`, captures, `verdict pass|fail|skip`, `finish`: the same record through the same door, with a multi-role matrix (what an admin creates, a user must see correctly) and edge cases as the craft, and small fixes made along the way.