extract

---
name: extract
description: Use when the user asks to save, package, or reuse a recurring pattern, workaround, or debugging solution as a standalone skill, or references /si:extract.
category: Engineering
version: 1.0.0
tools: []
---

# Extract Skill from Pattern

Turn a recurring pattern, workaround, or debugging solution into a standalone, reusable skill definition that can be handed off in chat and reused across projects.

## When to Extract

A learning qualifies for extraction when ANY of these are true:

| Criterion | Signal |
|---|---|
| Recurring | Same issue across 2+ projects |
| Non-obvious | Required real debugging to discover |
| Broadly applicable | Not tied to one specific codebase |
| Complex solution | Multi-step fix that's easy to forget |
| User-flagged | "Save this as a skill", "I want to reuse this" |

## Workflow

### 1. Identify the pattern
Search the Knowledge Base for related entries using keywords from the pattern description. If matching entries exist, use them as source material. If not, work directly from the user's description.

### 2. Scope the skill
Ask at most 2 clarifying questions, only if unclear:
- What problem does this solve?
- Should it include code examples?

### 3. Name the skill
Naming rules:
- Lowercase, hyphens between words
- Descriptive but concise (2-4 words)
- Examples: `docker-m1-fixes`, `api-timeout-patterns`, `pnpm-workspace-setup`

Reserved fragments that must NOT appear in the name: `claude`, `anthropic`. For skills about Syntic Code itself, use the `cc-` prefix instead:
- `claude-code-settings` -> `cc-settings`
- `claude-code-maintenance` -> `cc-maintenance`
- `claude-mcp-tools` -> `cc-mcp-tools`
- `claude-plugin-development` -> `cc-plugin-development`

Before finalizing the name, check it against this list. If a reserved fragment is present, transform it (drop the fragment or replace the `claude*`/`anthropic*` prefix with `cc-`) and confirm the new name with the user.

### 4. Draft the skill definition
@mention a teammate to help draft the full skill content if it needs deeper research, or draft it directly. Return the finished skill in chat with this structure:

- **Frontmatter**: `name` and a one-line `description` ending in "Use when: <trigger conditions>."
- **Title + one-line summary** of what the skill solves.
- **Quick Reference**: a Problem/Solution table.
- **The Problem**: 2-3 sentences on what goes wrong and why it's non-obvious.
- **Solutions**: Option 1 (recommended, step-by-step with examples) and Option 2 (alternative, for when Option 1 doesn't apply).
- **Trade-offs**: a Pros/Cons table comparing the options.
- **Edge Cases**: a bulleted list of edge cases and how to handle each.

Keep any supporting examples or edge-case detail inline in the same response rather than as separate reference material — there is nothing to load later, so the definition must be self-contained.

### 5. Quality gates
Before returning the result, verify:
- Frontmatter has a valid `name` and `description`
- `name` follows the lowercase-hyphens format
- `name` contains no reserved fragments (`claude`/`anthropic`) — use `cc-` prefix instead
- Description includes "Use when:" trigger conditions
- Solutions are self-contained (no external context needed)
- Code examples are complete and usable as-is
- No project-specific hardcoded values (paths, URLs, credentials)
- No unnecessary dependencies

### 6. Report
Summarize what was produced: the skill name, the sections included, and the source of the pattern (e.g., "Source: Knowledge Base entries — retained, since the skill itself is meant to be portable while the memory stays project-specific").

## Examples

### Extracting a debugging pattern
Given: "Fix for Docker builds failing on Apple Silicon with platform mismatch." Produces a skill covering the platform mismatch error message, three solutions (build flag, Dockerfile change, docker-compose change), a trade-offs table, and a performance note about Rosetta 2 emulation.

### Extracting a workflow pattern
Given: "Always regenerate the TypeScript API client after modifying the OpenAPI spec." Produces a skill covering why manual regeneration is needed, the exact regeneration sequence, CI integration notes, and common failure modes.

## Tips

- Extract patterns that would save time in a *different* project.
- Keep skills focused — one problem per skill.
- Include the error messages people would actually search for.
- Test the skill by reading it without the original context — does it still make sense?