Conciseness

The body never explains concepts Claude already knows — there is no 'Linear is a project tracking tool' padding, and lines like 'Every read and write goes to Linear's API as it runs; no tracker data is stored locally' are ruthlessly compressed. But several sections carry rare-needed operational policy at full length in the always-loaded file: the ~19-line 'Request journal' section ('It sums only returned valid X-Complexity values. Missing values stay unread. Shared remaining-quota changes are never request costs.'), the 'Shared label maintenance' governance paragraphs, and the single-bullet 'issues complete' wall of conditions. This matches level 3 ('mostly efficient but... could be tightened' — via relocation and compression). It is not level 2 because there is no fluff or known-concept explanation — every sentence carries non-obvious information — and not level 4 because a substantial fraction of the 170 lines is edge-case material that most invocations never use.

Actionability

Concrete, executable guidance dominates: the invocation pattern 'linear.sh <resource> <action> [options]', a full resource/action table, and copy-ready examples like 'linear.sh issues list --project "Phase 2" --state "Todo,In Progress" --max' and 'linear.sh journal start --max-bytes BYTES --actor-id UUID'. It is not level 5 because several common flows (create with agent labels, the --labels replace-and-validate procedure, quota-hold handling) are described only in prose with no example command, and a few examples use bare placeholders ('attachments fetch [URL] --output tmp/[FILENAME]'). It is above level 3 because what is shown is genuinely executable, not pseudocode, and the '--help' per-resource detail path is real.

Workflow Clarity

Validation checkpoints are explicit and pervasive for risky operations: 'Run auth-check --strict before the first mutation', the label procedure 'Fetch current labels, compute the final set, validate it against labels list --max --format=safe, then pass the complete set', post-mutation verification via 'issues bulk-get', and batch failure semantics ('Partial failures emit per-issue results, partial: true, and exit nonzero') with retry policy ('A 5xx or unanswered mutation is sent once with linear-http: write=unconfirmed: read its result before resending'). The destructive/batch cap at 3 does not apply since bulk/complete workflows do carry validation and fail-closed refusals. It is not level 5 because several multi-step processes (the Done-when/complete rules, attachment resolution, shared-label change coordination) are rendered as dense conditional prose rather than ordered steps or checklists, making their sequence hard to follow.

Progressive Disclosure

Section structure is real and usable (Commands table, Reads, Team Target, Attachments), and references are prominently signaled as markdown links — but scored against the actual bundle, both referenced files are missing: 'patterns/workflow-actions.md' (cited twice, including a '#quota-holds' anchor) and 'README.md' ('§ Setup', cited twice) do not exist anywhere in the bundle, which only ships scripts/. Meanwhile content that belongs in separate reference files (Request journal internals, shared-label governance) is inlined. This matches level 3 ('some structure but could be better organized... content that should be separate is inline'). It is not level 2 because structure is far from minimal (clear headers, a command table, a working '--help' depth path), and not level 4 because the two primary detail references are dangling, breaking navigation for exactly the material pushed out of the overview.

Specificity

The description quotes 'read or write: issues, projects, cycles, milestones, initiatives, labels' — it names the domain (Linear) and six concrete resources, but the only actions are the generic umbrella verbs 'read or write' rather than concrete operations (create, update, search, archive). This matches the level-3 anchor 'names domain and 1-2 concrete actions, but not comprehensive' (the resource enumeration is specific, the action coverage is not). It is not level 4 because it does not list several specific actions, and not level 2 because the resource list is more concrete than a bare 'Processes PDF files' style example.

Completeness

The opening 'Load for any Linear read or write' is an explicit when-to-load clause (equivalent to 'Use when...'), and 'read or write: issues, projects, cycles, milestones, initiatives, labels' states what it covers — so both what and when are present, matching level 4 ('when' could be more explicit or specific). It is not level 5 because the 'what' lacks concrete action phrases and the 'when' offers no trigger-phrase variety beyond 'any Linear read or write'; it is not level 3 because the trigger guidance is explicit, not merely implied, so the missing-'Use when' cap does not apply.

Trigger Term Quality

Quotes 'Linear read or write: issues, projects, cycles, milestones, initiatives, labels' — 'Linear' plus the resource names (issues, projects, labels) are exactly the natural terms a user would say when needing this skill. It is not level 5 because common variations are missing: 'comments', 'attachments', 'teams', and generic synonyms like 'ticket' or 'task' are absent even though the skill handles them. It is above level 3 because coverage of the tool's own vocabulary is good, not just 'some relevant keywords'.

Distinctiveness Conflict Risk

The description leads with 'Linear' and uses Linear-specific vocabulary ('cycles', 'initiatives'), giving it a clear niche with minimal risk of triggering for an unrelated skill. This matches level 5 ('clear niche with distinct triggers; minimal conflict risk'). It is not level 4 because no closely related skill domain is plausibly confused: generic words like 'issues' and 'projects' are anchored to the named tool Linear throughout.