Skip to content
cccskills
FreePublished on GitHub

superior-ui

Build, redesign, or visually refine product interfaces using project evidence, real content, functional states, and deliberate composition. Use for implementation work on websites, apps, dashboards, landing pages, or component systems. Do not use for read-only audits or logic-only changes.

The English summary is being prepared. Showing the original description.

KodekaTeam/superior-skills23 stars(GitHub 23 + cccskills 0)

Run score Not tested

See how to install

Files included (10)

  • SKILL.md7.5 KB
  • references/design-recreation.md3.2 KB
  • references/expressive-composition-and-component-craft.md6.1 KB
  • references/motion-and-rendering-performance.md5.5 KB
  • references/page-closure-and-footer.md6.3 KB
  • references/product-integrity.md4.1 KB
  • references/reference-source-hygiene.md4.0 KB
  • references/semantic-html-and-search-discovery.md4.9 KB
  • references/style-and-palette-direction.md13.7 KB
  • references/visual-system.md6.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Superior UI

Produce an interface that belongs to this product. Derive choices from the user's request, existing design evidence, content, and task flow; do not impose a house style or mechanically ban familiar techniques.

Establish the brief

Before editing, identify:

  • the primary user and job this surface supports;
  • the content and actions that deserve first attention;
  • existing design owners: tokens, typography, components, layouts, brand assets, and documented decisions;
  • implementation constraints, affected routes, and states;
  • what must remain unchanged.

Inspect the rendered surface when practical. If direction is missing, make the smallest reversible assumption that fits the product and disclose any choice that materially shapes the result.

Choose a visual thesis

State the direction in one useful sentence, such as “dense operational console with quiet chrome and high-signal status color.” The sentence must constrain actual decisions about hierarchy, density, type, color, shape, or motion. Avoid mood labels that could describe any product.

When the user asks to recreate, match, or closely follow a supplied design, that reference is the visual direction for the requested scope. Do not shortlist alternatives or redesign its visible composition unless the user asks. Read references/design-recreation.md for fidelity, adaptations, and visual verification.

When no governing visual direction exists, shortlist two or three materially different candidates that fit the product and explain each candidate's task fit, defining traits, and principal risk. Select one primary direction before implementation unless the user explicitly requests parallel concepts. A supporting influence may shape a limited detail, but do not blend several named styles into an incoherent trend collage. When a reference's role is ambiguous, preserve its observable characteristics and disclose material assumptions rather than silently redesigning it.

Read references/visual-system.md when the task creates a new visual direction, changes several components, needs substantial visual polish, or recreates a design from an image or external reference. Also read references/style-and-palette-direction.md when selecting among named UI styles, establishing a new palette, or assigning colors to body, component, and typography roles. For focused edits, preserve the local system without loading either reference.

Read references/reference-source-hygiene.md whenever a screenshot, template, repository, demo, or third-party design materially informs the implementation. Use the reference for source-identity cleanup and for deciding when copied or adapted material requires attribution or license preservation.

Read references/page-closure-and-footer.md when building or substantially redesigning a landing page, homepage, multi-section marketing page, or footer. Treat the ending as a deliberate part of the page composition without assuming that every site needs a large multi-column footer.

Read references/semantic-html-and-search-discovery.md when building or substantially changing a public page whose content must be discoverable, linked, or indexed, including landing pages, homepages, articles, documentation, catalogs, and public detail routes. Keep private dashboards and authenticated tools outside search-oriented requirements unless the product contract says otherwise.

Read references/expressive-composition-and-component-craft.md when the direction calls for asymmetric composition, layered depth, editorial tension, or bespoke tactile component details. Use those patterns as candidates justified by content and task—not as mandatory decoration or randomized style selection.

Read references/motion-and-rendering-performance.md when motion is a substantial part of the experience, including animated navigation, overlays, scroll entry, coordinated state transitions, or expressive microinteractions. Keep motion purposeful, accessible, and proportionate to runtime cost.

Build around the task

  • Start with semantic structure and information order; decoration follows.
  • Give each region a job. Remove sections that exist only to complete a familiar template when designing freely; for an explicit recreation, preserve the requested reference structure and handle unavailable content honestly.
  • Reuse existing primitives when they express the needed hierarchy. Add a variant only when the existing contract cannot.
  • Use spacing, type, contrast, alignment, and grouping to create hierarchy before adding containers or effects.
  • Let repeated components reflect repeated content. Do not force unlike information into identical cards.
  • Keep responsive and accessibility behavior intact. Load the dedicated skills when either concern is a substantial part of the request.

