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.
npx -y skills add sukoji/loadout --skill recommendAssembled 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/tensorflowin deps,wandb/mlflow. - Research / academic:
*.tex,*.bib,papers/dir,arxivin 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 anyCLAUDE.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
- Score each domain in
domains.jsonby how many of itssignalsappear in the profile. A domain whose signal is"always"(i.e.general) is always in play as the baseline. - Pick the 1β2 best-matching domains plus
general. - Union their
loadoutid 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 (signalsincludes"always"), (d) not already installed. - For Tier 2 official plugins: only include when signals are specific (e.g.
react,postgres) β never flood the list with genericpython/package.jsonmatches. Cap official picks at ~2 in the shortlist. - 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:
| Item | Kind | What it does | Needs |
|---|---|---|---|
| name | MCP Β· official/community, hook, or skill | one plain-language line | a 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.
- Read
community.jsonfor items with"optIn": "token-saver"(currently caveman). - 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.
- 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.
- 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
configinto./.mcp.jsonundermcpServers.<id>. Create the file if absent. If the item has"auth": trueor anenvplaceholder 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
settingsinto./.claude/settings.json(create if absent). For hooks, append to the matching event array rather than replacing it. Surface each item'snote(dependencies likejq, 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 theinstall.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>thenclaude plugin install <name>@<mp>β but only for curated/official items, never for community (unverified) ones.install.type: "manual"/referenceβ give thehomepagelink.
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/configfields 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.