crush-config

Use when the user needs help configuring Crush — writing crushrc (the Bash config format) or crush.json, setting up providers, models, LSPs, MCP servers, hooks, skills, permissions, or changing Crush behavior.

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

82%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A strong, highly actionable reference: executable examples for every command group, tight prose that assumes competence, and good internal navigation. The main gaps are minor — a couple of slightly redundant passages, no explicit validation/recovery step for config changes, and all reference detail inlined in one long file rather than split into a references bundle.

Suggestions

Trim the redundancy between the hook-output field descriptions and the decision-aggregation bullets (e.g., fold 'updated_input: last non-empty wins' into one place) and shorten the stdin JSON sample to the fields hooks actually read.

Add a short 'making a change' workflow with a validation checkpoint, e.g., write the crushrc statements, then confirm they took effect via `model large` (no-arg print) or by checking the startup warning when both crushrc and crush.json are present.

Move the long flag inventories (provider/model/mcp/lsp flags) and the hooks runtime spec into a references/ file (e.g., references/commands.md), keeping SKILL.md as an overview with well-signaled one-level-deep links.

Dimension	Reasoning	Score
Conciseness	The body is dense reference material with no padding — it never explains concepts Claude already knows (Bash, MCP, LSPs) and every section is commands, flags, or behavioral rules. Minor trim opportunities exist (the decision-aggregation bullets partially restate the hook-output field rules, and the full stdin JSON sample), which keeps it just below the lean 'every token earns its place' anchor.	4 / 5
Actionability	Every command family ships copy-paste-ready executable examples ('provider add deepseek --type openai-compat --base-url ... --api-key "${DEEPSEEK_API_KEY:?...}"', 'mcp add github --type http --url ...', 'hook add PreToolUse --matcher "^bash$" ...'), plus a concrete crushrc↔crush.json mapping table covering the common cases.	5 / 5
Workflow Clarity	The body follows a clear sequence (formats → discovery priority → per-entity command reference → hooks runtime → user-invocable skills → env vars → legacy JSON mapping) and offers a verification affordance ('model large with no argument prints the current selection'). It falls short of a 5 because there is no explicit validate-the-config step or error-recovery guidance for a change that fails to load; the destructive/batch cap does not apply since config editing is not a destructive batch operation.	4 / 5
Progressive Disclosure	A single self-contained file with no bundle files present; sections are well organized with working internal anchors ([Hooks runtime](#hooks-runtime), [Legacy JSON format](#legacy-json-format)) and the mapping table gives one-glance navigation. It is not a 5 because all detail — full flag inventories, the hooks runtime spec, and the option catalog — is inlined in a ~380-line file rather than offloaded to well-signaled one-level-deep reference files, and the under-50-line simple-skill exception does not apply.	4 / 5
	Total	17 / 20 Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An excellent description: concrete and comprehensive on capabilities, with an explicit 'Use when' trigger clause and tool-specific file names that make it both highly discoverable and clearly distinct from other configuration skills. The only weakness is a handful of missing natural synonyms users might phrase differently.

Dimension	Reasoning	Score
Specificity	The description enumerates multiple concrete actions — 'writing crushrc (the Bash config format) or crush.json, setting up providers, models, LSPs, MCP servers, hooks, skills, permissions, or changing Crush behavior' — with comprehensive coverage of the tool's config surfaces, matching the top anchor rather than the 'minor gaps' anchor below it.	5 / 5
Completeness	It explicitly answers both questions: the 'what' (writing crushrc/crush.json, setting up the enumerated entities) and a concrete 'Use when the user needs help configuring Crush...' trigger clause, exactly matching the 5 anchor's 'both what AND when with concrete trigger phrases'.	5 / 5
Trigger Term Quality	Good natural keyword coverage including concrete file names ('crushrc', 'crush.json') and entity terms users would actually say ('configuring Crush', 'MCP servers', 'hooks', 'permissions'). It stops short of the 5 anchor because a few natural phrasings are missing, such as 'crush config file', 'API keys', 'settings', or 'change the model'.	4 / 5
Distinctiveness Conflict Risk	It names the specific tool (Crush) and its distinctive file formats (crushrc, crush.json), carving out a clear niche with minimal risk of triggering for an unrelated skill; it is far above the 'minor overlap risk' anchor at 4.	5 / 5
	Total	19 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: charmbracelet/crush
Path: internal/skills/builtin/crush-config/SKILL.md
Commit: 8da3490

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.