Orangutan

Orangutan

Orangutan bundles two unrelated Claude Code utilities under one plugin. They share no code or state — pick whichever mode matches the request and ignore the other section entirely.

Mode: DESIGN.md

DESIGN.md is a two-layer spec for describing a visual identity to coding agents: YAML front matter carries exact, machine-readable design tokens; the markdown body carries human-readable rationale (why the values exist, how to apply them). Agents get precision from the tokens and judgment from the prose — neither layer alone is enough.

When creating a DESIGN.md for a project

1. Extract, don't invent. Read the project's actual design source of truth first — Tailwind config, CSS custom properties, theme files (e.g. this kind of project may have a themes/index.ts with named templates), Figma tokens if exported, existing component styles. Populate the YAML with real values pulled from code, not guesses. If a project has multiple themes/templates, either produce one DESIGN.md per theme or a components/token structure that parameterizes across them — ask the user which, don't assume.
2. Place it at the repo root as DESIGN.md unless the user specifies otherwise.
3. Fill every canonical section (see below) — if a category genuinely doesn't apply (e.g. no elevation system), keep the heading and state that explicitly rather than omitting it, so the file stays diffable against the spec.
4. Write the prose to justify the tokens, not restate them. "Boston Clay (#B8422E) is the only accent used for destructive actions — never for primary CTAs" is useful; "primary color is #1A1C1E" (already in the front matter) is not.

YAML front matter schema

version: alpha              # optional
name: <string>               # design system name
description: <string>        # optional, one line
colors:
  <token-name>: <Color>
typography:
  <token-name>: <Typography>
rounded:
  <scale-level>: <Dimension>
spacing:
  <scale-level>: <Dimension | number>
components:
  <component-name>:
    <token-name>: <string | token reference>

Token types:

Type	Format	Example
Color	CSS color notation	"#1A1C1E", "oklch(62% 0.18 250)"
Dimension	number + unit	48px, -0.02em
Typography	object	fontFamily, fontSize, fontWeight, lineHeight, letterSpacing

Token references use curly-brace path notation: "{colors.primary}", "{spacing.4}". A component token can point at any other token instead of duplicating its value — prefer references over repeated literals so the file stays single-source-of-truth. Unresolved references are a lint error.

Canonical markdown section order

Sections are ## headings, in this exact order (aliases in parens are acceptable heading text for the same slot):

1. Overview (Brand & Style)
2. Colors
3. Typography
4. Layout (Layout & Spacing)
5. Elevation & Depth (Elevation)
6. Shapes
7. Components
8. Do's and Don'ts

Unknown extra sections are preserved without error. Duplicate headings are invalid — don't emit the same section twice.

When reading/applying an existing DESIGN.md

• Treat the YAML tokens as authoritative values — use them directly (as CSS variables, Tailwind theme extensions, etc.) rather than re-deriving colors/spacing by eye.
• Read "Do's and Don'ts" before writing any new UI — it's the fastest way to avoid a change that's technically on-brand-color but wrong in application (e.g. "never use the accent for primary CTAs").
• If a token needed for a new component doesn't exist yet, extend the components block rather than hardcoding a raw value inline, and note the addition to the user.

Validation

The reference tooling is the @google/design.md CLI (validate / diff / export to Tailwind or W3C token format, plus a linter for broken {...} references and WCAG contrast). If it's available (npx @google/design.md validate DESIGN.md), prefer running it over manual review. If not installed and the task warrants it, ask before adding it as a dependency rather than assuming.

Mode: Install My Plugins

This mode installs from marketplaces the user has already added via /plugin marketplace add or claude plugin marketplace add — it never adds a marketplace itself. Its job is purely: for every marketplace already configured, install every plugin that marketplace offers and isn't installed yet.

Steps

