Agent skill

Visual Review

by nubjs in nubjs/nub

Verify UI/layout/styling changes are correct by computing occlusion, clipping, and alignment from the browser's resolved paint order via the chrome-devtools MCP evaluatescript tool — instead of…

MITAuto-check passedTesting & QA

Install Visual Review

skills CLI
$ npx skills add nubjs/nub --skill visual-review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install nubjs/nub visual-review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/nubjs/nub.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/visual-review .claude/skills/visual-review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
visual-review
GitHub stars
4.4k
Token cost
~3.4k tokens
SKILL.md length
1,083 words
Files
2
Skills in repo
31
Repo updated
First seen
Licence
MIT

At a glance

Verify UI/layout/styling changes are correct by computing occlusion, clipping, and alignment from the browser's resolved paint order via the chrome-devtools MCP evaluatescript tool — instead of…

  • Works in 5 steps: Occlusion (the non-negotiable check) → Ancestor overflow / clip → Alignment and spacing → …
  • Tasks that involve Browser testing
  • SKILL.md covers Optical ≠ mathematical, The evaluate_script routines, Icon-beside-text alignment —… and 7-step checklist, plus 1 more section
  • Runs JavaScript scripts from its folder

What it does

Visual Review is an agent skill from nubjs/nub. Verify UI/layout/styling changes are correct by computing occlusion, clipping, and alignment from the browser's resolved paint order via the chrome-devtools MCP evaluatescript tool — instead of eyeballing a flat screenshot. Invoke BEFORE declaring any UI, site, or styling/layout change correct. Screenshots have no depth buffer, so z-index/occlusion/clip bugs are exactly where "just look at it" fails; the evaluatescript routines below turn those fuzzy visual judgments into deterministic measurements — including…

Its SKILL.md is about 3.4k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `optical-center.js`).

It sits in Testing & QA, covering Browser testing. It works with Model Context Protocol and Chrome DevTools. The repository describes itself as: The fast all-in-one Node.js toolkit. The licence is MIT.

When your agent uses it

  • Tasks that involve Browser testing

Example prompts

  • “just look at it”
  • “/visual-review”

Requirements

  • Node.js

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Occlusion (the non-negotiable check)
  2. Ancestor overflow / clip
  3. Alignment and spacing
  4. Viewport and off-screen
  5. Optical center of mass (different font-sizes)

What it can do on your machine

Read from SKILL.md and the folder at commit 568e73a. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships script files (JavaScript), which the agent can run.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Visual Review loads about 3.4k tokens when it runs. Until then it costs about 168 tokens; SKILL.md has 1,083 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~168
When it runs · the whole SKILL.md, loaded when a task matches
~3.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from nubjs/nub at commit 568e73a, republished under its MIT licence (© nubjs). 1,083 words, ~3,444 tokens.

Download SKILL.mdSave it as .claude/skills/visual-review/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
visual-review
description
Verify UI/layout/styling changes are correct by computing occlusion, clipping, and alignment from the browser's resolved paint order via the chrome-devtools MCP `evaluate_script` tool — instead of eyeballing a flat screenshot. Invoke BEFORE declaring any UI, site, or styling/layout change correct. Screenshots have no depth buffer, so z-index/occlusion/clip bugs are exactly where "just look at it" fails; the `evaluate_script` routines below turn those fuzzy visual judgments into deterministic measurements — including optical center-of-mass, which measures the glyph ink's true visual center so differently-sized labels can be aligned by more than eye.
metadata.internal
true

Visual review — compute occlusion, don't perceive it

A flat PNG has no depth buffer and no stacking-context model, so layering and clipping bugs (z-index, overflow: hidden, fixed/sticky overlays) are exactly where eyeballing fails. The browser already resolved the paint order; query it with evaluate_script (chrome-devtools MCP).

Run both passes. Geometry catches occlusion the eye misses; the eye catches font-metric and color issues geometry misses.

Optical ≠ mathematical

A layout can be geometrically consistent and still look wrong. Never declare a spacing/alignment/centering change correct from measurements alone — change it, screenshot it, look, and adjust by eye. Expect to nudge against the math when:

  • Rounded caps (pills, rounded-full) eat edge space — content at px-3.5 from a rounded end looks tighter than against a square edge, so a pill with symmetric padding and a leading icon looks lopsided; the text-adjacent cap needs more padding (keep symmetric px on the pill, add pr-*/pl-* per button on its text side).
  • Icon ink ≠ icon box — a w-4 icon whose glyph is 14px and visually light leaves dead space, inflating the perceived gap beyond the measured flex gap.
  • Optical ≠ geometric centering — a glyph can be box-centered and ride visually high/low because the font's ink sits asymmetrically in the em.

