skill-extractor
- Repo stars 411
- Author updated Live
- Author repo skills-curated
- Domain
- Data
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @trailofbits · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-extractor
description: >- Extracts reusable knowledge from work sessions and saves it as a Claude Code skill. Use these…
category: data
runtime: no special runtime
---
# skill-extractor output preview
## PART A: Task fit
- Use case: >- Extracts reusable knowledge from work sessions and saves it as a Claude Code skill. Use these prompts to identify knowledge worth extracting: If you can't answer at least two of these with something non-trivial, it's probably not worth extracting. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to Use / When NOT to Use / Finding Extraction Candidates” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “>- Extracts reusable knowledge from work sessions and saves it as a Claude Code skill. Use these prompts to identify knowledge worth extracting: If you can't answer at least two of these with something non-trivial, it's probably not worth extracting. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “When to Use / When NOT to Use / Finding Extraction Candidates” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/skill-extractor`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “When to Use / When NOT to Use / Finding Extraction Candidates”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: skill-extractor
description: >- Extracts reusable knowledge from work sessions and saves it as a Claude Code skill. Use these…
category: data
source: trailofbits/skills-curated
---
# skill-extractor
## When to use
- >- Extracts reusable knowledge from work sessions and saves it as a Claude Code skill. Use these prompts to identify k…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to Use / When NOT to Use / Finding Extraction Candidates” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "skill-extractor" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to Use / When NOT to Use / Finding Extraction Candidates
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} 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: setparameter, check before recursing - Verification: Cyclic test case completes without RecursionError
Decide Fit First
Design Intent
How To Use It
Boundaries And Review