1. claude plugin marketplace list --json — list of configured marketplaces, for the summary report only. Don't add or remove anything here.
2. claude plugin list --json --available — returns { installed: [...], available: [...] }. Each available[] entry has pluginId (e.g. name@marketplace) and marketplaceName. This covers every plugin across every configured marketplace, live — not a cached list.
3. Diff: to_install = [a.pluginId for a in available if a.pluginId not in {i.id for i in installed}].
4. Review step — classify before installing, don't skip this. For each candidate in to_install, inspect what it registers before it's installed, e.g. via claude plugin details <pluginId> (use whatever inspection command the host CLI actually offers; if none exists, fall back to reading the plugin's manifest from its marketplace source). Flag a plugin as needs review rather than auto-installing it if:
   • It declares any hooks, especially PreToolUse/PostToolUse hooks matching broad tool patterns (Bash, Edit, Write, or *). Hooks like this can silently gate or block the very tools needed to fix a problem — this is not hypothetical, a bulk install once enabled a plugin whose hook demanded external MCP login before allowing any Bash or Edit call, breaking the session until the user manually disabled it from outside the session.
   • It bundles an MCP server that requires authentication/login before its tools work.
   • Its manifest/component inventory can't be resolved cleanly — treat "couldn't tell" as needs-review, never as safe-by-default. Everything else is safe to auto-install without per-plugin confirmation.
5. Never silently auto-install a needs-review plugin. Before installing anything, show the user the full needs-review list (plugin id + the specific reason it was flagged, e.g. "registers a PreToolUse hook on Bash/Edit") and get explicit confirmation on which of those, if any, to include. The safe list can proceed straight to installation without per-plugin confirmation — the scale warning below still applies to it.
6. Install the approved set (safe list + any needs-review plugins the user explicitly approved) via claude plugin install <pluginId>. Notes on doing this well:
   • This can be hundreds of plugins and take a long time (several seconds per install is typical — a few hundred plugins can mean 30-60+ minutes). Always run the install loop via a backgrounded shell process, writing progress to a log file, rather than blocking the conversation on it. Log a PROGRESS: n/total line periodically (e.g. every 20) so interim state is checkable.
   • One plugin failing to install (bad manifest, transient network error) must not abort the rest — catch the failure, record the plugin id to a failures list, continue the loop.
   • Skip anything already installed (compare against installed[].id) — don't reinstall.
7. Post-install auto-remediation. The review step (4-5) only catches problems visible before install; some only surface once a plugin is active and its hook/MCP server actually fires (e.g. it blocks tool calls, throws on every invocation, or otherwise breaks the session). When this happens during this same run — a plugin you just installed causes an error that wasn't present before it was installed — treat that as a third handling path distinct from both "safe" and "needs review": automatically disable or uninstall that specific plugin (claude plugin disable <pluginId> or claude plugin uninstall <pluginId>), then tell the user which plugin was removed and exactly what error it caused. Don't leave a plugin that's actively breaking the session installed just because it passed the pre-install review — and don't ask permission first for this specific case, since a broken plugin is actively blocking further conversation; inform after acting, not before.
8. When the job completes, report: total available, already installed before this run, newly installed, failed to install, and auto-removed-after-error (with the reason for each). Include the needs-review plugins that were held back (not installed) so the user can revisit them later.
9. Tell the user new plugins take effect on next session / after a plugin reload — don't try to trigger a reload yourself, that's a user-run action in the host CLI.

Re-running

Because this queries live marketplace state instead of a stored list, re-running it later naturally picks up:

• New marketplaces the user has added since the last run (their available plugins get installed too).
• New plugins added to an existing marketplace's catalog.
• Nothing extra to maintain — there is no manifest file in this skill to keep in sync.

Scale warning

Before running this for the first time on a machine with many marketplaces configured, check the actual count first (claude plugin list --json --available and count .available) and tell the user the number before installing — "install everything" can mean hundreds of plugins on a machine with several large marketplaces added, which noticeably increases context overhead and session startup time going forward. Don't silently install everything without surfacing the scale — confirm if the number is large (a few hundred+) before proceeding, unless the user has already explicitly signed off on "install literally all of it" for this run.