Extracting Methodology Into Skills
Converts descriptions of professional expertise into structured Claude Code agent skill files with proper YAML frontmatter, workflows, and examples. Use when a user describes someone's methodology, expertise, or process and wants it packaged as a reusable skill, or when asked to "create a skill" from a description of how an expert works.
Given raw input describing expertise (a bio, a transcript, a set of habits, or a vague description), produce a single skill file:
YAML--- name: reviewing-pull-requests description: Reviews pull requests for correctness, style, and maintainability risk. Use when a user requests a code review, asks "does this PR look good", or submits a diff for feedback. ---
...
No preamble, no meta-commentary — output the skill file directly.
Progress:
- Step 1: Identify the core recurring task in the description (the verb + object)
- Step 2: Derive the gerund-form name (kebab-case, ≤64 chars)
- Step 3: Write third-person description with explicit trigger phrases (≤1024 chars)
- Step 4: Extract the actual methodology — steps, heuristics, decision rules the expert uses (not generic advice)
- Step 5: Build Quick Start with a concrete, runnable/actionable example
- Step 6: Build Workflow as an ordered checklist reflecting how the expert actually works
- Step 7: Write 2+ concrete Example input/output pairs
- Step 8: List Best Practices specific to this domain (not generic "be careful")
- Step 9: List Common Pitfalls — specific failure modes, not truisms
- Step 10: If input is gibberish/too short/not real expertise, emit a minimal placeholder skill instead of asking questions
Example 1: Input: "A description of someone who is an expert at extracting professional methodology and packaging it into Claude Code agent skill format, with rules about YAML frontmatter, structure, and key principles like conciseness and specificity."
Output: A skill file named extracting-methodology-into-skills (this file) — demonstrating the process is self-applicable: the same rules used to build other skills were used to build this one, sourced entirely from the system instructions of the conversation.
Example 2: Input: "gibberish asdkjf 123 ???"
Output:
YAML--- name: handling-unclear-input description: Provides a minimal placeholder response when input is gibberish, too short, or doesn't describe real expertise. Use when a request lacks enough substance to extract a methodology from. ---
Acknowledge the input can't be parsed into expertise, and output a minimal placeholder skill with a generic name, description, and a single "Workflow" step noting more detail is needed.
- Mine the entire context (not just the last message) for methodology signals — rules, constraints, and examples given earlier often ARE the methodology.
- Prefer skills that are self-consistent: if instructions describe a process, apply that same process to generate the output.
- Keep frontmatter description trigger-oriented — imagine another Claude instance deciding whether to invoke this skill from a one-line description alone.
- Default to one file; only mention splitting into multiple files if the extracted methodology genuinely exceeds ~500 lines.
- When the source material already contains structural rules (headers required, ordering, formatting constraints), treat those as hard requirements, not suggestions.
- Writing the description in first or second person ("I extract..." / "You can use this to...") instead of third person.
- Omitting concrete trigger phrases from the description, making the skill undiscoverable.
- Padding sections with generic advice ("be thorough", "double-check your work") instead of domain-specific heuristics.
- Asking the user clarifying questions when input is unclear — always emit a placeholder skill instead.
- Exceeding length limits on
name(64 chars) ordescription(1024 chars) in frontmatter.