← SkillquiverCONTENT HISTORY

Update to Skillquiver

Snapshot Sep 30, 2026 · 23:14 UTC · version 2.1.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Builds accessible interfaces and verifies renders. Use when creating or redesigning a page, dashboard, or static HTML file.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 209
    },
    {
      "relative_path": "references/direction-plan.md",
      "size_in_bytes": 6380
    },
    {
      "relative_path": "references/render-verification.md",
      "size_in_bytes": 3375
    },
    {
      "relative_path": "references/ui-copy.md",
      "size_in_bytes": 2212
    },
    {
      "relative_path": "scripts/capture-static-page.cjs",
      "size_in_bytes": 4975
    }
  ],
  "name": "design-ui",
  "skill_md_contents": "---\nname: design-ui\ndescription: Builds accessible interfaces and verifies renders. Use when creating or redesigning a page, dashboard, or static HTML file.\n---\n\n# Design UI\n\nTranslate the brief into explicit visual decisions, implement one coherent\nsystem, and map every delivery claim to evidence.\n\n## Route before any tool call\n\nIf the prompt names one existing framework-free HTML file and explicit\npreservation constraints, the bounded path below is mandatory. Accessibility,\nvisual-quality, and responsive wording do not select the full workflow. Read\nonly through the bounded path, then act; do not load this skill's references or\ncontinue into the full workflow. Use the full workflow for every other task.\n\n## Bounded path for a small static page\n\nUse this path when the request names one existing framework-free HTML file and\nexplicit preservation constraints:\n\nThis is a closed route. Do not enumerate the workspace, inspect version control\nor package files, search for browsers, or reread this skill or the target for\nconfirmation. Visual, accessibility, or usability wording does not authorize\nnew product behavior; add JavaScript only when the prompt explicitly requests\nan interaction. Do not probe the DOM, image pixels, or browser environment with\nextra commands.\n\nFor this route, `focus` means the visible keyboard focus treatment and labeling\nof the existing control. It never means implementing search, filtering, live\nstatus, empty states, or other interaction. When the prompt requests no\ninteraction, the finished file must add no `script` element or event handler.\n\n1. Read only that file and directly referenced local assets. Do not inspect\n   package files, invoke other skills, or load this skill's references.\n2. Before editing, send one sentence with this complete shape: `Direction:\n   audience ...; layout ...; palette ...; typography ...; focus ...;\n   responsive ...`. Do not edit until all six fields have concrete values.\n   Preserve content and behavior; add no JavaScript or product behavior unless\n   requested.\n3. Apply one focused HTML/CSS patch. Preserve every named ID and constraint.\n   Never delete the target file or replace it through a delete/add sequence.\n   Make the 360px layout safe in the first patch: use border-box sizing, give\n   grid or flex children `min-width: 0`, keep controls within `max-width: 100%`,\n   and use a single-column flow below 480px. Put multi-column layout behind a\n   `min-width` media query. At widths below 480px, use normal block flow with\n   at least a 16px viewport gutter and borders instead of outer shadows. Do not\n   use `100vw`, fixed or absolute positioning, transforms, decorative pseudo\n   elements, grids, or flex containers there. Add only the visible label and,\n   if needed, one short helper line; do not add badges, chips, eyebrow copy, or\n   other content. Start from these shell invariants and keep their effect:\n   `*,*::before,*::after{box-sizing:border-box}`, `body{margin:0;padding:16px}`,\n   `main{width:100%;max-width:72rem;margin-inline:auto}`, and\n   `input{display:block;width:100%;min-width:0;max-width:100%}`.\n4. Run `node <this-skill-dir>/scripts/capture-static-page.cjs <page.html>\n   <output-dir> <width...>` with every required width. It uses an already\n   installed Chrome, Chromium, or Edge and installs nothing. Inspect each saved\n   image at most once with the host image viewer, never with another command.\n   For a capture below 480px, inspect only the returned `inspectionPath`; it\n   centers the exact captured pixels on a wider canvas to avoid host-viewer\n   cropping. Report the original `outputPath`, width, and height as evidence.\n5. Report the returned image paths and dimensions. If it fails, stop and state\n   that rendered verification is unavailable in the next response. Run no more\n   commands after a failed capture. If the first captures expose a concrete\n   defect, make one repair and repeat step 4 once. Run the capture command at\n   most twice total. Do not repair, inspect, or recapture after the second run;\n   issue the final response immediately even if a defect remains. A remaining\n   defect at any required width means rendered verification failed; never call\n   that width usable or the task complete.\n\nFor applications, multiple pages, uncertain behavior, or design-system work,\nuse the full workflow below. Accessibility and honest delivery apply to both.\n\n## Full workflow\n\n### 1. Record intent\n\nInspect the existing stack, routes, content, assets, dependencies, design\nsystem, representative states, and user references. Record page kind\n(greenfield, preserve, or overhaul), audience, delivery limits, required and\nrejected directions, preserved behavior/content, and the brief's free axes:\npalette, type, layout, motion, tone, and imagery. Keep the intent artifact\noutside the repository unless the user requests a versioned design spec.\n\nAsk one question only when two materially different directions remain equally\nplausible. Otherwise state the design read and proceed. A visual redesign does\nnot authorize framework, route, logic, or content changes.\n\n### 2. Commit to a direction\n\nRead [direction-plan.md](references/direction-plan.md) completely. Before code,\nrecord and critique concrete tokens, contrast, type roles, layout family,\nbreakpoints, spacing ownership, desktop/mobile wireframes, ordered blocks,\ninteractions, and one bounded signature element. Mark missing content rather\nthan fabricating it. The brief wins every conflict.\n\n### 3. Implement one system\n\nUse the existing stack and design system unless the request authorizes a\nreplacement or they cannot meet the brief. Verify version-sensitive APIs in\nversion-matched primary documentation.\n\n- Trace every color, type, spacing, radius, elevation, and motion value to the\n  direction plan; record an extension before using it.\n- Preserve real content, assets, functionality, legal text, and responsive\n  behavior.\n- Use motion only for hierarchy, continuity, feedback, or brand character and\n  provide reduced-motion behavior.\n- Give each style decision one owner; avoid layered overrides and decorative\n  competition with the signature.\n\nWhen creating or changing interface text, read\n[ui-copy.md](references/ui-copy.md). Include labels and empty, error, loading,\ndisabled, and success states; never invent evidence.\n\n### 4. Verify the render and behavior\n\nBefore the first render, read\n[render-verification.md](references/render-verification.md) and freeze its\nchecklist. Use the available browser automation at mobile, desktop, meaningful\nintermediate widths, and relevant non-happy states. Check content presence,\nlayout, overflow, contrast, focus, keyboard and assistive semantics, motion,\nand actual interactions.\n\nKeep screenshots, behavioral evidence, code review, and subjective judgment\nseparate. A screenshot does not prove an interaction. If the environment lacks\na browser or required access, report the exact limitation instead of claiming\nrendered verification.\n\n### 5. Review touched UI structure\n\nRead every touched UI file completely and review only component boundaries,\nprop flow, and style-token ownership:\n\n- Split or combine components along concepts that change together.\n- Remove pass-through layers that add no contract, validation, or translation.\n- Route repeated raw values through the direction plan's owning token.\n\nReport actionable findings with exact file and line, reader cost, and named\nfix; name clean files so reviewed scope is explicit. Route generic pre-merge\nreview to the repository's review workflow.\n\n## Deliver honestly\n\nReport the design read, preserved constraints, material changes, tested\nviewports and interactions, evidence paths, structural review, and every\nunresolved visual or behavioral gap. Label subjective judgments and give\nlimitations the same prominence as completed work.\n"
}

SHA-256 of public snapshot: 4f959f021ccdae6fe3b4dca83adfcd9b6cda99efcb62a44193ad843dad5a7ccc