Update to Cino Toolkit

{
  "name": "cino-product-design-review",
  "description": "Perform read-only, evidence-backed product-design and frontend UX audits of websites and web applications. Use when the user asks to inspect visual quality, hierarchy, typography, spacing, responsiveness, accessibility, interaction states, design consistency, or whether an interface looks generic or AI-made. Produce P0/P1/P2 findings tied to exact routes, states, widths, components, evidence, fixes, and verification. This skill audits and specifies repairs; it does not itself authorize product or code changes.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 304
    },
    {
      "relative_path": "assets/icon.svg",
      "size_in_bytes": 460
    },
    {
      "relative_path": "references/audit-criteria.md",
      "size_in_bytes": 4846
    },
    {
      "relative_path": "references/finding-format.md",
      "size_in_bytes": 3639
    },
    {
      "relative_path": "references/responsive-testing.md",
      "size_in_bytes": 3146
    },
    {
      "relative_path": "references/validation.md",
      "size_in_bytes": 2018
    }
  ],
  "skill_md_contents": "---\nname: cino-product-design-review\ndescription: Perform read-only, evidence-backed product-design and frontend UX audits of websites and web applications. Use when the user asks to inspect visual quality, hierarchy, typography, spacing, responsiveness, accessibility, interaction states, design consistency, or whether an interface looks generic or AI-made. Produce P0/P1/P2 findings tied to exact routes, states, widths, components, evidence, fixes, and verification. This skill audits and specifies repairs; it does not itself authorize product or code changes.\n---\n\n# Cino Product Design Review\n\nAudit the interface the user actually has, not an imagined redesign. Prioritize user harm and task completion over taste, preserve settled product rules, and make every serious finding independently verifiable.\n\n## Operating boundary\n\n- Treat every audit as read-only unless the user separately and explicitly asks for implementation.\n- When implementation is authorized, finish the audit first and hand its repair brief to the appropriate implementation workflow. Do not silently broaden this skill into a redesign or code-editing mode.\n- Review presentation and interaction quality. Do not claim that a visual audit validates calculations, permissions, data integrity, legal compliance, or business logic.\n- Respect existing product, brand, content, and business decisions unless the evidence shows that their presentation causes user harm.\n- State when access, routes, data, states, or viewport coverage are missing. Never fabricate unseen behavior.\n\n## Required references\n\nRead [finding-format.md](references/finding-format.md) for every audit.\n\nRead [audit-criteria.md](references/audit-criteria.md) when evaluating visual design, interaction design, accessibility, content presentation, or design-system consistency.\n\nRead [responsive-testing.md](references/responsive-testing.md) when the product has responsive layouts, constrained app containers, multiple device classes, or width-related claims.\n\nRead [validation.md](references/validation.md) only when testing or revising this skill itself. Do not load a known answer key before a blind validation pass.\n\n## Audit workflow\n\n### 1. Establish authority and coverage\n\nIdentify the product purpose, primary user, core task, required journey, brand constraints, authoritative design system, target routes, target states, and required widths. Inspect supplied requirements and source artifacts before applying personal preferences.\n\nAsk only for missing information that would materially change the audit. If the target is accessible and the user asked for a broad review, begin with reasonable coverage and record assumptions.\n\n### 2. Inspect real rendered states\n\nPrefer the live or locally running interface at exact routes, states, and widths. Use browser evidence, screenshots, DOM/accessibility information, and relevant source code when available. Source code can explain a symptom but does not replace rendered evidence for a visual claim.\n\nExercise the core task before polishing peripheral pages. Include consequential states such as loading, empty, error, disabled, validation, success, focus, hover, overflow, and realistic dense or long data when they exist.\n\nDo not infer that a state works merely because a component exists. Do not infer that a component is broken merely because its source looks unusual.\n\n### 3. Separate systemic and local problems\n\nClassify repeated faults in typography, spacing, color, controls, grids, or responsive behavior as system findings, then cite representative instances. Classify isolated faults against their exact page and component. Avoid duplicating one root cause as many page findings.\n\n### 4. Rank by harm\n\nAssign P0, P1, or P2 using [finding-format.md](references/finding-format.md). Task blockage, concealed material information, dangerous ambiguity, and serious accessibility barriers outrank style inconsistency. Do not issue a P0 for aesthetics alone.\n\n### 5. Write a repairable report\n\nFor each serious finding, give enough location, state, evidence, cause, repair direction, and verification detail that another person can reproduce and fix it without guessing. Label the basis as observed, directly inferred, or unverified.\n\n### 6. Close with a decision\n\nReturn one audit result:\n\n- **PASS** — required coverage is complete and no material P0 or P1 remains.\n- **PASS WITH CORRECTIONS** — no P0 remains, but one or more material P1 fixes are required.\n- **FAIL** — one or more P0 findings block the stated task or release standard.\n- **INCOMPLETE EVIDENCE** — required access or coverage is missing, so a reliable decision is not possible.\n\nThe result must follow the evidence. Do not soften it to be agreeable or inflate it to sound rigorous.\n\n## Output order\n\n1. Audit result and one-sentence reason\n2. Coverage: routes, states, widths, artifacts, and explicit gaps\n3. System findings\n4. Page-specific findings\n5. Prioritized repair brief\n6. Verification plan\n7. Assumptions and untested areas\n\nKeep P0 and P1 findings complete. Consolidate lower-value P2 polish so it does not bury consequential work.\n\n## Quality guardrails\n\n- Evidence over taste.\n- User task over visual novelty.\n- Exact context over vague claims.\n- Root causes over duplicate symptoms.\n- Brand adaptation over generic uniformity.\n- Accessible clarity over decorative motion.\n- Explicit uncertainty over invented certainty.\n\nDo not use a fixed blacklist of gradients, rounded cards, large headings, or other fashionable patterns as proof of “AI design.” Flag a pattern only when it is generic, inconsistent, inaccessible, poorly matched to the product, or harmful to the user journey.\n"
}