Composition notes

• Question: which packaged skills exist, and are they exercised? The register (source, bundle, installs, tools) against the exercise (invocations, last invoked); the gap between them — configured everywhere, never run — is the one attention state. Zero speaks: the idle skill ranks first, "never" under Last invoked is the row's only colored element (there is no Status column — exercised is Invocations > 0, already printed), and its expand names the plugin that put it there.
• Tier 3, said once: skills are modeled end-to-end and no adapter emits them (c59 §3). The note under the band states it; the cells do not apologize. The invocation-as-tool-call rule (tool.kind = 'skill') is the pipeline contract this page specifies, and the footer cross-foots skill invocations against those tools' calls.
• Verdict line from skillsVerdict(world) in derived/skills.ts — verdicts.skills sharpened with the band's denominators (installs carrying, exercised-of-n, the idle skill's plugin and people); tone is taken from verdicts.skills so the two never disagree. Fold-in candidate.
• Framing band = register vs exercise as four Phase1StatBlocks, three of them filter buttons (findings-regroup-v2 idiom): skills (reset, sources on the sub), exercised in 30d, configured-never-exercised (the attention device; at zero it reads "nothing configured and idle" in clear tone), installs carrying skills of the fleet's installs (a plain claim — there is no install-level filter on a skills table; the denominator shows how thin the footprint is).
• Table is the raw UxTableList family so ?id= can pre-open a row (inventory.vue pattern). Rows from skillRollup(world), ranked never-exercised first then invocations desc; sorters on every column; search rides the Skill header (name, description, source, plugin, people). Descriptions wrap to two lines under the name rather than truncating. The tool count is not a column (it reads "1" on every row) — it lives in the expand's header and its "Tools it exposes" row. Source column: a grey pill plus the plugin chip (→ Plugins) for bundled skills, the owner chip for a user skill, standalone · .claude/ for a project skill.
• Expand = four UxTableListExpandSections on a bare row: header (name, description, source, bundle, technologies, headline stats, and for the idle skill a plain-voice consequence), configured-on grid (agent chip → Agent detail, person, device, sessions·7d, last seen), bundle and tools (tool chips with ×calls · denied — c68 §2.10's pre-signals, fine on a ledger page; the plugin chip and its bundle siblings: sibling skills, slash commands as plain mono chips because commands have no home page, the bundled MCP server), and sessions on carrying installs.
• Sessions where it ran — not derivable, and not inferred. No session event records a skill invocation (the four event-bearing sessions have no tool_call of kind skill; one-line sessions carry only a count). Matching session summaries to skill names would be prompt-topic mining, the line c67 drew. The expand shows the 7-day sessions on installs carrying the skill, labelled as candidates; for the idle skill that yields the page's sharpest sentence — n sessions this week on installs carrying it, none invoked it.
• "view details →" is an honest stub: Phase 1 gives Surface pages listing + expand only, so the affordance links to the row's own ?id= address and says so.
• Derivation: every number traces to skillRollup / skillsBand / sessionsOnCarryingInstalls / bundleSiblings over instancesForSkill / peopleForSkill / recentSessions; nothing hand-typed. Where a project skill lives (which repo's .claude/) is not modeled on the skill — the expand shows the carrying installs' repos and says that is the nearest witness.
• Open: should a skill carry repoId (project source) and ownerPersonId (user source) in the world? Should the pipeline emit a skill_invocation event or is a tool call of kind skill enough for Session detail to render a skill beat? Both flagged for the world, neither decided here.