Geometry decides occlusion/clipping; the eye decides balance/scale/centering.


The evaluate_script routines

Replace 'SELECTOR' with a real CSS selector before running.

1 — Occlusion (the non-negotiable check)

Reports what fraction of the element is actually visible, and names anything covering it.

js
(selector => {
  const el = document.querySelector(selector);
  if (!el) return { error: 'not found' };
  const r = el.getBoundingClientRect();
  if (r.width === 0 || r.height === 0) return { error: 'zero-size box' };
  const N = 5;                       // 5×5 = 25 sample points across the box
  let visible = 0; const coveredBy = new Set();
  for (let i = 0; i < N; i++) for (let j = 0; j < N; j++) {
    const x = r.left + (i + 0.5) / N * r.width;
    const y = r.top  + (j + 0.5) / N * r.height;
    const top = document.elementFromPoint(x, y);   // topmost painted element here
    if (top === el || el.contains(top)) visible++;
    else if (top) coveredBy.add(top.tagName.toLowerCase() +
                                (top.id ? '#' + top.id : '') +
                                (top.className ? '.' + String(top.className).split(' ')[0] : ''));
  }
  return { coverage: visible / (N * N), coveredBy: [...coveredBy] };
})('SELECTOR')

coverage === 1 → no occlusion. coverage < 1 with a coveredBy entry that is not an ancestor/descendant → occlusion bug; the array names the covering element. No z-index reasoning required — elementFromPoint returns the browser's resolved paint order.

2 — Ancestor overflow / clip
js
(selector => {
  const el = document.querySelector(selector);
  const r = el.getBoundingClientRect();
  for (let p = el.parentElement; p; p = p.parentElement) {
    const o = getComputedStyle(p).overflow;
    if (o === 'visible') continue;
    const pr = p.getBoundingClientRect();
    if (r.left < pr.left || r.top < pr.top || r.right > pr.right || r.bottom > pr.bottom)
      return { clippedBy: p.tagName + (p.id ? '#' + p.id : ''),
               overflow: o, target: r, clip: pr };
  }
  return { clipped: false };
})('SELECTOR')

clipped: false is clean. Anything else → the element is cropped by that ancestor.

3 — Alignment and spacing
js
([a, b] => {
  const A = document.querySelector(a).getBoundingClientRect();
  const B = document.querySelector(b).getBoundingClientRect();
  return {
    leftAligned: Math.abs(A.left - B.left),       // px delta; ~0 = aligned
    centerXdelta: Math.abs((A.left+A.right)/2 - (B.left+B.right)/2),
    gap: B.top - A.bottom,                          // vertical spacing between them
  };
})(['SEL_A', 'SEL_B'])

State verdicts in px: "left-edge delta 2px (clean)", "gap 28px vs expected 24px."

getBoundingClientRect centers the line box, not the visible ink. Fine at the same font-size; for elements at different font-sizes that must look centered together, use §5.

4 — Viewport and off-screen
js
(selector => {
  const r = document.querySelector(selector).getBoundingClientRect();
  return {
    inViewport: r.top >= 0 && r.left >= 0 && r.bottom <= innerHeight && r.right <= innerWidth,
    rect: r,
    viewport: { w: innerWidth, h: innerHeight },
  };
})('SELECTOR')
5 — Optical center of mass (different font-sizes)

Measures the alpha-weighted centroid of the actual glyph ink by rasterizing each label's computed font to a canvas. Implementation lives beside this skill in optical-center.js; inline it into one evaluate_script call.

js
// after inlining optical-center.js in the same evaluate_script:
opticalCenter(['.wordmark', 'a[href="/docs"]', 'a[href="/blog"]'])
//  → results:[{selector, comY, deltaFromAnchor}],  cssHint:[{selector, nudge}]
//    deltaFromAnchor ~0 = optically aligned; cssHint gives the ready-to-paste translate.
  • One call does measure + fix + verify. { apply: true } nudges each non-anchor toward the anchor, re-measures the post-nudge DOM, and iterates until converged, returning { before, after, appliedTranslateY }. Don't hand-derive nudges — transcribe appliedTranslateY to CSS.
  • { overlay: true } paints the analysis onto the page (anchor solid-green, others dashed-red, px deltas labelled) so the next screenshot self-documents.
  • Anchor choice matters — a filled pill/badge is optically centered by its BOX, not its caps ink; anchor to a bare-glyph sibling.
  • Auto-handled: the baseline probe uses vertical-align:baseline, which flex/grid ignore, so the tool descends from a flex <a> to the inline element hosting the text.
  • Scope: exact for a single line of plain text. Letter-spacing, text-shadow, -webkit-text-stroke, gradient text, and raster content aren't in the font render — screenshot the element's clip box and centroid the real pixels instead, or trust the eye.

