There's a growing problem in AI tooling that nobody's talking about.
Anthropic's Claude Code shipped Skills — markdown files that define AI behavior. Instructions, conditionals, logic flow, all written in English. A SKILL.md is literally a program in human language.
This was a genuine paradigm shift. But there's a catch.
The Duplication Problem
Skills are getting copied everywhere. People take a SKILL.md from one repository, paste it into another, change two lines, and call it their own. Skill marketplaces are filling up with near-identical copies. There's no extension mechanism. No way to build on someone else's work without forking it.
Sound familiar? This is exactly what happened before object-oriented programming solved inheritance. Developers copied entire functions, changed a few lines, maintained separate copies that diverged over time.
We solved this in OOP decades ago. It's time to solve it for AI skills.
The Standard: Extensible Skills
I'm proposing a standard for how AI skills should be extended. The core idea comes from the SOLID Open/Closed Principle: "Open for extension, closed for modification."
SKILL.md is the base class. Stable. Tested. Version-controlled by the original author. You don't copy it. You don't fork it. You don't maintain your own version.
skill-memories/*.md are YOUR extensions. Like subclass overrides. Your team's conventions, your project's patterns, your rules. They sit in .claude/skill-memories/ and Claude reads them at runtime alongside the original skill.
Your rules override defaults. The original skill keeps getting updates from its author. You never have merge conflicts. This is inheritance for human-language programs.
Progressive Disclosure: Not Just Text
Here's where it gets powerful. Skill memories aren't just preference files. They support three levels of progressive disclosure:
Level 1 — Simple rules (text)
### Form Handling
- Use React Hook Form for all forms
- Combine with Zod validation schemas
- Never use plain useState for form state
Level 2 — Conditional logic (branching)
### Component Generation
When generating React components:
1. Check design system first (src/components/ui/)
2. If component exists → import it, don't recreate
3. If logic exceeds 50 lines → extract to custom hooks
When user mentions "admin" or "dashboard":
- Add role-based access control checks
- Include audit logging
Level 3 — Reference external scripts and tools
### Validation Pipeline
Before completing any component:
1. Run `scripts/validate-design-tokens.sh` to check token compliance
2. Execute `npx chromatic --exit-zero-on-changes` for visual regression
3. If validation fails, fix and re-run before proceeding
Level 3 is huge. Your skill memory can reference scripts, tools, and pipelines. The AI executes them as part of its workflow. This is progressive disclosure applied to AI behavior — from simple text rules to full automation.
What This Looks Like in Practice
Day 1. You ask Claude to generate a login form. It produces useState with inline styles. Wrong for your codebase.
You correct it: "Use React Hook Form with Zod. Never use inline styles. Tailwind only."
SpecWeave's Reflect system captures that correction automatically and saves it to .claude/skill-memories/frontend.md.
Day 8. Different session. "Generate a signup form." Claude reads the skill memory. React Hook Form. Zod. Tailwind. No reminder needed. You programmed the AI in English. Once. Permanently.
Why Marketplaces Need an "Extensible" Tag
As AI skill marketplaces grow, consumers need to know: can I extend this skill, or am I locked into copying it?
I propose a simple standard:
- Extensible — supports skill-memories. Install it, extend it, receive updates.
- Non-extensible — take it as-is, or fork it and maintain your own copy.
Every skill marketplace should adopt this distinction. Extensible skills are composable, maintainable, and respectful of the original author's work. Non-extensible skills create duplication debt.
The OOP Analogy
For developers who think in OOP, the mapping is direct:
| OOP Concept | Extensible Skills |
|---|---|
| Base class | SKILL.md (core program) |
| Subclass override | skill-memories/*.md (your extensions) |
| Open extension | No controlled extension points — user can add or override anything (convention-based, not enforced) |
| Runtime polymorphism | Claude reads both and merges at runtime |
| Don't copy the class | Don't fork the skill |
| Extend the class | Write skill-memories |
This isn't a loose metaphor. It's a precise architectural pattern applied to programs written in human language.
The Comparison That Matters
Where every major AI coding tool stands today:
Claude Code — open programs. Readable. Extensible via skill-memories. Version-controlled in Git. This is a platform.
ChatGPT — custom instructions per conversation. Useful, but no version control, no composability, no extension mechanism. A preference, not a program.
GitHub Copilot — black box. No visibility into reasoning. Limited customization of behavior.
Cursor — proprietary with good UX. Behavior logic is locked. You use what they ship.
Claude Code and ChatGPT lead the market. But only one supports true extensibility today. The rest require copying.
A Call to the Industry
I encourage every skill author, every marketplace, and every AI tool builder to adopt extensible skills:
- Skill authors: Make your skills extensible. Users can add their own rules on top without touching your code.
- Marketplaces: Add an "extensible" tag. Let consumers filter by extensibility.
- AI tool builders: Support a skill-memories pattern. Let users extend without forking.
Anthropic built the foundation with Claude Code Skills. SpecWeave proposes the extension standard. I hope Anthropic, OpenAI, and the broader community will adopt this pattern — or improve on it. The standard is open.
Get Started
SpecWeave is open source under the MIT license. 68+ extensible skills included.
Repository: github.com/anton-abyzov/specweave
Documentation: spec-weave.com
The Extensible Skills standard: spec-weave.com/docs/guides/extensible-skills
Discord: discord.gg/UYg4BGJ65V
Stop copying skills. Start extending them.
Top comments (3)
The OOP analogy is interesting but I think the reality is messier than classical inheritance. In practice, the "merge at runtime" step is where things get tricky. When Claude reads a base SKILL.md and your skill-memories override, there's no guaranteed resolution order the way a compiler handles method dispatch. You're relying on the model to figure out which instruction wins when they conflict.
I've been testing this with .cursorrules files (similar concept, different tool) and found that rule ordering matters more than most people realize. First-loaded rules tend to take priority over later ones, and the model doesn't always pick the "most specific" override the way a subclass would. It's more like CSS specificity than Java inheritance.
That said, the core insight is right: copying entire rule sets and maintaining divergent forks is unsustainable. The progressive disclosure levels are a good framework. Level 3 especially, having the AI execute validation scripts as part of its workflow, is where the real leverage is.
Great points, Ned. The CSS specificity analogy is actually closer to reality than classical inheritance -- you're right that there's no compiler-enforced dispatch here. In SpecWeave's implementation, skill-memories are loaded after the base SKILL.md, and we explicitly document that user overrides take precedence. But you're correct that the model is ultimately doing the resolution, not a deterministic runtime.
The .cursorrules observation is spot-on too. We've seen the same ordering sensitivity, which is why SpecWeave structures skill-memories with clear section headers that signal intent (e.g.,
## Override: Testing Framework) rather than just dumping rules in sequence.Agreed on Level 3 being the highest-leverage piece. Validation scripts give you a deterministic check that catches conflicts the model might miss -- it's the safety net that makes the "messy" resolution order tolerable in practice.
i've noticed that clear structural markers help more than just relying on the model to figure out ordering on its own. i ended up doing something similar with .mdc section headers. the validation scripts on top is where i'd invest the most effort though, because at least that layer is deterministic even when the model's resolution isn't