maxi3777/claritykit
Turn vague design into reviewable artifacts — direction, requirements, architecture candidates, behavior models, data contracts, UI prototypes — with tool-derived paths, an optional explicitly-activated design flow, and a managed preview site.
Generate the acceptance evidence a behavior module with ClarityKit artifacts needs — a transition-coverage checklist from the behavior model and a UX comparison against the approved prototype. The governing workflow owns the verdict and report location. Invoke ONLY when the user names clarify-acceptance or the governing workflow's verification step explicitly calls for ClarityKit evidence; never self-activate from testing talk.
Present 2-3 architecture/stack candidates as layered diagrams, with verified version compatibility and a comparison table, so the user can choose; produces ADR content. Invoke ONLY when the user names clarify-architecture or clarity-flow enters the architecture step; never self-activate from a stack question in passing.
Pin down a module's behavior before implementation — scenario episodes, a YAML statechart for complex behavior, hand-crafted diagram views for user approval, acceptance criteria content. Invoke ONLY when the user names clarify-behavior or clarity-flow enters the behavior step; never self-activate from talk about features or flows.
Define what the system knows and what crosses its boundaries — a conceptual entity diagram, field-level ER + YAML contract sheet when persistence exists, endpoint map / cross-boundary sequences when interfaces exist; error taxonomy cross-checked against failure scenarios. Invoke ONLY when the user names clarify-data or clarity-flow enters the data step; never self-activate from a data-model remark.
Frame a rough direction into a one-page brief — who the user is, the job and today's workaround, observable success, at least three explicit non-goals — so the project doesn't solve the wrong problem. Invoke ONLY when the user names clarify-direction or clarity-flow enters the direction step; never self-activate from a vague idea.
Sharpen a vague idea into a decidable requirement brief with a scope mindmap (story map / priority quadrant when scope or priorities must be fought out). Invoke ONLY when the user names clarify-requirements or clarity-flow enters the requirements step; never self-activate from fuzzy requirements in conversation. Does not own where requirement documents are saved.
Build an interactive HTML prototype — a functional shell with real interaction logic, no backend, no visual design — so the user can feel the UX before implementation, and iterate until approved. Invoke ONLY when the user names clarify-ui or clarity-flow enters the ui step; never self-activate from a passing mockup request.
The ClarityKit design flow — activate ONLY when the user explicitly asks for it (mentions clarity-flow / the ClarityKit design flow, in any language; a governing host workflow calling for ClarityKit counts as the ask). Runs standalone or as a clarification sub-flow inside a host workflow's thinking stage (e.g. superpowers brainstorming, planning before an implementation plan). Walks direction → requirements → behavior/architecture (chosen order) → data → ui → commission, judging each step's necessity before entering it, keeping docs/clarity/flow.yaml as the resume point, closing with a signed delegation ledger. Every other ClarityKit skill is invoked the same way — the user names it, or this flow enters its step; none self-activates.
Start, stop, or check the ClarityKit preview server for the CURRENT project (serves the project's diagram/prototype site over http://localhost, survives reboots of the conversation). INVOKE ONLY WHEN THE USER EXPLICITLY ASKS to start/stop/restart the preview server (e.g. "start the preview server", "open the preview"). Never start a server on your own initiative.