extract
by alirezarezvaniextract is a Skill Authoring utility that turns recurring fixes, workflows, or debugging patterns into a reusable SKILL.md with clear scope, triggers, workflow, examples, and optional references.
This skill scores 76/100, making it a solid listing candidate for directory users who want an agent workflow for turning recurring debugging or implementation patterns into reusable skills. It has enough operational substance in SKILL.md—usage syntax, qualification criteria, and a stepwise workflow—to reduce guesswork compared with a generic prompt, but users should know it is documentation-only and somewhat tied to a Claude memory convention.
- Clear activation path: the frontmatter explicitly says to use it for /si:extract or when packaging a recurring solution from memory into a skill.
- Provides concrete usage forms, including naming, custom output directory, and dry-run variants, which improves triggerability and agent execution.
- Defines extraction criteria such as recurring, non-obvious, broadly applicable, complex, or user-flagged patterns, helping an agent decide when the skill is appropriate.
- No support files, scripts, references, or README are included; everything depends on the SKILL.md instructions rather than executable automation or packaged examples.
- The workflow is tailored to a Claude/self-improving-agent memory layout, including a specific ~/.claude/projects memory path, which may limit portability without adaptation.
Overview of extract skill
What extract does
extract is a Skill Authoring utility for turning a recurring fix, workflow, debugging pattern, or hard-won project lesson into a reusable Claude skill. Instead of leaving useful knowledge buried in chat history or memory, the extract skill helps package it as a portable SKILL.md with a clear trigger, scope, workflow, examples, and optional supporting files.
Best fit for extract
Use extract when you have already solved something once or twice and want the agent to reuse that solution reliably later. It is especially useful for engineering teams, self-improving agent setups, and developers who maintain repeated project conventions, debugging recipes, migration steps, or tool-specific procedures. It is not meant for inventing a brand-new skill from a vague idea; it works best when the pattern has evidence behind it.
What makes this extract skill useful
The strongest part of extract is its decision logic: it asks whether a learning is recurring, non-obvious, broadly applicable, complex enough to forget, or explicitly user-requested. That prevents turning every note into a skill. The workflow also encourages checking Claude auto-memory before writing, so the resulting skill can be based on real past resolutions rather than a generic prompt template.
What to know before installing
This repository path contains a single SKILL.md and no bundled scripts, references, or helper assets. That makes the extract install lightweight, but it also means you should expect a prompt-driven authoring workflow rather than an automated generator with validation tooling. If you need linting, publishing automation, or multi-file scaffolding, you may need to add that around the skill yourself.
How to Use extract skill
extract install and repository reading path
Install with:
npx skills add alirezarezvani/claude-skills --skill extract
After install, read SKILL.md first; it is the primary implementation file and contains the command patterns, extraction criteria, and authoring workflow. There are no references/, resources/, rules/, or scripts/ folders in the current skill path, so do not look for hidden tooling. The important setup step is ensuring your agent can access the project context or memory entries that contain the pattern you want to extract.
Calling extract in practice
The intended command style is:
/si:extract <pattern description>
/si:extract <pattern> --name docker-m1-fixes
/si:extract <pattern> --output ./skills/
/si:extract <pattern> --dry-run
Use /si:extract when you want an interactive extraction. Add --name when the skill name is already obvious, --output when your project stores skills in a custom folder, and --dry-run when you want to review the proposed structure before files are created.
Turn a rough idea into a strong extract prompt
A weak prompt is:
/si:extract make a skill for Docker problems
A stronger prompt is:
/si:extract We repeatedly fix Docker build failures on Apple Silicon by pinning platform, rebuilding base images, clearing stale buildx cache, and checking native dependency images. This came up in two Node projects and one Python service. Create a reusable troubleshooting skill with decision steps and examples. --name docker-apple-silicon-debugging --dry-run
The stronger version gives extract the recurrence signal, context, platform, solution shape, and intended artifact. That helps the agent write a skill that triggers correctly instead of producing a broad Docker advice page.
Suggested extract usage workflow
Start by describing the solved problem, where it occurred, the symptoms, the actual fix, and what made the solution non-obvious. Let the skill check or reason from memory if available. Then review the proposed scope before accepting the output: a good extracted skill should have a narrow trigger, repeatable steps, known constraints, and examples that resemble future requests. If the first draft is too broad, ask the agent to split it into smaller skills or reduce it to the reusable part only.
extract skill FAQ
Is extract for Skill Authoring beginners?
Yes, if you already have a concrete pattern to package. The extract skill is beginner-friendly because it gives criteria for deciding whether something deserves a skill and a workflow for shaping SKILL.md. However, beginners should avoid extracting one-off fixes too early. Wait until the solution is likely to recur or is complex enough that forgetting the details would cost time.
How is extract different from an ordinary prompt?
An ordinary prompt can ask Claude to “write a skill,” but extract gives the agent a repeatable authoring process: identify the pattern, check for supporting memory, determine scope, and produce reusable skill content. The value is consistency. You are not just generating documentation; you are creating an installable behavior package that future agents can trigger from a clear description.
When should I not use extract?
Do not use extract for project-specific secrets, temporary workarounds, incomplete hypotheses, or procedures that depend on one private codebase with no reusable logic. Also avoid it when the answer is better as a short README note, shell alias, test, or script. A skill is most useful when the agent needs procedural judgment, not when a deterministic command would solve the problem.
Does extract create a complete multi-file skill package?
It can guide creation of a standalone skill, including SKILL.md, examples, and reference docs when needed, but the current repository evidence shows only the core skill file. Treat extract as an authoring workflow, not a full scaffolding framework. If your organization has required metadata, tests, or publishing steps, include those requirements in the prompt.
How to Improve extract skill
Give extract evidence, not just conclusions
The extract skill improves when the input includes the original failure mode, failed attempts, final fix, and recurrence evidence. For example, “we solved this in three repos after OAuth redirects broke behind a proxy” is more useful than “make an OAuth proxy skill.” Evidence helps the agent decide trigger conditions, warnings, and the boundary between reusable guidance and local implementation detail.
Control scope before accepting the skill
The most common failure mode is an extracted skill that is too broad: “Kubernetes debugging,” “frontend performance,” or “API design.” Ask extract to name the exact future moment when the skill should activate. Good scopes sound like “debug pnpm workspace dependency resolution after package moves” or “migrate GitHub Actions from Node 16 to Node 20.” Narrow scopes make future invocation more reliable.
Improve output with examples and anti-examples
Ask for at least one realistic usage example and one “do not use this when…” case. Examples teach the agent how to apply the skill; anti-examples prevent accidental activation. This is especially important for extract usage in shared skill libraries, where vague skills create noise and compete with more specific skills.
Iterate after the first extract draft
After the first output, review four things: trigger clarity, step order, missing constraints, and portability. If the draft assumes your current repository layout, ask for a portable version. If it omits verification, ask for checks that prove the fix worked. If it reads like a blog post, ask extract to rewrite it as operational instructions for an agent that must perform the task later.
