agentsclimarketplace
Sign in

Ui guidance

Skill n-n-code/n-n-code-skills/.agents/skills/ui-guidance

Overlay for graphical UI and web frontend code. Use alongside the repo's implementation skill when implementing or reviewing UI changes.From its SKILL.md

Install
npx -y skills add n-n-code/n-n-code-skills --skill ui-guidance

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.3 KB, 656 tokens by cl100k_base, as published. Nobody here has run it

UI/Frontend Guidance

This is a composable overlay, not a standalone workflow. Use alongside the repo's implementation skill (e.g. coding-guidance-cpp, project-core-dev) when the change touches UI or frontend code.

Use this as the thin default overlay for ordinary UI work. If the task is redesign-heavy, frontend-polish heavy, or needs a stronger UX review checklist, prefer ui-design-guidance.

Routing examples:

  • add a small control that matches nearby components -> use this skill
  • fix spacing, labels, or responsive behavior within the existing visual language -> use this skill
  • redesign a page, introduce a new visual direction, or perform a UX-heavy release review -> use ui-design-guidance
  • product-security or permission-sensitive UI flows -> add security when the main risk is trust, identity, or authorization rather than presentation

When to use

The repo includes graphical UI or web frontend code — web views, desktop UI, embedded panels, or rendering layers.

Not for

Terminal UIs (ncurses, TUI frameworks) unless the repo explicitly treats them as UI with design standards. Pure data visualization or plotting libraries are also out of scope.

Rules

  • Preserve the existing design language unless the task explicitly calls for redesign. Do not introduce new color palettes, spacing systems, or component patterns without justification.
  • Accessibility, layout stability, and responsive behavior are part of done — not follow-up work.
  • UI changes must not bypass the repo's test and build hygiene.
  • Verify visual output manually or with snapshot tests if the repo supports them.
  • If the repo does not document breakpoints, design tokens, or visual test tooling, derive them from nearby UI code and record the fallback evidence in any implementation or review note you produce.

Decision Heuristics

  • Design language check: before adding a new visual element, grep the codebase for an existing element that serves a similar purpose. Match its spacing, color tokens, and component structure unless the task requires divergence.
  • Evidence fallback: when the repo lacks UI docs, use the nearest existing component or screen as the baseline and name the files inspected.
  • Accessibility bar: if the change adds interactive elements, verify keyboard navigation and screen reader labels. If the repo has no a11y testing, add manual verification to the review checklist.
  • Layout stability: if the change affects layout, test at the repo's supported viewport sizes. If those are undocumented, test at the common breakpoints already exercised by nearby code or styles. Flag layout shifts that appear on resize or content change.

Validation

A UI change is done when (in addition to the base implementation skill's validation):

  • visual output matches the existing design language or the requested redesign
  • interactive elements are keyboard-navigable
  • layout is stable across supported viewports
  • when automated UI verification is absent, any implementation or review note you produce names the screenshots, snapshots, or manual checks used as evidence

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most design frontend skills give in 656 tokens

Counted across 1,169 of the 1,878 authors here whose files we hold, read 2026-08-07

  • Use CSS variables for color consistencyin 72 of 1169, across 23 files
  • Commit to one bold aesthetic direction before codingin 72 of 1169, across 27 files
  • Match implementation complexity to the aesthetic visionin 70 of 1169, across 20 files
  • Add atmospheric background effects and texturesin 57 of 1169, across 9 files
  • Use unexpected spatial compositions and layoutsin 56 of 1169, across 8 files
  • Implement real working codein 55 of 1169, across 7 files
  • Vary themes and aesthetics across different designsin 48 of 1169, across 7 files
  • Launch chromium in headless modein 47 of 1169, across 4 files
  • Close the browser when donein 47 of 1169, across 4 files
  • Run provided scripts with help flag firstin 47 of 1169, across 4 files
  • Wait for network idle statein 47 of 1169, across 4 files
  • Use descriptive selectors for elementsin 47 of 1169, across 4 files

Said here and by no other author read

  • use alongside repo implementation skill for UI changes
  • prefer ui-design-guidance for redesign-heavy tasks
  • add security skill for permission-sensitive UI flows
  • preserve existing design language unless task explicitly calls for redesign
  • treat accessibility, layout stability, and responsive behavior as done criteria
  • do not bypass repo test and build hygiene for UI changes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,758. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.