Kasetto knows what you installed. Each agent knows what it ran. Nothing on the\nmachine joins the two, so installed-and-forgotten assets accumulate silently -\nskills nobody has ever invoked, MCP servers loading tool definitions into every\nrequest for a server the user stopped using months ago.
\nThis skill closes that loop: read the lock, read each agent's local session\nstore, join them, and say plainly what is alive and what is dead.
\nTwo scripts, both standard-library Python 3, both offline.
\npython3 scripts/collect.py --out usage.json # scan + join\npython3 scripts/render.py usage.json --out usage.html\ncollect.py is the slow one on a cold cache (a few seconds for a large history)\nand near-instant afterwards - it caches per-file results in\n$XDG_CACHE_HOME/kasetto/usage-scan.json keyed on size and mtime, so a rerun\nonly touches files the agent appended to. Delete that file to force a full\nrescan.
Open the dashboard when it is written, then give the user the short version in\nthe terminal: how many assets are idle, the biggest surprises, and what you would\ncut. The HTML is the artifact; your reading of it is the value.
\ncollect.py reports a coverage block listing every agent it knows about and\nwhether it found a readable session store. Honour it.
An asset the user drives daily from an agent that has no provider looks\ncompletely dead in this report. If you present \"55 skills never used\" without\nsaying which agents that claim covers, and they act on it, they delete something\nthey rely on. That is the one way this skill can actively hurt someone.
\nSo:
\nstatus: absent agent is one the user actually uses, say so directly\nand treat the idle list as a shortlist to review rather than a cut listverified_format: false provider parsed a store whose layout has not been\nconfirmed against a real sample. A zero from it is weak evidence, not proofStart with insights - collect.py computes the findings worth acting on\nrather than leaving them to be read off a chart. Each carries a severity, a\ntitle already phrased as a claim, a detail explaining why it matters, and\nthe items it refers to. Lead your summary with these, in order; they are\nalready sorted by severity. Then use the rest of the JSON to answer follow-ups.
Severity is a deliberately narrow vocabulary, and it drives colour in the\ndashboard:
\nbad (red) - Concrete waste, meaning a source repo with nothing in use. This\nis the only thing red is spent on, because an unused skill is dormant, not\nbroken, and colouring it red would burn the strongest signal on the least\nurgent findingwarn (amber) - Act on it: idle MCP packs, coverage gaps, unverified formatsinfo (cyan) - Context: concentration, freshly installed assets, unmanaged\nfindsgood (green) - Nothing idleIdle skills are grey throughout. Keep that distinction when you talk about them:\n\"dormant\" and \"worth a look\", not \"bad\".
\nusage.json carries more than the dashboard shows. Worth reading directly when\nthe user asks something specific:
skills / mcps - Per asset: total, last_used, by_agent, days (a\ndate-keyed histogram), plus source and scope from the lock. Skills carry\nage and a fresh flag; MCP packs carry by_server and by_toolby_source - Per source repo, how many of its assets are live, fresh and idle.\nUsually the most useful view. Assets go idle in clusters, because a repo\ngets added for one skill and brings twelve. A wholly idle source is a single\nsource: block to delete rather than N rows to prune, so lead with this when\nrecommending cutsactivity - Daily invocation totals for skills and MCPs, which is what\nseparates \"used heavily last year\" from \"used steadily this week\"unmanaged - Names called locally that are not in the lock: installed by hand\nor shipped by the agent. A heavily used one is worth bringing under\nkasetto.yaml so it syncs everywherecounts - Headline numbers, with skills_idle and skills_fresh already\nseparatedAn MCP pack can merge several servers, so usage is counted per server and rolled\nup. A pack alive on one server and idle on another is worth calling out; that\ndetail is invisible in the pack-level total.
\nThe idle list is a starting point, not a verdict. Before suggesting a cut:
\ncollect.py already separates these into skills_fresh using a 7-day\nthreshold, and the dashboard holds them in their own section. Never move one\ninto a cut list because its count is zeroTo act on a decision, the existing CLI does it - kst remove edits\nkasetto.yaml in place and preserves comments and key order, then kst sync\nuninstalls the asset. Do not hand-edit the lock.
The provider list is a table at the top of scripts/collect.py. Adding one is a\nnew entry plus, sometimes, a reader. references/providers.md documents each\nknown agent's store, which are verified against real data, and which are\ninferred from documentation.
Two things to hold onto when you extend it:
\nMatch patterns, not schemas. Session formats churn - Goose moved JSONL to\nSQLite, OpenCode JSON to SQLite, Copilot CLI flat files to per-session\ndirectories. What did not move through any of those migrations is the tool-name\nstring. Matching mcp__<server>__<tool> survives a schema rewrite that would\nbreak a field-by-field parser. Resist the urge to \"properly\" parse these files.
Anchor on an invocation position. Session logs also record the tools\noffered each turn, as arrays of names repeated on every request. An early\nversion matched the bare mcp__x__y string anywhere and reported 38,743 calls\nfor a server with zero real invocations. Every pattern must require a key\nposition (\"name\": \"mcp__...\"), and any new provider needs a sanity check\nagainst an independent count before its numbers are trusted.
Skills and MCP servers only. Commands and instructions are deliberately out:\nslash commands in the logs are mostly agent built-ins rather than kasetto assets,\nand instructions are injected as context and never \"invoked\", so usage is\nundefined for them. If asked about those, explain why rather than guessing.
\nEverything stays local. The scripts read files and run kst list --json; nothing\nis uploaded, and the dashboard makes no network requests so it stays readable\noffline and safe to share.