Niblet

Build an interface that belongs to this product, not a generic template. Niblet is an optional reference catalogue; this skill also works entirely from local product evidence without an MCP connection, account, script, or browser automation.

Start here

1. Identify the requested surface, action, and scope. Read the product brief, relevant current screens, components, tokens, content, and platform constraints. Inspect the repository directly; this skill has no setup script.
2. Select the surface mode below and write a compact design contract in the conversation or the existing surface brief. Ask only for a consequential decision that the available product evidence cannot answer. Mark other assumptions.
3. Read the command playbook for the requested command. The local MCP adapter registers each entry as niblet-<command>; a standalone filesystem installation invokes the same work instructions in ordinary language. For native work, also read native guidance.
4. Work within the contract. Use existing components and tokens before introducing new ones. If a concrete visual question remains unresolved, follow the evidence policy; reference retrieval is optional, never a prerequisite to useful work.
5. Cover the applicable states and run the bounded finish gate. Report the delivered scope, evidence actually inspected, and any specific verification limitation.

Routing: with no target or command, present a short context-aware menu and wait for a choice rather than making changes. An explicit command loads its playbook entry. Otherwise treat the request as ordinary design work. For a new surface or replacement visual world without product context, run init first; narrow refinements can proceed from the incumbent implementation. craft aliases ordinary new work; teach aliases init.

Authority order: the user's current requirements and product brief; established product behavior, content, components, and design system; native platform and accessibility constraints; this skill; external references. Aesthetic preferences never overrule product truth, accessibility, or functional requirements.

Four modes

Choose by the job of each surface, not the repository's category. Different surfaces in one product may use different modes. Persist the choice only in that surface's brief when persistence is requested; do not impose a project-wide mode.