Dear Anthropic: Implement Persistent Skill Registry with Dewey Classification and Bidirectional Linking From: TABARC-Code - building sophisticated multi-skill systems Date: 30 April 2026 Status: Feature request with working proof of concept Scope: Claude.ai, Claude API, Claude Code
Claude's skill system is powerful but architecturally incomplete. Skills exist in isolation. There's no persistent way to classify them, link them bidirectionally, weight them semantically, or tell Claude which skills should work together for a given task.
This proposal requests three capabilities that would transform how users build and deploy skill ecosystems: Writable persistent skill metadata – A registry file Claude can read and update across conversations Standardised Dewey Decimal classification for skills (extending standard DDC to skill domains) Bidirectional linking protocol – If skill A calls skill B, skill B's registry entry automatically reflects that relationship Impact: Users with 50+ skills could reduce token waste by 30–40%, improve skill selection accuracy by measurable margins, and build genuinely self-improving skill systems.
The Problem I'm building an ecosystem of 79 skills across fiction writing, game design, worldbuilding, and creative systems.
Currently:
####Problem 1: Skills are isolated When I invoke master-drafting-orchestrator to write a scene, it calls: narrative-voice-engine pacing-time-engine prose-style-voice-engine dialogue-subtext-engine period-texture-engine thematic-engine suspense-horror-engine
But Claude has no persistent record that these seven skills form a coherent stack. If I ask for a "western novel," Claude doesn't know that this stack should filter to only the subset relevant to westerns (dropping period-texture-engine if the western is contemporary, weighting thematic-engine higher if the user cares about frontier mythology). That seems like a wasted potental
Each conversation, I start from zero knowledge about skill relationships.
Problem 2: No semantic weighting All skills are equal. But for say a "western novel" request, some skills are more relevant than others: character-psychology-engine – highly relevant (western archetypes matter) suspense-horror-engine – moderately relevant (tension in westerns is different from horror tension) period-texture-engine – conditional (relevant only if historical western, not contemporary) I've got no way to tell Claude "when the user says 'western,' prioritise character-psychology-engine and dialogue-subtext-engine, defer period-texture-engine unless confirmed historical."
Problem 3: Bidirectional linking is manual and fragile If i have the poetry writer In my prose-style-voice-engine, declare, write a series of sonnets:
Claude would then run the skill and al available skills, unless i manual tell it that x,y,z skills are useful.
If I later update a master-drafting-orchestrator skill to call a new skill, I have to manually go back to that new skill and add master-drafting-orchestrator to its called-by list. One human error breaks the chain. There's no automated reciprocation.This should be possible with Claude automation Skill lining.
Problem 4: Context-specific skill selection is guesswork When a user says "I want to write a novel," I invoke golden-age-author. But that skill then has to enumerate which sub-skills to call. This is hard-coded. There's no way for the system to discover that master-drafting-orchestrator, fiction-structure-engine, and character-psychology-engine are the relevant subset for a novel-length project (Yes i can make them sub skills but that dilutes the skill and skill set. I have found dedicated Skills and Sub skills work better, and even with the current hack of manual loinking works better, -and that this subset changes if the user specifies "cosmic horror novel" vs "literary fiction novel."
Problem 5: No skill performance history Skills don't know if they've been useful. When master-drafting-orchestrator calls thematic-engine, there's no feedback loop. If the user says "the theme felt forced," the system doesn't record that. Next conversation, it calls thematic-engine with the same weight. This is a failure and a waste of potential.
The Solution: Three Integrated Features Feature 1: Persistent Skill Metadata (Writable Storage)
What: Allow Claude to read and write to a skill registry file that persists across conversations. Current limitation: /mnt/skills/user/ is read-only. Claude can read skill files but can't update them. Any metadata I generate lives only in the current conversation. Requested change: Create a writable directory - e.g., /mnt/skills/registry/ - where Claude can maintain: Code datum Benefit: A Master Skill can audit, classify, and improve the registry every conversation. Improvements persist. This also provides a massive amount of potential data for claude through the reinforcement data skill improvement, and evolutionary neural skill linking that would in theory add to developmental ai constat improvement.
Feature 2: Dewey Decimal Classification for Skills What: Standardise skill classification using Dewey Decimal Classification (000–999), extended for skill domains. Example assignments from my ecosystem: Nil Why Dewey: Already established and a mature referencing binary system. Hierarchical (800s = all literature; 813 = American fiction; 813.X = specific subgenres) Standardised (anyone familiar with DDC understands the classification instantly) Scalable (room for 1000+ distinct skill categories without collision) Semantic proximity (skills with close Dewey numbers are conceptually related) Benefit: Instead of listing "call these 40 skills for a novel," the system says: "Call all skills in 813.X, weight 813.401 and 813.402 higher, include 813.403 conditionally." Feature 3: Bidirectional Linking Protocol What: Enforce reciprocal relationships in the registry. If A calls B, B's entry automatically updates to show "called-by A."
How it works Skill and Sub Skills: When Claude Code audits the skill registry, it detects relationships such as: “Novel-drafting-orchestrator calls prose-style-voice-engine.” The master registry updates automatically when a skill calls a sub-skill. The sub-skill adds the parent skill to its called-by field. If the relationship is removed, both entries update accordingly. The registry enforces reciprocity: if Skill A calls Skill B, Skill B must list Skill A in called-by. Chain validation is applied across all links (A > B > C > D). Each step must confirm both calls and called-by relationships. Reverse links (e.g. D > A) are also recorded and validated. The system prevents broken chains and removes the need for manual backlinking. The architecture is self-validating and consistent. Sub-skills include: prose-style-voice-engine, novel plotting and dialogue engine, and plot master. If plot master frequently calls novel plotting and dialogue engine, their connection is strengthened. The registry applies weighted or “heat-based” linking based on usage patterns. This allows Claude to prioritise stronger relationships and improve orchestration efficiency.
How It Works: Concrete Example Scenario: User says "Write me a western novel" Step 1: Master Skill reads the registry Step 2: Master Skill filters and weights Request: "western novel" Filter 1: 813.X skills (American fiction) > 47 candidates Filter 2: Intersection with 813.086 (westerns) > adds semantic weight Filter 3: User is writing, not diagnosing > exclude diagnostic skills Filter 4:User is Writing so list and review writing and sub writing skills,utilise and reinforce those skills that tie with writing, Filter 5: User hasn't specified historical vs contemporary > keep period-texture conditional
Result: 38 skills selected, with weighted priority order:
Step 3: Claude routes intelligently
Instead of calling all 47, it: Calls golden-age-author (orchestrator) > Which calls master-drafting-orchestrator (core generation) > Which calls top 8–12 weighted skills (not all 47) >Weighted by relevance (character-psychology-engine gets more pressure than a minor skill)
Step 4: Feedback loop
User says: "The character dynamics feel shallow."
So System records: "character-psychology-engine used for western novel, user found character work insufficient." Next western request: bump character-psychology-engine weight to 105. Technical Implementation > Storage Structure
Option A: JSON registry (structured) Json
Option B: Markdown registry (human-readable)
Markdown Recommendation: JSON for machine parsing, with Markdown export for human review. Persistence > Where it lives: /mnt/skills/registry/ (writable by Claude)
Versioning: Git-style with timestamps Code Access: Claude can read (every conversation, load current registry) Claude can write (update after audits, skill creation, feedback incorporation) User can download and review User can manually edit and re-upload if needed Master Skill Responsibilities
A new top-level skill (skill-registry-master) would: On every conversation start: Load the registry Validate bidirectional links Flag broken chains Check for orphaned skills When a new skill is created: Assign a Dewey number (20% user input, 80% system inference) Add it to the registry Identify partner skills (other skills it should work with) Update all calling skills' called-by lists
When a skill is invoked: Record the invocation Track performance (user satisfaction, token efficiency) Adjust weights based on feedback Weekly/monthly (async): Audit the entire registry Suggest skill consolidations (if three skills do nearly the same thing) Flag underperforming skills (rarely called, low satisfaction) Generate improvement reports
Benefits to Anthropic For Claude.ai users (consumer) Faster skill discovery – "I want to write a novel" > system auto-selects the 40 relevant skills instead of you guessing. Better results – Skills work together by design, not accident Less token waste – Call only needed skills, not all 79 Self-improving skills – Your skill ecosystem learns from every conversation For Claude API users (developer) Semantic routing – Instead of hard-coded if/else chains, use Dewey classification to route programmatically Skill marketplaces – Third-party skills could publish their Dewey numbers and partner declarations; users could mix and match Performance benchmarking – Track which skill combinations produce the best results across your user base Reduced hallucination – By explicitly routing to relevant skills, you reduce the chance Claude invents skills that don't exist
For Anthropic (business) Demonstrates skill maturity – Shows Claude's skill system is production-ready, not a toy Competitive advantage – No other LLM has bidirectional skill linking. This is genuinely novel architecture Reduces support burden – Users can self-diagnose skill problems ("master skill audit says prose-style-voice-engine has a broken reciprocation link") Data on skill effectiveness – The registry generates rich telemetry about which skill combinations work best for which tasks Implementation Checklist Massive business potential – Enables evolutionary, neural-style skill development, allowing the system to continuously refine itself through usage patterns. Ongoing AI expansion – Supports the growth of capabilities over time, as increasingly sophisticated skill relationships emerge. Continuous improvement loop – More developed, interconnected “neural-style” skills lead to constant performance gains and smarter orchestration.
Why Now Skill ecosystems are growing – Users like me are building 50–100+ skill systems. Without structure, they become unmaintainable.
Claude is capable – The model can understand Dewey classification, manage bidirectional links, and learn from feedback. This isn't theoretical; it's executable now. Competitive opportunity – No other LLM platform has this. Anthropic could own "the skill system that actually scales."
Proof of concept exists – I've manually built military-gothic-voice with explicit bidirectional contracts and data flow specs. It works. It's just maintenance-heavy. Automation would unlock the potential.
Questions & Concerns You Might Have and I can see Q: Won't this add significant latency? A: The registry is loaded once per conversation. Lookups are O(1) JSON/dict access. Negligible overhead. Q: What if the registry gets corrupted? A: Versioning solves this. Keep backups. If corrupted, rollback to the last validated version. Q: How do users opt in? A: The Master Skill is optional. Users without 50+ skills won't need it. Power users can enable it explicitly. Q: What about security? Can Claude edit arbitrary files? A: Scope it tightly. Claude can only edit /mnt/skills/registry/, nothing else. The registry is metadata, not code. Worst case: bad metadata just means suboptimal routing. Its a nice simple fix Q: This sounds like a lot of work. A: Yes. But it's a strategic investment that unlocks a whole category of power-user features. And it generates telemetry that helps Anthropic understand how Claude is actually used. And you could use Claude to implement it..
Closing The skill system is Anthropic's biggest architectural advantage over other LLMs. But it's currently bottom-up only - users build skills, skills call other skills, humans manually manage the graph. Make it top-down too. Give Claude the tools to understand the graph, classify it, validate it, and improve it. The payoff isn't marginal. It's the difference between "a collection of tools" and "an intelligent system that knows what it is and what it can do." Respectfully, A user who's spent 200+ hours building a skill ecosystem and knows exactly what's missing.
This proposal is written by someone who's built the thing manually. I know it works because I've proven it with military-gothic-voice and the Aria ecosystem. I'm asking Anthropic to build the infrastructure so I - and every other such user - don't have to do it by hand.
Honestly i see the skill system is your secret weapon. Please Automate it.