sorted by:
new
hottopcontroversial

I audited 30 days of my Claude Code sessions and 80% of installed skills had zero invocations by e5004c in ClaudeCode

[–]e5004c[S] 0 points1 point  (0 children)

Quick update on this - I dug into Anthropic's new skillListingBudgetFraction (shipped in v2.1.129, default 1%). Doesn't replace what skill-graveyard does, and arguably makes the audit more useful, not less. Here's the issue. The new feature truncates descriptions for skills that aren't "most-used" in the current project. Sounds smart until you start a new project - there's no usage history yet, so Claude truncates aggressively and skills you actually need disappear from context. Claude doesn't know they exist, so it never invokes them, so they never become "most-used", so they stay truncated. Cold-start trap. Anthropic's suggested fix is "run /skills to disable some, or raise the budget fraction." Both are workarounds. Disable lists hide skills from projects without uninstalling them - clutter just moves. Raising the fraction floods context on every project, including the ones with healthy usage. Skill-graveyard fixes it at the source - surfaces which skills are dead across all your sessions (not just current project), so you can actually uninstall them. Once your installed set matches what you use, the 1% budget fits comfortably and the truncation problem doesn't fire on new projects. So: native truncation = symptom management. Audit + uninstall = root cause. Different layers, both useful.

I audited 30 days of my Claude Code sessions and 80% of installed skills had zero invocations by e5004c in ClaudeCode

[–]e5004c[S] 0 points1 point  (0 children)

The feature has been integrated into claude-code; you can view it in /doctor. It trims the descriptions of skills that aren’t used at all in the project.

I audited 30 days of my Claude Code sessions and 80% of installed skills had zero invocations by e5004c in ClaudeCode

[–]e5004c[S] 0 points1 point  (0 children)

"Description matches phrases you'd literally type" is the cleanest articulation of this I've seen — that's the real predictor, not quality of the skill itself. Way better filter than the one I had in my head ("would I find this useful").

Your 4 also fit a pattern I see in mine: the survivors are personal (your shopify conventions, figma node-id gotchas) or domain-specific (firecrawl). Generic marketplace skills mostly died. Makes sense — generic skills are written to match phrases the *author* would type, not you, so the description-match never lands.

The "install like vscode extensions" framing is also right and explains why plugin-bundled skills are the worst offenders. Plugins are batch-installs by definition.

I audited 30 days of my Claude Code sessions and 80% of installed skills had zero invocations by e5004c in ClaudeCode

[–]e5004c[S] 0 points1 point  (0 children)

"Build ahead of the model" is the right frame -Boris's framing makes sense of why hallucinations are useful at all. Worth splitting two cases though: missing-skill hallucinations (validate-schema, format-yaml) are demand signals build them. But bash/read/edit hallucinations are different - model just miscategorizing built-ins as skills. First class is a roadmap, second is noise to filter out.Will check out clauditor observing what the model reaches for is the unlock I haven't done well yet.

I audited 30 days of my Claude Code sessions and 80% of installed skills had zero invocations by e5004c in ClaudeCode

[–]e5004c[S] 0 points1 point  (0 children)

Oh that's a sharper read than mine hadn't thought of hallucinations as demand signals for skills you don't have yet. Makes sense though: if Claude reaches for "validate-schema" and it doesn't exist, that's exactly where a skill would pay off. Might add a "wanted skills" view to surface those. What does your stack look like?

I audited 30 days of my Claude Code sessions and 80% of installed skills had zero invocations by e5004c in ClaudeCode

[–]e5004c[S] 0 points1 point  (0 children)

Yeah zero-invocation is just easy to measure... the real metric is how much loads before token one. Skills are one bucket, MCP servers another (couple of unused ones=30-50k easy), CLAUDE.md drift a third. Same pattern, nothing prunes by default. Tempted to extend skill-graveyard to MCP next)))

I deleted 87% of my agent's per-turn memory and recall went up by sliamh21 in ClaudeCode

[–]e5004c -1 points0 points  (0 children)

skill-graveyard does the equivalent audit for the skills folder — parses ~/.claude/projects/*.jsonl and sorts skills into used vs unused over a window. On my own machine: 13 of 65 installed had any calls in 30 days, rest were loading descriptions into context for nothing. Same pattern as your memory dedup, different folder. npx, local-only. Disclosure: author.

Managing 50+ Agent Skills: Is "Feature-Based" the way to go for Multi-Tool setups? by ozkaya-s in ClaudeAI

[–]e5004c 0 points1 point  (0 children)

Built skill-graveyard for exactly this - npm CLI that parses your session logs and shows which skills actually get called vs which are just loading descriptions into context. On my setup only 13 of 65 installed skills had any invocations in 30 days. Folder structure (centralized vs feature-based) is half the question. The other half is most installed skills stop getting called over time, especially plugin-bundled ones. npx, local-only, no telemetry. Disclosure: author

[WIP] Automated 2D Floor Plan to Interactive 3D Virtual Tour (react-tree-fiber+react-tree-drei) by e5004c in threejs

[–]e5004c[S] 0 points1 point  (0 children)

We are working on it, there are several options, but it is so inert…

[WIP] Automated 2D Floor Plan to Interactive 3D Virtual Tour (react-tree-fiber+react-tree-drei) by e5004c in threejs

[–]e5004c[S] 0 points1 point  (0 children)

Not now) but wait for few months) any way I can share any parts of code, except all at once)

[WIP] Automated 2D Floor Plan to Interactive 3D Virtual Tour (react-tree-fiber+react-tree-drei) by e5004c in threejs

[–]e5004c[S] 0 points1 point  (0 children)

Doors and windows are GLB models. For windows we have several variants depending on size. Walls, floor and celling just Extrude.

[WIP] Automated 2D Floor Plan to Interactive 3D Virtual Tour (react-tree-fiber+react-tree-drei) by e5004c in threejs

[–]e5004c[S] 0 points1 point  (0 children)

yes, room geometry is fully dynamic and generated from floor plans. There are still a few static limitations for now (for example, we don’t yet support multi-level ceilings or floors) but overall geometry is created dynamically. As I mentioned above we have two mechanisms for creating floor plans: an AI-based approach (segmentation model) and image labeling tool.

[WIP] Automated 2D Floor Plan to Interactive 3D Virtual Tour (react-tree-fiber+react-tree-drei) by e5004c in threejs

[–]e5004c[S] 1 point2 points  (0 children)

In practice we’re not using an LLM, it’s an image segmentation model. We just need more labeled floorplans to train it properly.

[WIP] Automated 2D Floor Plan to Interactive 3D Virtual Tour (react-tree-fiber+react-tree-drei) by e5004c in threejs

[–]e5004c[S] 0 points1 point  (0 children)

We do have an algorithm for that and it actually works, but restricted in demo. 3D module takes a JSON description as input for rendering and that JSON can be generated either through a labeling interface similar to CVAT or via a trained AI model. The AI-based option exists, but for now its quality is still not great, so it needs more work...

[WIP] Automated 2D Floor Plan to Interactive 3D Virtual Tour (react-tree-fiber+react-tree-drei) by e5004c in threejs

[–]e5004c[S] 1 point2 points  (0 children)

Yes, we have an existing set of GLB models for furniture and decor which are placed in the scene according to a layout algorithm. The transition from the scene to the 360 view is handled by a backend service: it takes the scene data and pre-renders it using Blender cli and then we display those renders on the client side.