agentsclimarketplace

Recommend

Skill sukoji/loadout/plugins/loadout/skills/recommend

🎯 Loadout β€” profile your project and gear up Claude Code with the right skills, MCP servers & hooks, in one command. A recommender + installer, not a list you read.

Install
npx -y skills add sukoji/loadout --skill recommend

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

  • 1 stars1 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.

What its author says it does

Copied from the file, not written here

Profile the current project and recommend a domain-matched loadout of Claude Code extensions (MCP servers, hooks, settings, skills), then apply the ones the user picks. Use when the user wants to set up, gear up, or optimize Claude Code for this repo, asks "what skills/MCP should I use here", runs /loadout, or opens a fresh project and wants the right tooling configured.

SKILL.md

9.1 KB, as published. Nobody here has run it

Loadout β€” recommend & apply

Your job: look at THIS project, figure out what it is, and hand the user a short, ranked loadout of Claude Code extensions worth adding β€” then apply exactly the ones they choose. You are a recommender and installer, not a list-dumper. Never paste the whole catalog.

Step 0 β€” Load the catalog (3 tiers)

Read the curated (Tier 1) files fully β€” they're small and hand-verified:

  • ${CLAUDE_PLUGIN_ROOT}/catalog/mcp.json
  • ${CLAUDE_PLUGIN_ROOT}/catalog/skills.json
  • ${CLAUDE_PLUGIN_ROOT}/catalog/hooks.json
  • ${CLAUDE_PLUGIN_ROOT}/catalog/domains.json
  • ${CLAUDE_PLUGIN_ROOT}/catalog/community.json (Tier 3, small)

Each item has id, name, description, domains, signals. MCP items carry a config, hook/setting items a settings object, skill items an install block.

Tier 2 (official marketplace) is large (catalog/ecosystem.json, ~240 entries) β€” do NOT read it whole. After you know the project's signals (Step 1), Grep ecosystem.json for those signal tokens to pull only the handful of official plugins that match. Each is a tier: "official", verified Anthropic-marketplace plugin installed with the /plugin install <name>@claude-plugins-official command in its install.commands.

Tier meaning: curated = auto-apply safe; official = trusted, install via /plugin; community (Tier 3) = UNVERIFIED β€” only surface if the user asks to "discover"/see more, label it clearly, and never auto-apply it. Items with "optIn": "token-saver" are never in discover or the domain loadout β€” offer them only in the separate token-saver step (Step 3).

Step 1 β€” Profile the project

Detect what the repo is. Be fast and evidence-based β€” do not ask the user things you can read:

  • Languages / frameworks / package managers: look for package.json (and its deps β€” react, next, vue, svelte, express, nestjs, prisma…), requirements.txt, pyproject.toml, go.mod, Cargo.toml, pom.xml, Gemfile, pubspec.yaml, *.xcodeproj, build.gradle.
  • Infra / CI: Dockerfile, docker-compose*, .github/workflows, *.tf, k8s/helm.
  • Data/ML: *.ipynb, numpy/pandas/torch/tensorflow in deps, wandb/mlflow.
  • Research / academic: *.tex, *.bib, papers/ dir, arxiv in deps.
  • Security surface: auth/payment/crypto libs, presence of .env.
  • What's already set up: read existing .mcp.json, .claude/settings.json, .claude/settings.local.json, and any CLAUDE.md. Never recommend something already installed.

Use Glob/Grep/Read. Keep it to a handful of targeted checks. Summarize the profile in 2–3 lines.

Step 2 β€” Match domains and build the loadout

  1. Score each domain in domains.json by how many of its signals appear in the profile. A domain whose signal is "always" (i.e. general) is always in play as the baseline.
  2. Pick the 1–2 best-matching domains plus general.
  3. Union their loadout id lists. Rank items by: (a) strength of signal match against the project, (b) curated (Tier 1) over official marketplace (Tier 2), (c) whether the item is broadly useful (signals includes "always"), (d) not already installed.
  4. For Tier 2 official plugins: only include when signals are specific (e.g. react, postgres) β€” never flood the list with generic python/package.json matches. Cap official picks at ~2 in the shortlist.
  5. Drop anything already present in the repo's config. Cap the recommendation at ~6–8 items so the choice stays easy. Note (don't hide) anything you cut for length.

Step 3 β€” Present the loadout for selection

First show a tight table so the user can decide informed β€” one row per item with these columns:

