Capture and publish
Getting work onto a board — screens as they are built, whole journeys, client-facing walkthroughs, and the boards that hold them.
/vitrinka: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×).
- 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.
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.
/vitrinka: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.