Conciseness

Every line is a path, a copy-paste grep, a named API, or a decision rule (e.g. "A pixel-size fix swaps only the size class for its exact-pixel token (`text-[12px]` → `text-caption`)") — no explanation of concepts Claude already knows and no padding. Not 4 because nothing can be trimmed without losing operational content; the dense exception lists (exempt shells, non-heading title values) each earn their place.

Actionability

Gives copy-paste-ready commands with exact pathspecs (`git grep -n "flex h-full flex-col bg-\[var(--bg)\]" -- 'apps/sim/**/settings/**' 'apps/sim/ee/'`), named functions (`saveDiscardActions()`, `useSettingsUnsavedGuard`), and expected-match lists to judge output against. Not 5 because key shapes — the canonical page body, the save/discard wiring, and the resource-row contract — are deferred to `.claude/rules/sim-settings-pages.md` rather than shown, so Mode A steps 3–4 and the Mode C conversion aren't executable from this file alone; not 3 because everything actually written here is concrete and executable.

Workflow Clarity

Each mode is a numbered find→fix→verify sequence with explicit validation checkpoints, including for the batch sweep: "Verify the whole sweep: the local gate in the root CLAUDE.md, plus the affected pages' tests. Diff each file against the base and confirm the change is purely structural before shipping." Not 4 because no mode lacks a checkpoint — even Mode C's verify includes a per-block diff read for lost props, conditions, and key placement.

Progressive Disclosure

Clear mode-based sections and a "Key paths" map, with repeated, well-signaled one-level-deep pointers to the convention doc ("The full convention lives in `.claude/rules/sim-settings-pages.md` — read it first; this skill is the procedure"). Not 5 because the skill ships no bundle files and its completeness hinges on external repo rule files that cannot be verified from the bundle itself — a single moved path would silently hollow out Modes A–C; not 3 because structure and reference signaling are clear throughout with no nested-reference chains.

Specificity

"Add a new Sim settings page" and "audit existing settings pages for design-system compliance with the shared SettingsPanel layout" are two concrete, domain-specific actions, but coverage is not comprehensive — the row-migration capability (Mode C, `SettingsResourceRow`) is never mentioned. Not 4 because only two actions are listed rather than several; not 2 because the actions are concrete rather than generic.

Completeness

Explicitly answers both what ("Add a new Sim settings page, or audit existing settings pages for design-system compliance with the shared SettingsPanel layout") and when ("Use when creating a settings tab, or when asked to check/clean up settings pages so they match the design system") with concrete trigger phrases. Not 4 because the when clause is already explicit and specific, not merely present.

Trigger Term Quality

Natural user phrasings are present — "creating a settings tab", "check/clean up settings pages", "match the design system", "consistent title, header, search, spacing" — giving good keyword coverage. Not 5 because common variations (e.g. "settings section", "new settings", migration/"resource row" triggers) are missing; not 3 because coverage includes multiple natural synonyms beyond a couple of generic keywords.

Distinctiveness Conflict Risk

"Sim settings page" and "shared SettingsPanel layout" pin a narrow, repo-specific niche with distinct triggers, so overlap with any other skill is minimal. Not 4 because no plausible overlap scenario exists — the triggers are unambiguous.