dev-design

Output style (plain words, no dashes, no hyphens)

Write everything this skill produces, files and messages alike, in plain simple language. Keep technical terms that carry real meaning; explain each in plain words. Never use a dash or a hyphen as punctuation: no em dash, no en dash, and no hyphenated compounds. Write read only, not read-only. Say it in simple words, or reword the sentence. Code, file paths, command flags, and values other skills match on keep their hyphens. A structural separator inside a template format other skills parse, such as the em dash in ## Phase 1 — <NAME>, is part of that format: reproduce it exactly, since changing it breaks the mirroring. Use short sentences, commas, or parentheses. Clear beats clever.

What this skill does

Answers how the product looks and behaves, given a project-overview.md that says what it is and an architecture.md that says what it is built with.

It finds every surface the flows require, settles the design system once, builds an interactive prototype for each surface, and runs the review that puts a rendered design in front of a person to approve. Nothing else in the workflow may originate a design decision, and nothing else may write the three files this skill owns.

It also appends every durable design choice the person makes to .konteksto/human-decisions.md, preserving the selected option beside the recommendation they saw.

Skip this skill entirely on a backend with no app/. A service with no screens has no surfaces, no prototypes, and no design system, and /dev-architect says so in its report rather than sending you here.

Where this sits

Before this: /dev-architect, which settled the stack. The client framework matters here, because a prototype should not fight the thing that will implement it.