Use when a tricky bug, non-obvious workaround, hidden gotcha, or undocumented behavior took real debugging effort to discover and should be captured as a reusable learned skill.
Scanned 9/6/2026
Install to Claude Code
npx -y skills add yeaight7/agent-powerups --skill hard-won-skill-extractor --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Hard Won Skill Extractor?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/yeaight7-hard-won-skill-extractor-agent-powerups)More formats (shields.io, HTML) on the badges page.
---
name: hard-won-skill-extractor
description: Use when a tricky bug, non-obvious workaround, hidden gotcha, or undocumented behavior took real debugging effort to discover and should be captured as a reusable learned skill.
---
# Hard-Won Skill Extractor
This skill serves to document how to manually extract a useful learned skill into a reusable markdown file.
## Core Principle
Reusable skills are not code snippets to copy-paste, but **principles and decision-making heuristics** that teach an agent HOW TO THINK about a class of problems.
**The difference:**
- BAD (mimicking): "When you see ConnectionResetError, add this try/except block"
- GOOD (reusable skill): "In async network code, any I/O operation can fail independently due to client/server lifecycle mismatches. The principle: wrap each I/O operation separately, because failure between operations is the common case, not the exception."
## Quality Gate
Before extracting a skill manually, ALL three must be true:
- "Could someone Google this in 5 minutes?" → NO
- "Is this specific to THIS codebase?" → YES
- "Did this take real debugging effort to discover?" → YES
## Recognition Signals
Extract ONLY after:
- Solving a tricky bug that required deep investigation
- Discovering a non-obvious workaround specific to this codebase
- Finding a hidden gotcha that wastes time when forgotten
- Uncovering undocumented behavior that affects this project
## What Makes a USEFUL Skill
1. **Non-Googleable**: Something you couldn't easily find via search
2. **Context-Specific**: References actual files, error messages, or patterns from THIS codebase
3. **Actionable with Precision**: Tells you exactly WHAT to do and WHERE
4. **Hard-Won**: Took significant debugging effort to discover
## Anti-Patterns (DO NOT EXTRACT)
- Generic programming patterns (use documentation instead)
- Refactoring techniques (these are universal)
- Library usage examples (use library docs)
- Type definitions or boilerplate
- Anything a junior dev could Google in 5 minutes
## Manual Extraction Workflow
### Step 1: Gather Required Information
- **Problem Statement**: The SPECIFIC error, symptom, or confusion that occurred
- **Solution**: The EXACT fix, not general advice
- **Triggers**: Keywords that would appear when hitting this problem again
- **Scope**: Almost always Project-level unless it's a truly universal insight
### Step 2: Quality Validation
Reject skills that are:
- Too generic
- Easily Googleable
- Vague solutions
- Poor triggers
### Step 3: Save Location
- **Project-level**: `.skills/<skill-name>.md` - Default. Intended to be committed with the repo.
### Step 4: Promote if reusable
If the extracted idea should become a maintained, shareable skill instead of a project-local note, switch to `skill-authoring-guide` and turn it into a proper skill folder with frontmatter, support files, and validation.
### Required File Format
Every learned skill file MUST start with YAML frontmatter. Do **not** write plain markdown without frontmatter.
After the frontmatter, use a pure Markdown body with headings. Do not use XML-like tags such as `<Purpose>` or `<Workflow>` as default top-level structure; reserve XML-like delimiters for nested examples, quoted input, external documents, or machine-readable prompt payloads.
Minimum required frontmatter:
```yaml
---
name: <skill-name>
description: <one-line description>
triggers:
- <trigger-1>
- <trigger-2>
---
```
### Skill Body Template
```markdown
---
name: <skill-name>
description: <one-line description>
triggers:
- <trigger-1>
- <trigger-2>
---
# [Skill Name]
## The Insight
What is the underlying PRINCIPLE you discovered? Not the code, but the mental model.
## Why This Matters
What goes wrong if you don't know this? What symptom led you here?
## Recognition Pattern
How do you know when this skill applies? What are the signs?
## The Approach
The decision-making heuristic, not just code. How should an agent THINK about this?
## Example (Optional)
If code helps, show it - but as illustration of the principle, not copy-paste material.
```
## Verification
- [ ] All three quality-gate questions hold: not Googleable in 5 minutes, specific to this codebase, took real debugging effort
- [ ] The saved file starts with YAML frontmatter including name, description, and triggers
- [ ] The body teaches the principle and recognition pattern — not copy-paste code
- [ ] Anti-pattern content (generic patterns, library usage, boilerplate) was rejected, not extracted
- [ ] Truly reusable insights were promoted via skill-authoring-guide instead of staying project-local
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!