Authoring

/vitrinka:artifact

One skill, four authored surfaces — the single entry for everything you author on vitrinka rather than capture:

• A standalone document — a report, analysis, comparison or dashboard authored as a doc.json of elements (pages under pages/), validated and pushed with vitrinka board push, minted as a document card with its own /a/<id> view — exportable to PDF, HTML, Email and Word, and filterable by audience.
• A Confluence-grade page card — markdown pages, optionally bound to a repo file with a source and a revision, refreshed after repository edits and writable back to the file.
• An architecture diagram — composed from repository truth or from a system you describe. You send semantics — lanes, groups, typed nodes, ports, edges — and the server lays it out.
• A whole living-docs board — the repository scanned for truth sources (docker-compose, OpenAPI, SQL DDL, migrations), each diagram in its section, the pages authored, and the deep links wired both ways.

/vitrinka:brainstorming

Decision-led design. It maps the decisions that actually matter, puts them to you as batched multiple choice with a recommendation each, and ends in a committed decision log plus a feature brief — then builds from it. When the decisions go on a board, you answer them in the brainstorm studio, one chapter per decision with the takes side by side — brainstorming. The brief is also where /vitrinka-experimental:make-idea hands over to its build.

Pre-build recall (built in)

The pre-build memory pass needs no skill anymore — it rides the MCP server itself. Before designing or restyling a screen, the session pulls what vitrinka already knows: the project's memory, prior shots of that screen, and the indexed component vocabulary.

Project memory holds durable facts only — conventions, decisions, the traps a new session must respect — never session notes. Agents read it with get {kind: "project_memory"}: a bounded, ranked index of the rows the project's repo memory islands publish (pinned first, then by kind, recency and use), paged with next and marked complete / omitted; note reads a row's linked note. Those rows are written in the repo — memo add <kind>/<topic> "<sentence>." in a worktree, landed by its PR — never through vitrinka. Until an island absorbs it, the index also carries the project's legacy memory document (legacy.body, one markdown page up to 64 KiB, read and edited in Library → Memory), which save_project_memory replaces whole: read it, change only what changed, write it back. Once absorbed, that write answers 409 legacy_put and keeps your text as a proposal for the repo. When memory conflicts with what you asked for, the agent raises the conflict with you instead of resolving it silently.