Load superior-ux when the primary work is a journey, information architecture, task flow, cross-screen continuity, feedback, or recovery contract. Keep ordinary page hierarchy and visual interaction design here.

Protect product integrity

Read references/product-integrity.md when the surface includes dashboards, marketing claims, forms, navigation, asynchronous data, or multiple UI states.

At minimum:

  • never fabricate metrics, customers, testimonials, activity, compliance, or destinations;
  • make controls work, remove them, or label them honestly as unavailable;
  • distinguish loading, first-use, filtered-empty, permission-denied, validation, error, and success states when relevant;
  • write specific labels and actions using the product's vocabulary;
  • preserve user data and existing behavior outside the requested change.

Critique before delivery

Review the result from three distances:

  1. Page: Is the primary task obvious, does the composition have intentional rhythm, and does the page end with deliberate visual and informational closure?
  2. Component: Does each component earn its boundary, emphasis, and interaction?
  3. Detail: Are labels, icons, states, focus, alignment, and content honest and coherent?

Challenge generic template habits when creating a new direction. In an explicit recreation, the supplied design is evidence for the requested visual choices; do not discard them merely because they resemble a template.

Verify

Exercise changed interactions and relevant states. Check representative narrow and wide viewports, content extremes, keyboard flow, and the project's normal lint/type/build checks in proportion to the change. For recreation, compare rendered output against the reference at a comparable viewport when practical, iterate on material differences, and report unverified fidelity or necessary deviations. Report concrete results and any unverified risk.

Load superior-performance when loading, rendering, responsiveness, bundle cost, or client memory is a primary measured concern. Keep ordinary motion and rendering discipline in this skill when no dedicated performance investigation is needed.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Review or implement interface accessibility for semantics, keyboard operation, focus, contrast, status communication, zoom, and assistive technology. Use when accessibility is explicitly requested, required by the product contract, or a changed interaction creates substantial accessibility risk. Do not activate for every visual edit or use it as a generic design audit.

The English summary is being prepared. Showing the original description.

KodekaTeam/superior-skills23Updated Oct 29, 2026

Implement, harden, or review defensive security controls for REST APIs, including authentication and authorization boundaries, validation, rate limiting, abuse prevention, resource limits, SSRF defenses, safe errors, logging, and security tests. Use when API security, endpoint hardening, threat review, rate limiting, token handling, or sensitive business-flow protection is an explicit concern. Do not use for ordinary endpoint logic without meaningful security scope or for offensive exploitation.

The English summary is being prepared. Showing the original description.

KodekaTeam/superior-skills23Updated Oct 29, 2026

Design, implement, or assess project structure, module ownership, dependency boundaries, and safe file or folder organization. Use when project architecture, feature placement, separation of responsibilities, or architectural refactoring is a primary concern, including new framework projects. For a read-only assessment, do not modify files unless the user also requests changes; do not activate merely because ordinary feature work adds a file.

The English summary is being prepared. Showing the original description.

KodekaTeam/superior-skills23Updated Oct 29, 2026

Review a code change, diff, commit, branch, or pull request for actionable defects, regressions, security risks, compatibility breaks, and missing verification. Use when code review is the primary requested outcome. Keep the review read-only unless the user explicitly asks to implement fixes; do not use as a substitute for implementation or a specialized visual audit.

The English summary is being prepared. Showing the original description.

KodekaTeam/superior-skills23Updated Oct 29, 2026

Add, revise, or remove source-code comments while preserving executable behavior. Use for comment-only cleanup, documentation comments, TODO quality, and reducing narration. Do not use when the requested change modifies logic.

The English summary is being prepared. Showing the original description.

KodekaTeam/superior-skills23Updated Oct 29, 2026

Write or revise user-facing product and marketing copy with a specific voice, verifiable claims, natural rhythm, and useful actions. Use for interface labels, onboarding, landing pages, help text, and product messaging. Do not use for code comments or neutral technical documentation unless tone editing is requested.

The English summary is being prepared. Showing the original description.

KodekaTeam/superior-skills23Updated Oct 29, 2026

See all skills by KodekaTeam

Report a problem with this skill