Update to Cino Toolkit

{
  "name": "tmc-ui-master",
  "description": "Audit, plan, implement, repair, refactor, and verify all frontend UI and UX work for The Moving Chain. Use for TMC visual quality, page redesigns, interaction simplification, responsive layouts, accessibility, design-system consistency, scoped frontend code hygiene, asynchronous and session recovery, frontend privacy and runtime checks, motion, loading or error states, rendered-browser testing, visual regressions, UI handoffs, and determining what UI work remains. Supports read-only audits and explicitly authorised implementation while protecting pricing, Quote, Instruction, Case, authentication, tenancy, and other business logic.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 329
    },
    {
      "relative_path": "assets/icon.svg",
      "size_in_bytes": 2952
    },
    {
      "relative_path": "references/audit-and-implementation.md",
      "size_in_bytes": 7681
    },
    {
      "relative_path": "references/authority-and-invariants.md",
      "size_in_bytes": 6022
    },
    {
      "relative_path": "references/code-hygiene.md",
      "size_in_bytes": 7067
    },
    {
      "relative_path": "references/verification-matrix.md",
      "size_in_bytes": 8858
    }
  ],
  "skill_md_contents": "---\nname: tmc-ui-master\ndescription: Audit, plan, implement, repair, refactor, and verify all frontend UI and UX work for The Moving Chain. Use for TMC visual quality, page redesigns, interaction simplification, responsive layouts, accessibility, design-system consistency, scoped frontend code hygiene, asynchronous and session recovery, frontend privacy and runtime checks, motion, loading or error states, rendered-browser testing, visual regressions, UI handoffs, and determining what UI work remains. Supports read-only audits and explicitly authorised implementation while protecting pricing, Quote, Instruction, Case, authentication, tenancy, and other business logic.\n---\n\n# TMC UI master\n\nImprove the interface that exists, using current TMC authority and rendered evidence. Handle the whole UI loop without turning visual work into an unauthorised product or business-logic rewrite.\n\n## Choose the operating mode\n\nInfer the narrowest mode from the request.\n\n- **Status:** Determine what is complete, partial, missing, stale, duplicated, or conflicting across current UI branches, PRs, Drive authority, and the rendered product. Do not edit.\n- **Audit:** Inspect real routes, states, data, and widths. Return evidence-backed P0, P1, and P2 findings. Do not edit.\n- **Plan:** Convert accepted findings into bounded implementation lanes with ownership, dependencies, acceptance criteria, and verification. Do not edit.\n- **Implement:** Make the authorised UI changes on the verified isolated branch, then test them. Do not merge or deploy unless the user separately authorises that action.\n- **Verify:** Review completed UI work against its authority, rendered result, responsive matrix, accessibility checks, tests, and protected invariants. Fix only when the request also authorises fixes.\n\nIf the request mixes modes, preserve their order: establish status, audit, plan, implement, verify.\n\n## Read current authority first\n\nRead [authority-and-invariants.md](references/authority-and-invariants.md) for every task. Resolve the current Drive authority, live repository state, target branch or PR, and relevant API contracts before judging or changing the UI.\n\nDo not rely on a remembered SHA, old screenshot, superseded handoff, or copied summary when the live source can be checked. Stop before edits if the required base branch or commit does not match the authorised start condition.\n\nUse connected Drive, repository, and browser tools to discover available authority and runtime access before asking the user to supply links, documents, branches, or screenshots. Ask only for evidence that the available tools cannot locate or access and that would materially change the result.\n\n## Work from rendered evidence\n\nUse the real application at exact routes, roles, states, viewport sizes, and usable container widths. Exercise the user journey. Source code explains a symptom but does not prove the final visual result.\n\nRead [audit-and-implementation.md](references/audit-and-implementation.md) for status, audit, plan, or implementation work. Read [verification-matrix.md](references/verification-matrix.md) whenever the task touches responsive behavior, dense data, accessibility, motion, asynchronous behavior, session recovery, privacy-sensitive presentation, cross-browser behavior, representative-user acceptance, or completion claims.\n\nFor implementation, repair, refactor, or completion verification, also read [code-hygiene.md](references/code-hygiene.md). Apply its hygiene gate to the changed code and the shared code it directly depends on. Do not use UI work as permission for an unrelated repository-wide rewrite.\n\nWhen available and relevant:\n\n- use cino-product-design-review for the formal evidence-backed audit;\n- use cino-critical-review for consequential product decisions, authority conflicts, or risky redesigns;\n- use vercel:nextjs while implementing Next.js work;\n- use vercel:geist for typography-system changes;\n- use vercel:react-best-practices after editing multiple TSX components;\n- use vercel:agent-browser-verify after starting a development server;\n- use vercel:verification before claiming the full affected journey is complete.\n\nDo not install a new UI library, replace the design system, or add a dependency merely because it makes one screen easier to build.\n\nScale verification to the risk and the changed behavior. Do not force every minor visual repair through every browser, failure sequence, or broker acceptance check. Do not omit those checks when the lane changes a consequential workflow, asynchronous state, authentication recovery, client-data handling, a shared system, or claimed browser or accessibility support.\n\n## Preserve the boundary between UI and product truth\n\nUI work may change presentation, layout, hierarchy, copy clarity, interaction feedback, responsiveness, accessibility, and motion within the authorised scope.\n\nIt must not silently change:\n\n- pricing, eligibility, referral-fee calculations, totals, or data freshness;\n- Quote persistence, recovery, versioning, stale-state behavior, or Provider selection semantics;\n- Instruction idempotency, submission, frozen money, or exactly-one Case creation;\n- authentication, invitation, permissions, tenancy, or admin authority;\n- session semantics, client-data storage, analytics, telemetry, or privacy policy;\n- backend truth, API contracts, lifecycle states, compliance claims, or production data.\n\nIf a visual improvement appears to require one of these changes, pause that decision and identify the required product or technical authority.\n\n## Implement in bounded lanes\n\nPrefer the smallest shared-system change that fixes a repeated root cause, followed by page-specific repairs. Keep unrelated working behavior untouched.\n\nFor each lane:\n\n1. Name the affected routes, components, states, widths, and user task.\n2. Capture the before state.\n3. Record the governing authority and protected behavior.\n4. Define observable acceptance criteria, the person responsible for verification, any required acceptance owner, and the applicable quality gates.\n5. Implement only the authorised surface.\n6. Test realistic data and interaction states.\n7. Capture and inspect the after state.\n8. Run the scoped code-hygiene gate and remove proven superseded code.\n9. Run focused tests, then the relevant resilience, runtime, privacy, browser, accessibility, and wider gates.\n10. Return the exact diff scope, hygiene evidence, deletions, gates actually completed, regressions checked, untested claims, remaining issues, and next safe lane.\n\nDo not declare a page complete because it looks good in one screenshot.\n\n## Make UI state reproducible\n\nPrefer existing fixtures, seeded accounts, Storybook stories, test routes, or safe local mocks that reproduce consequential states. If the frontend lacks a reliable way to reach required UI states, propose a non-production UI state harness. Build it only when implementation is authorised and keep it out of production behavior.\n\nThe harness should represent product-valid states rather than invented mock behavior. It must not become a second implementation of pricing or other business logic.\n\n## Decide completion honestly\n\nUse one result:\n\n- **PASS:** Required coverage is complete and no material P0 or P1 remains.\n- **PASS WITH CORRECTIONS:** No P0 remains, but material P1 work remains.\n- **FAIL:** A supported P0 blocks the required task or release standard.\n- **INCOMPLETE EVIDENCE:** A required route, role, state, width, authority, or environment could not be inspected.\n\nSeparate observed defects from direct inferences and unverified risks. Never turn unavailable evidence into a confident pass.\n\n## Handoff\n\nReturn:\n\n- mode and result;\n- authority, repository, branch, and commit inspected;\n- routes, states, roles, widths, and browsers covered;\n- the browser, device, accessibility, privacy, and user-acceptance targets used, including unresolved targets;\n- changes made or findings produced;\n- tests, rendered checks, failure sequences, runtime inspection, and representative-user checks completed;\n- protected invariants rechecked;\n- unresolved conflicts, blocked evidence, and remaining P0, P1, or grouped P2 work;\n- the next smallest safe UI lane.\n\nFor implementation, include the branch and commit created. Do not merge, deploy, mark a protected PR ready, or mutate production unless the user explicitly asked for that action.\n"
}