DEV Community

Shimo
Shimo

Posted on • Originally published at zenn.dev

Tracking Skill Origins in Claude Code — How I Classified 79 Skills with origin Metadata

#claudecode #ai #devtools #cli

I bulk-installed 27 skills from ECC (Everything Claude Code), added some I found on GitHub, accumulated auto-extracted ones from /learn, and wrote my own. Before I knew it, I had 79. "Where did this skill come from?" — I couldn't tell.

ECC is a community repository that bundles skills and configurations for Claude Code.

Why This Is a Problem

When you try to audit your skills by running ls ~/.claude/skills/, you see this:

backend-patterns/
coding-standards/
continuous-learning/
iterative-retrieval/
myai-lab-patterns/
nutrient-document-processing/
search-first/
strategic-compact/
...
Enter fullscreen mode Exit fullscreen mode

Which ones did you write? Which came from ECC? Which are community-made? Opening the files reveals only name and description — no provenance information.

This causes real problems in practice:

  • Update decisions: When ECC releases an update, you don't know which skills to replace
  • Deletion decisions: You want to remove unused skills, but the criteria differ between self-made and external ones
  • Sharing: When handing skills to teammates, you can't verify the license or source

Solution: origin Metadata

I created a rule to add one line of provenance at the top of each skill file.

For files with YAML frontmatter, add it as a field:

---
name: coding-standards
description: "Universal coding standards..."
origin: ECC
---
Enter fullscreen mode Exit fullscreen mode

For files without frontmatter, add it as an HTML comment:

<!-- origin: original -->
# My Custom Skill
Enter fullscreen mode Exit fullscreen mode

Origin Categories

origin value Meaning Example
original Self-created search-first
ECC Installed from Everything Claude Code coding-standards
{org/repo} Specific external repository PSPDFKit-labs/nutrient-agent-skill
auto-extracted Auto-extracted by continuous-learning learned/*.md
skill-create Auto-generated from git history myai-lab-patterns

What I Actually Did

I classified and tagged 66 global skills and 13 project-level skills.

The Matching Process

  1. Identifying ECC skills: The configure-ecc/SKILL.md file contains a list of all 27 skills. I cross-referenced against this to confirm ECC origins
  2. Identifying external repositories: For skills with no frontmatter clues, I checked file footers and READMEs. nutrient-document-processing had the original repository URL at the bottom of the file
  3. Classifying self-made and auto-generated: Files under learned/ got auto-extracted, those generated by /skill-create got skill-create, and the rest were original

Breakdown 

Skills by origin (79 total):
  ECC             27  — exact match with configure-ecc list
  original        22  — self-made (rules, skills, agents)
  auto-extracted  18  — generated by continuous-learning / /learn
  skill-create     6  — patterns extracted from git history
  external repos   6  — individually found and installed from GitHub
Enter fullscreen mode Exit fullscreen mode

The tagging itself was batch-processed with a Python script that detects YAML frontmatter presence and inserts origin in the appropriate format.

Operational Rules

I defined rules in ~/.claude/rules/common/skills.md so they're automatically applied across all projects:

  • When creating new skills: Always include origin
  • When installing external skills: Record the source repository name
  • auto-extracted: Automatically tagged on skills generated by continuous-learning in learned/
  • During audits: Use origin as the basis for update checks and deletion decisions

The Underlying Issue

This problem can be solved with personal workflows, but it should really be handled at the ecosystem level.

npm packages have package.json with clear provenance, versioning, and licensing. Claude Code skills have no equivalent standard yet. With only name and description in the frontmatter, management breaks down as skills proliferate.

If origin, version, and license became standard frontmatter metadata, this problem would disappear entirely.

Filing Issues Upstream

Rather than keeping this as a personal workaround, I proposed improvements upstream:

I submitted to ECC first since the change is small and easier to accept, then linked it as a reference in the Anthropic issue. The goal is to turn a personal workaround into an ecosystem-wide improvement.

Summary

  • Claude Code skills don't record their provenance, making management impossible as numbers grow
  • An origin metadata field in frontmatter solves this
  • Existing skills can be classified by cross-referencing the ECC repository's installer
  • Long-term, a standard metadata specification for skills is needed
  • Issues have been filed with both ECC and Anthropic

Run ls ~/.claude/skills/ — if even one result makes you think "what's this?", it's time to add origin tags.

Top comments (0)