ItemKindWhat it doesNeeds
nameMCP Β· official/community, hook, or skillone plain-language linea token / login, or "β€”"

Group by kind (MCP / Hooks & settings / Skills). Then call AskUserQuestion with multiSelect: true. Every option must be self-explanatory β€” a user should never have to guess what a checkbox means:

  • label = the item name.
  • description = [kind Β· official/community] <one-line what it does>. <auth note>. Source: <homepage> β€” e.g. [MCP Β· community] Drives a real browser to test/verify web UIs. No auth. Source: github.com/microsoft/playwright-mcp, or [MCP Β· official] Read/write your Notion pages. Needs a Notion integration token. Source: ….

Put the strongest 2–3 picks first and mark the top one "(Recommended)". Always spell out auth/token needs in the option itself (e.g. "needs a Figma token", "needs a Stripe secret key", "OAuth on first use") so no one installs something and then hits a wall.

Token-saver opt-in (separate from the stack loadout)

After the main loadout question, always offer token-saver skills in a second, separate AskUserQuestion β€” never mix them into the domain loadout table or the first multi-select.

  1. Read community.json for items with "optIn": "token-saver" (currently caveman).
  2. These are not stack recommendations β€” they change how verbose the agent is, not what tools the project needs. Label them clearly: optional, unverified community, reduces output tokens.
  3. Use a single-select or yes/no question, e.g. "Add a token-saver skill (terser replies)?" with caveman as the option. Default is no β€” user must opt in.
  4. Never auto-apply token-savers with the main loadout; never include them when the user says "apply all" unless they explicitly pick the token-saver step.

If a project signal is ambiguous (e.g. no clear framework), ask one short clarifying question about the project's domain before recommending β€” don't guess wildly.

Step 4 β€” Apply what they picked

Apply each selected item by its kind. Always show the exact change and confirm before writing. Merge; never overwrite an existing file wholesale. Prefer project scope unless the user says otherwise.

  • MCP items β†’ merge config into ./.mcp.json under mcpServers.<id>. Create the file if absent. If the item has "auth": true or an env placeholder like <your-...-token>, tell the user exactly which token to fill in and where to get it β€” write the entry but flag the placeholder.
  • Hook / setting items β†’ deep-merge settings into ./.claude/settings.json (create if absent). For hooks, append to the matching event array rather than replacing it. Surface each item's note (dependencies like jq, or platform caveats) so the user isn't surprised.
  • Skill items:
    • install.type: "builtin" β†’ nothing to install; tell the user the command to run (e.g. /init, /code-review) and what it does.
    • install.type: "plugin" β†’ show the install.commands (e.g. /plugin marketplace add … then /plugin install …) for the user to run. If the user asks you to actually install them, run the CLI form via Bash instead β€” claude plugin marketplace add <repo> then claude plugin install <name>@<mp> β€” but only for curated/official items, never for community (unverified) ones.
    • install.type: "manual" / reference β†’ give the homepage link.

After applying, print a short receipt: what was written to which file, what tokens still need filling, and the exact next commands to run. Suggest npx claude-loadout doctor if any auth placeholders were written. Remind the user to restart Claude Code (or /reload-plugins) so new MCP servers and plugins load.

Other agents (Codex, Cursor, opencode, Gemini, OpenClaw)

This skill configures Claude Code. MCP servers are portable to other agents; skills and hooks are not. If the user wants the same MCP servers set up for another agent, tell them to run npx claude-loadout --target <codex|cursor|opencode|gemini|openclaw|all> in the project β€” or, if asked, write that agent's config directly from the catalog's MCP config fields, using the correct file and shape: Codex .codex/config.toml ([mcp_servers.NAME]), Cursor .cursor/mcp.json (mcpServers), Gemini .gemini/settings.json (mcpServers), opencode opencode.json (mcp.NAME, type: local, command array, environment), OpenClaw ~/.openclaw/openclaw.json (mcp.servers.NAME). Never write skills/hooks to these.

Guardrails

  • Read config before writing it; produce a minimal, valid merge. If you can't safely merge, show the snippet and let the user paste it.
  • Every install command you output must come from the catalog's install/config fields or official Claude Code syntax β€” never invent package names or endpoints.
  • Recommend fewer, better. A 6-item loadout the user actually applies beats a 30-item dump they ignore.

Keep looking

Skills are one crate of 328,083. 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.