Keep it to ONE tool call. To avoid re-inlining ~6KB, define it once via navigate_page's initScript so window.opticalCenter exists in every later evaluate_script.

Portability

optical-center.js is dependency-free, JSON-in/JSON-out, no closure over outer scope, so it rides on any evaluate primitive. Pattern is always: inject once (defines window.opticalCenter) → call it.

js
// chrome-devtools MCP — inline in one evaluate_script, or persist via initScript:
navigate_page({ url, initScript: <contents of optical-center.js> })
evaluate_script(`() => window.opticalCenter(['.wm','a[href="/docs"]'], { overlay:true })`)

// Playwright (Node):
await page.addInitScript({ path: 'optical-center.js' });     // window.opticalCenter on every doc
const r = await page.evaluate(([t,o]) => window.opticalCenter(t,o),
                              [['.wm','a[href="/docs"]'], { apply:true }]);

// Puppeteer:
await page.evaluateOnNewDocument(fs.readFileSync('optical-center.js','utf8'));
const r = await page.evaluate((t,o) => window.opticalCenter(t,o),
                              ['.wm','a[href="/docs"]'], { overlay:true });

// Selenium / WebDriver (any language):
driver.execute_script(open('optical-center.js').read())       // define it once
r = driver.execute_script("return window.opticalCenter(arguments[0], arguments[1])",
                          ['.wm', 'a[href="/docs"]'], { 'apply': True })

// DevTools console / bookmarklet: paste the file, then call opticalCenter([...]).

Don't break these invariants when editing the file: no import/export/require in the injected source, args stay plain JSON, the return stays JSON-serializable (never a DOM node), and it keeps defining a single global.


Show full SKILL.md (491 more words)Show less

Icon-beside-text alignment — measure each glyph's INK

The most-repeated visual defect: an icon, glyph, emoji, badge, or counter beside text, riding high or low. items-center centers the glyph's BOX on the flex line; the eye aligns INK, and those never coincide — a digit has no descender so its ink rides high, an SVG's ink sits wherever its path falls in its viewBox, and an emoji is a bitmap whose metrics ignore your font size.

One shared nudge cannot fix a cluster. Measure each glyph, correct each glyph. Illustrative divergence for a real count-badge cluster (11.5px text, 12px icons):

glyphink heightoffset from the digit's ink centercorrection
filled octicon10.8px1.16px lowtranslateY(-0.1em)
lucide stroke glyph9.0px1.29px lowtranslateY(-0.112em)
emoji16.0px0.26px — sub-pixelnone; a nudge only blurs the bitmap
  • Express the correction in em, never px, then prove it by doubling the cluster's font size and re-measuring; the residual must stay near zero.
  • Leave sub-pixel offsets alone. Below ~0.3px you are under the device grid.
  • Re-measure after correcting. The residual should read ~0.01px.
js
// Baseline: an empty zero-size inline-block's bottom margin edge IS the baseline of the INLINE context
// it sits in. THE TRAP: a badge holder is usually inline-FLEX, so a probe appended there becomes a FLEX
// ITEM and reports the flex line's center — inflating a real 1.2px error into a plausible 3.5px one.
// Wrap the text node in its OWN inline span, probe INSIDE.
const baselineOfTextNode = (node) => {
  const span = document.createElement("span")
  node.parentNode.insertBefore(span, node); span.appendChild(node)
  const probe = document.createElement("span")
  probe.style.cssText = "display:inline-block;width:0;height:0;padding:0;margin:0;border:0"
  span.appendChild(probe)
  const baseline = probe.getBoundingClientRect().bottom
  const cs = getComputedStyle(span)
  const font = `${cs.fontStyle} ${cs.fontWeight} ${cs.fontSize} / ${cs.lineHeight} ${cs.fontFamily}`
  probe.remove(); span.parentNode.insertBefore(node, span); span.remove()
  return { baseline, font }
}
const inkOfText = (text, font, baseline) => {
  const c = document.createElement("canvas").getContext("2d"); c.font = font
  const m = c.measureText(text)
  return { top: baseline - m.actualBoundingBoxAscent, bottom: baseline + m.actualBoundingBoxDescent }
}
// An SVG geometry element's getBoundingClientRect IS its ink box (stroke included). Union EVERY child —
// a multi-path icon's ink is all of it, not the first path.
const inkOfSvg = (svg) => {
  const rects = [...svg.querySelectorAll("path,rect,circle,ellipse,polyline,polygon,line")]
    .map((g) => g.getBoundingClientRect())
  return { top: Math.min(...rects.map((r) => r.top)), bottom: Math.max(...rects.map((r) => r.bottom)) }
}
// → returns textInkCenter - glyphInkCenter. NEGATIVE = glyph sits BELOW the text and must be LIFTED.

