Vlak

What it is for

Vlak gives us a shared starting point for an interface. The buttons, fields, and type already belong together, which leaves more attention for what the page needs to do.

Use the component documentation for the current APIs, installation, and licenses. If you knew the project as Raster, this is its new name. Polder covers the work around it: deciding what to build, explaining the choices, and checking the result.

Open Vlak documentation

Tools, in order

Here is where each tool helps. Use an equivalent you already work with if it fits the task and your project’s access requirements.

1. 01

   Before building

   Vlak · Notion

   Define the actual interface task and inspect the current Vlak documentation. Choose components that fit the task before inventing new controls.

   Carry forward A component plan and acceptance criteria.

2. 02

   During implementation

   A coding workspace with approved file access · Claude, ChatGPT, or Grok · Vlak

   Give the coding agent the approved component choices, current APIs, and realistic content. Keep the first implementation small enough to inspect.

   Carry forward A working interface in a local or preview environment.

3. 03

   Before review

   Browser and accessibility checks · Playwright

   Test keyboard use, focus, errors, long labels, and mobile behavior. Share a working preview, not only a screenshot.

   Carry forward A tested preview with known limitations.

Review the work with partners

We make and revise the work with Claude, ChatGPT, or Grok, then put selected versions on our Studio project pages for partners to review. Check the preview before sharing it. You can do the same with a private prototype or shared document; use a workspace that can access the files you need.

Name the version, say what changed, and ask the question you need answered. Keep feedback with that version and discuss conflicting requests before making the next changes. Confirm approval separately, and keep confidential work in a restricted space.

Delegate the routine work

Repeat a verified component pattern or write bounded tests for known acceptance criteria.

Interaction choices, accessibility decisions, and changes to the shared system need design and engineering review.

Sequence prompts, then delegateChoose a model for the design task

How to use it

Leave the next person enough to work with

Write down what was decided and why, with links to the notes or examples behind it. Keep the open questions alongside the decisions. Someone joining the project should be able to tell which is which without asking you.

Project: [name]
Input sources: [references and permission]
Approved decisions: [choice, rationale, owner]
Assumptions: [what remains untested]
Open questions: [question, owner, due date]
Acceptance checks: [observable pass/fail criteria]
Next step: [person or workflow]
Approval: [name, date, version]

Before you move on

• Can someone who was not in the room understand the result?
• Are claims supported by evidence, with uncertainty labeled?
• Has the responsible person approved the decisions—not just received the document?
• Have you removed private information and checked rights to any assets?

If the summary says something was agreed and you cannot find that agreement in the notes, ask the person who decides before carrying it into the next task.