Skill Extractor

Extracts reusable knowledge from work sessions and saves it as a Claude Code skill.

When to Use

Just solved a non-obvious problem through investigation
Discovered a workaround that required trial-and-error
Found a debugging technique that would help in similar situations
Learned a project-specific pattern worth preserving
Fixed an error where the root cause wasn't immediately apparent

When NOT to Use

Simple documentation lookups (just bookmark the docs)
Trivial fixes (typos, obvious errors)
One-off project-specific configurations
Knowledge that's already well-documented elsewhere
Unverified solutions (wait until it actually works)

Finding Extraction Candidates

Use these prompts to identify knowledge worth extracting:

"What did I just learn that wasn't obvious before starting?"
"If I faced this exact problem again, what would I wish I knew?"
"What error message or symptom led me here, and what was the actual cause?"
"Is this pattern specific to this project, or would it help in similar projects?"
"What would I tell a colleague who hits this same issue?"

If you can't answer at least two of these with something non-trivial, it's probably not worth extracting.

Command

/skill-extractor [--project] [context hint]

Default: saves to ~/.claude/skills/[name]/SKILL.md
--project: saves to .claude/skills/[name]/SKILL.md
Context hint helps focus extraction (e.g., /skill-extractor the cyclic data DoS fix)

Extraction Process

Step 0: Check for Existing Skills

Before creating a new skill, search for existing ones that might cover the same ground:

# Check user skills
ls ~/.claude/skills/

# Check project skills
ls .claude/skills/

# Search by keyword
grep -r "keyword" ~/.claude/skills/ .claude/skills/ 2>/dev/null

If a related skill exists, consider updating it instead of creating a new one. See skill-lifecycle.md for guidance on when to update vs create.

Step 1: Identify the Learning

If $ARGUMENTS contains a context hint (e.g., "the cyclic data DoS fix"), use it to focus the extraction on that specific topic.

Analyze the conversation to identify:

What problem was solved?
What made the solution non-obvious?
What would someone need to know to solve this faster next time?
What are the exact trigger conditions (error messages, symptoms)?

Present a brief summary to the user:

I identified this potential skill:

**Problem:** [Brief description]
**Key insight:** [What made it non-obvious]
**Triggers:** [Error messages or symptoms]

Step 2: Quality Assessment

Evaluate the candidate skill against these criteria:

Criterion	Pass?	Evidence
Reusable - Helps future tasks, not just this instance		[Why]
Non-trivial - Required discovery, not docs lookup		[Why]
Verified - Solution actually worked		[Evidence]
Specific triggers - Exact error messages or scenarios		[What they are]
Explains WHY - Trade-offs and judgment, not just steps		[How]
Value-add - Teaches judgment, not just facts Claude could look up		[How]

Present assessment to user and ask: "Proceed with extraction? [yes/no]"

The user decides whether to proceed regardless of how many criteria pass. Respect their judgment - if they say yes, extract; if no, skip.

Step 3: Gather Details

Ask the user:

Skill name - Suggest a kebab-case name based on context, let them override
Scope - User-level (default) or project-level (--project)

Step 4: Optional Research

If the topic involves a specific library or framework:

Use web search to find current best practices
Use Context7 MCP (if available) for official documentation
Include relevant sources in the References section

Skip research for:

Project-specific internal patterns
Generic programming concepts
Time-sensitive extractions

Step 5: Generate the Skill

Use the template from skill-template.md.

Quality standards: Follow quality-guide.md to ensure the skill provides lasting value. Key points:

Behavioral guidance over reference dumps
Explain WHY, not just WHAT
Specific triggers that compete well against other skills

Step 6: Validate Before Saving

Run through the validation checklist in skill-template.md. If validation fails, fix the issues before saving.

Step 7: Save the Skill

Create the directory and save:

User-level: ~/.claude/skills/[name]/SKILL.md
Project-level: .claude/skills/[name]/SKILL.md

Report success:

Skill saved to: [path]

The skill will be available in future sessions when the context matches:
"[first line of description]"

Memory Consolidation

When extracting, consider how the new knowledge relates to existing skills:

Combine or separate?

Combine if the new knowledge is a variation or edge case of an existing skill
Separate if it has distinct trigger conditions or solves a fundamentally different problem
When in doubt, start separate - you can always merge later

Update vs create:

Update an existing skill when you've discovered additional edge cases, better solutions, or corrections
Create a new skill when the knowledge has different trigger conditions, even if the domain is related

Cross-referencing:

If skills are related but separate, add a "See also" section linking them
Example: A skill for "debugging connection pool exhaustion" might link to "serverless cold start optimization"

Skill Lifecycle

Skills aren't permanent. See skill-lifecycle.md for guidance on:

Updating skills with new discoveries
Deprecating skills when tools or patterns change
Archiving skills that are no longer relevant

Rationalizations to Reject

If you catch yourself thinking any of these, do NOT extract:

"This might be useful someday" - Only extract verified, reusable knowledge
"Let me just save everything" - Quality over quantity
"The user didn't confirm but it seems valuable" - Always get explicit confirmation
"I'll skip the 'When NOT to Use' section" - It's mandatory for good skills
"The description can be vague" - Specific triggers are essential for discovery

Example Extraction

Scenario: User discovered that an AST visitor crashes with RecursionError when analyzing serialized files containing cyclic references (e.g., a list that contains itself).

Identified learning:

Cyclic data structures create cyclic ASTs
Visitor pattern without cycle tracking causes infinite recursion
Need to track visited nodes or enforce depth limits

Generated skill name: cyclic-ast-visitor-hardening

Key sections:

When to Use: "RecursionError in AST visitor", "analyzing untrusted serialized input"
When NOT to Use: "Recursion from deeply nested (but acyclic) structures"
Problem: Visitor doesn't track visited nodes, enters infinite loop on cycles
Solution: Add visited: set parameter, check before recursing
Verification: Cyclic test case completes without RecursionError