Distrust a suspiciously large reading. A 3.5px error on an 11.5px font is ~30% — a broken instrument, not a misalignment. If the number claims a gross error and the picture shows a subtle one, fix the instrument.

Mirror the real product before inventing a treatment. If the thing exists in a product the user knows (GitHub, Linear, an existing component), drive the real one headless and read its computed values rather than designing from taste. Corollary: color belongs to an item's own state, not to its links.


7-step checklist

Run for any change to site/ or other rendered UI. Steps 3–4 are what a screenshot review cannot do.

  1. You are the first reviewer of your own screenshot. Capturing evidence is not reviewing it. Read the shot back and hunt for what is WRONG — a glyph riding high, one mark heavier than its neighbours, a collision at a narrow width. Capture at a scale where the detail is judgeable. Never hand the user a screenshot you have not personally critiqued.
  2. Screenshot — take_screenshot, full page + tight crop around the changed element.
  3. Console — list_console_messages. A 200 alongside a thrown error is still a broken page.
  4. Occlusion pass — §1 on the changed element AND neighbors near fixed/sticky/absolute/overlay elements. coverage < 1 with a non-ancestor cover → flag it.
  5. Clip pass — §2 on the changed element.
  6. Alignment/spacing pass — §3 for anything that should align or sit at a fixed gap. For labels at different font-sizes, §5. For any icon/glyph/emoji beside text, the ink measurement above, per glyph, then re-measure the residual.
  7. Viewport pass — §4.
  8. State the verdict in measurements. "coverage 1.0, clip: false, left-edge delta 0px" — never a bare "looks great."

If chrome-devtools MCP is unavailable

Say so explicitly. Reason about stacking from the CSS (position, z-index, overflow, paint order), but label it inference, not measurement. Do not silently claim visual verification you couldn't do.

© nubjs, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in .claude/skills/visual-review of nubjs/nub.

  • SKILL.md
  • optical-center.js

Open the folder on GitHubat commit 568e73a

Compare with similar skills

Visual Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Visual Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Visual Review this skillnubjs/nub4.4k—~3.4kAutomated safety check: PassMIT
Browser Testing with Chrome DevToolsaddyosmani/agent-skills103k4 repos~3.5kAutomated safety check: WarnMIT
Diff-Driven Smoke TestsSkyvern-AI/skyvern23k—~5.2kAutomated safety check: PassAGPL-3.0
System Bridge Testing Workflowtimmo001/system-bridge356—~843Automated safety check: PassApache-2.0
Mirroir Onboardjfarcand/mirroir-mcp245—~4.4kAutomated safety check: NotesApache-2.0
Capture Bannersnguyenyou/scalex109—~586Automated safety check: PassMIT

Similar skills

  • Connects an agent to a real Chrome instance through the Chrome DevTools MCP server, so it can inspect the DOM, read console errors and profile performance directly.

    103k GitHub starsUsed in 4 repos~3.5k tokens
    Testing & QAAuto-check: warnings
  • Diff-Driven Smoke Tests

    Skyvern-AI/skyvern

    Reads your git diff, writes a handful of happy-path browser smoke tests, runs them with Skyvern or Chrome DevTools MCP and posts screenshot evidence to the PR.

    23k GitHub stars~5.2k tokensUpdated today
    Testing & QAAuto-check passed
  • System Bridge Testing Workflow

    timmo001/system-bridge

    How to test System Bridge - Go table-driven tests and commands, web-client quality checks (lint/typecheck/format, no unit tests), the Chrome DevTools MCP interactive test loop for UI and WebSocket…

    356 GitHub stars~843 tokensUpdated today
    Testing & QAAuto-check passed
  • Mirroir Onboard

    jfarcand/mirroir-mcp

    Onboard a consumer web app to mirroir's .mirroir/ dotfile by EXPLORING the running app (chrome-devtools-mcp) — derive real selectors from the accessibility tree, exercise each surface's primary…

    245 GitHub stars~4.4k tokensUpdated 2 days ago
    Testing & QAAuto-check: notes
  • Capture Banners

    nguyenyou/scalex

    Re-render Scalex banner and OG image PNGs from their HTML source files using Chrome DevTools MCP.

    109 GitHub stars~586 tokensUpdated 20 days ago
    Testing & QAAuto-check passed
  • Octocode Chrome Devtools

    bgauryy/octocode

    A skill your agent uses when a live page needs Chrome DevTools/CDP evidence: network failures, console errors, performance, DOM/CSS actionability, screenshots/PDF, cookies/storage…

    949 GitHub stars~1.6k tokensUpdated 5 days ago
    Testing & QAAuto-check passed

