Extracting Skills From Documents
Given a document (e.g., a PDF on negotiation tactics, a markdown file of book notes on decision-making), run through six steps: skim it, analyze its structure, extract its components, synthesize actionable steps, construct the skill file, then validate it against a quality rubric.
Skill Creation Workflow
- [ ] Step 1: Inspectional reading (skim, classify, assess skill-worthiness)
- [ ] Step 2: Structural analysis (unity, parts, problems solved)
- [ ] Step 3: Component extraction (terms, propositions, arguments, solutions)
- [ ] Step 4: Synthesis (completeness check, actionable transformation, triggers)
- [ ] Step 5: Skill construction (write SKILL.md + resources)
- [ ] Step 6: Validation (score against rubric, refine)
Step 1: Inspectional Reading
Skim the whole document before going deep:
- Read title, headers, table of contents, intro/conclusion, index if present
- Classify document type: theoretical (explains "what is") vs. practical (explains "how to")
- Assess skill-worthiness: does this contain a repeatable process, decision framework, or methodology — or is it just narrative/opinion with nothing actionable? If it's not skill-worthy, say so and stop.
Output: a one-paragraph summary of what the document is, its type, and whether it merits a skill.
Step 2: Structural Analysis
- State the unity: what single problem or goal does this document address? Write it as one sentence.
- Enumerate the parts: outline major sections and how they relate to the unity.
- Define the problems: what specific questions does the author answer in each part?
Step 3: Component Extraction
Go section by section and extract:
- Terms: key vocabulary/concepts the author defines specially
- Propositions: the author's key claims/assertions
- Arguments: how propositions are supported (evidence, reasoning chains)
- Solutions: concrete techniques, steps, frameworks, or decision rules offered
Prefer extracting verbatim techniques over paraphrasing — precision matters more than brevity here.
Step 4: Synthesis and Application
- Completeness check: do you have terms, propositions, arguments, AND solutions? If solutions are missing, the document may not convert to an actionable skill — flag this.
- Identify applications: what real tasks would this methodology help with?
- Transform to actions: rewrite extracted solutions as imperative steps ("Do X, then check Y") rather than descriptive claims ("X leads to Y").
- Define triggers: what user phrases or situations should invoke this skill?
Step 5: Skill Construction
- Decide complexity: single SKILL.md file, or SKILL.md + supporting resource files (templates, checklists, reference tables)?
- Write YAML frontmatter (gerund name, third-person description with triggers)
- Structure body: Quick Start → Workflow → Examples → Best Practices → Common Pitfalls
- If the source has reusable templates/checklists, extract them into separate files and reference them; don't inline everything into SKILL.md if it pushes past ~500 lines.
Step 6: Validation and Refinement
Score the drafted skill against these criteria (1–5 each, threshold ≥3.5 average):
- Actionability: can someone follow this without re-reading the source document?
- Specificity: concrete steps/examples vs. vague abstractions?
- Trigger clarity: will Claude correctly invoke this skill when relevant?
- Completeness: does it cover the source's core methodology, not just fragments?
- Concision: is it as short as possible while remaining usable?
If below threshold, identify the weakest criterion and revise that section specifically.
Example 1:
Input: A PDF titled "The Eisenhower Decision Matrix" explaining urgent/important quadrants with examples.
Output: A skill named prioritizing-tasks-eisenhower-matrix with a Quick Start showing the 2x2 grid, a Workflow for classifying tasks into quadrants, and Examples of real task classifications.
Example 2: Input: A memoir chapter with anecdotes about a CEO's career, no repeatable process. Output: Assessment at Step 1 states the document is narrative, not methodological — no skill created, explain why.
- Always do Step 1 before deciding whether to proceed — don't assume every document deserves a skill.
- Preserve the source's specific terminology in extracted terms; renaming concepts loses fidelity.
- When extracting solutions (Step 3), separate "always do this" (rules) from "consider this" (heuristics) — they belong in different parts of the final skill (Workflow vs. Best Practices).
- Keep the final skill decoupled from the source document — it should work for someone who never read the original.
- Skipping the completeness check (Step 4) and building a skill from theory alone, with no actionable steps.
- Copying the document's structure (chapters) instead of restructuring into skill format (Quick Start/Workflow/Examples).
- Writing descriptions in first or second person instead of third person with explicit triggers.
- Producing an overlong skill file when a shorter one with linked resource files would serve better.