Niblet

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.

Mode is a prioritization tool, not a visual preset. A pricing page still needs usable controls; a gallery still needs accessible navigation; an application can have character without obscuring its tasks.

Design contract

Keep this short enough to guide implementation. Record:

• Surface and mode: route, component, or native screen; intended user; task and primary action.
• Scope: new work, refinement, or redesign; files/flows in scope and explicit exclusions.
• Product authority: brief, local components/tokens, content, and platform rules being followed.
• Identity: the hierarchy, density, typography, color roles, imagery, and interaction character appropriate to this product. Identify one or two concrete distinguishing decisions, not a list of fashionable adjectives.
• Reading order: rank what the user must understand first, second, and next; identify which supporting details can wait. Name the existing components and semantic tokens that express this hierarchy.
• Behavior and states: critical interaction, applicable state matrix, responsive/native adaptations, accessibility requirements, and real data constraints.
• Evidence and acceptance: any unresolved reference question; what a rendered result must visibly demonstrate; available device/browser and remaining limitations.

For refinement, preserve identity, behavior, copy, and out-of-scope areas unless the request expressly changes them. For redesign, replace the visual direction coherently while retaining product facts, required functionality, and native constraints. Neither scope authorizes unrelated feature work.

Slop checks

Make the product's task recognizable from the rendered screen, not just its logo. Apply these checks within the target product's established language:

• Use real objects, labels, and content density. Metrics need a real source; empty states explain what is missing and what to do next. Do not fill a dashboard with invented activity.
• Give the primary action a clear consequence and dominant position; subordinate secondary actions without hiding essential navigation.
• Group content by the user's decision or workflow. A grid is appropriate for comparing screens or products, not a default container for unrelated facts.
• Reuse semantic surface, text, border, action, and status tokens. Add a primitive only when existing components cannot express the task; record why in the contract. When a React product needs one it does not have, take the leanest library component that fits (components) and restyle it with the product's tokens rather than writing a generic one from memory.
• Let useful content carry visual interest. New gradients, glow, glass, nested cards, oversized headings, and motion need a product or interaction purpose. Preserve established brand assets and effects during refinement rather than enforcing a universal ban.
• Check the substitution test: if another product's name could replace this one without changing the content or structure, identify the missing product-specific decision and correct it.

For Niblet's own site, follow its current design contract and source components: Plus Jakarta Sans, ground/tile/sheet surfaces, ink/muted text, the blue accent, real screen tiles, and existing mascot assets. Do not import a reference site's font, palette, or button treatment. For other products, their own system takes precedence over these Niblet-specific choices.