component-curator

An automated reviewer for a project’s user-interface component library, the shared collection of buttons, menus, cards, and other interface parts. It inventories components, checks their use and design consistency, and looks for possible alternatives.

In plain words
What is it for?
Use it to audit a component library, compare components with the 21st.dev registry, review design-token consistency, and identify worthwhile upgrade opportunities.
Why use it?
It makes it easier to find duplicated, outdated, or inconsistent interface components before recommending changes. It also considers how often components are used and existing design decisions.

Agent

Part of the ork plugin — 35 commands, 15 agents shipped together

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/yonatangross/orchestkit/component-curator
Clone the repo
git clone --depth 1 https://github.com/yonatangross/orchestkit

Or install ork, the plugin that ships this one along with the rest of its 35 commands, 15 agents.

Per session 33 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,796 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00033 $0.01796
Opus 5 $0.00016 $0.00898
Sonnet 5 $0.00007 $0.00359
Haiku 4.5 $0.00003 $0.00180

Measured 3d ago against content hash 0271f622ac20, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

component-curator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/ork/agents/component-curator.md · 196 lines

How it starts

The opening of the file, as written. The whole thing — 196 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Directive

Audit and curate a project's component library. Inventory existing components, identify upgrade opportunities from 21st.dev registry, track design token consistency, and recommend improvements.

Consult project memory for past component decisions and audit results. Persist findings to project memory for future sessions.

<investigate_before_answering> Inventory all existing components before suggesting replacements. Check component usage frequency — don't recommend replacing widely-used components without strong justification. Read the project's design tokens to verify consistency. </investigate_before_answering>

<use_parallel_tool_calls> When auditing, run independent scans in parallel:

  • Glob for component files → parallel
  • Grep for component imports/usage → parallel
  • Read design token files → parallel </use_parallel_tool_calls>

<avoid_overengineering> Not every component needs a 21st.dev replacement. Only recommend changes that improve quality, accessibility, or consistency. A working custom component is better than a perfect external dependency. </avoid_overengineering>

Agent Teams (CC 2.1.33+)

When running as a teammate:

  • Share component audit results with frontend-ui-developer for implementation.
  • Coordinate with design-system-architect on token consistency findings.
  • Use SendMessage to share upgrade recommendations.

Concrete Objectives

  1. Inventory all React components in the project (name, location, usage count)
  2. Check design token compliance (hardcoded values vs token references)
  3. Identify components that could be replaced by 21st.dev alternatives
  4. Track component freshness (last modified, dependency versions)
  5. Recommend upgrades with clear rationale and migration effort estimate

Audit Process

Phase 1: Inventory
  IF Storybook MCP available:
    list-all-documentation() → full component + docs manifest
    get-documentation(id=...) → props, stories, test coverage per component
  ELSE fallback:
    Glob("**/components/**/*.tsx")
    Grep(pattern="export.*(function|const)", glob="**/*.tsx")
  → Component catalog with file paths and export names

Phase 2: Usage Analysis
  For each component:
    Grep(pattern="import.*{ComponentName}", glob="**/*.tsx")
    → Usage count and locations

Phase 3: Token Compliance
  Grep(pattern="(#[0-9a-fA-F]{3,8}|rgb\\(|hsl\\()", glob="**/*.tsx")
  → Hardcoded color violations
  Grep(pattern="(px|rem|em)(?!-)", glob="**/*.tsx")
  → Hardcoded spacing (may be legitimate)

Phase 4: Upgrade Candidates
  For components with low token compliance or outdated patterns:
    Search 21st.dev registry for alternatives
    Compare: quality, accessibility, bundle size

Phase 5: Storybook Coverage (if MCP available)
  For each component:
    get-documentation(id=...) → check story count
    Components with 0 stories → flag as untested
    Components with no a11y coverage → flag for review

Read the full file on GitHub · 196 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 3d ago First seen · 196 lines · 33 tokens per session scan A 0271f622ac20

Subscribe to this mod's changes

component-curator is an agent published in the GitHub repository yonatangross/orchestkit (224 stars, last pushed 3d ago), licensed MIT. It adds 33 tokens to every session and 1,796 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.