More from nubjs/nub

All 31 skills in this repo
  • Cpu Reduction

    nubjs/nub

    Diagnose and clear CPU, memory, and disk contention on the maintainer's dev host.

    4.4k GitHub stars~2.8k tokensUpdated yesterday
    Auto-check passed
  • Reclaim disk on the maintainer's Mac when the volume is full or filling — ENOSPC, "no space left on device", a failed build or agent harness, or a routine sweep of Rust build residue.

    4.4k GitHub stars~2.4k tokensUpdated yesterday
    Auto-check passed
  • Nub Charts

    nubjs/nub

    Build a performance chart for nubjs.com — the SVG bar figures in blog posts, docs pages and social posts (a runtime augmentation against plain node, an install or dispatch comparison, a cross-tool…

    4.4k GitHub stars~4.6k tokensUpdated yesterday
    Auto-check passed
  • Audit Thread

    nubjs/nub

    A skill your agent uses when running a compatibility/parity AUDIT — enumerating where nub diverges from a reference it claims parity with (pnpm CLI grammar, a lockfile format, a Node behavior, a…

    4.4k GitHub stars~1.8k tokensUpdated yesterday
    Auto-check passed
  • Linux Vm Test

    nubjs/nub

    Run ad-hoc Nub tests and debugging probes on real local Linux guests.

    4.4k GitHub stars~986 tokensUpdated yesterday
    Auto-check passed
  • Performance-trace Nub package-manager installs using the existing phase timings, structured diagnostics, and sampling-profiler workflow.

    4.4k GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed

Categories

Questions about Visual Review

What does Visual Review do?

Verify UI/layout/styling changes are correct by computing occlusion, clipping, and alignment from the browser's resolved paint order via the chrome-devtools MCP evaluatescript tool — instead of…. Visual Review is an agent skill from nubjs/nub. Verify UI/layout/styling changes are correct by computing occlusion, clipping, and alignment from the browser's resolved paint order via the chrome-devtools MCP evaluatescript tool — instead of eyeballing a flat screenshot.

When should I use Visual Review?

Visual Review fits situations like: tasks that involve Browser testing.

How do I install Visual Review in Claude Code?

Run `npx skills add nubjs/nub --skill visual-review -a claude-code`. Or copy the skill folder (.claude/skills/visual-review in nubjs/nub) into .claude/skills/visual-review in your project. Claude Code loads it when a task matches its description.

How do I install Visual Review in Codex?

Run `npx skills add nubjs/nub --skill visual-review -a codex`. Or copy the skill folder (.claude/skills/visual-review in nubjs/nub) into .agents/skills/visual-review in your project. Codex loads it when a task matches its description.

Can I use Visual Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add nubjs/nub --skill visual-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/visual-review, .gemini/skills/visual-review, .github/skills/visual-review and .opencode/skills/visual-review in your project.

What does Visual Review need to run?

Going by SKILL.md and its folder, Visual Review needs JavaScript for the scripts in its folder. Our summary lists: Node.js.

Does Visual Review access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Visual Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Visual Review use?

Visual Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Visual Review use?

About 3.4k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Visual Review?

Skills that share tags, products or a category with Visual Review: Browser Testing with Chrome DevTools (addyosmani/agent-skills, 103k stars), Diff-Driven Smoke Tests (Skyvern-AI/skyvern, 23k stars), System Bridge Testing Workflow (timmo001/system-bridge, 356 stars) and Mirroir Onboard (jfarcand/mirroir-mcp, 245 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Visual Review?

nubjs (a GitHub organization) maintains it in nubjs/nub, which has 4,372 GitHub stars. The repository holds 31 skills in this directory. The repository was last updated on October 7, 2026.

Source: nubjs/nub on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.