Process Extraction

Process-to-Skill Workflow

Philosophy

Implicit procedural knowledge — the sequence of steps an operator or agent executes to accomplish something reliably — is the most perishable asset in a system. It lives in conversation history, in memory, or nowhere at all. When the context window closes, it is gone.

This skill preserves that knowledge by converting it into an installable, agent-executable SKILL.md. The extraction requires at least two completed runs of the process: the first run establishes the steps, the second distinguishes essential steps from accidental ones. Formalizing after one run encodes noise alongside signal.

When to Use

• A workflow has been completed at least twice and is likely to be repeated
• User says: "turn this process into a skill", "standardize this workflow", "make this repeatable", "capture this procedure", "formalize this multi-step task"
• A retrospective surfaces a recurring manual sequence that could be automated or delegated
• A process is working but only the person who ran it knows how

Do NOT invoke for half-formed ideas or one-off workflows — redirect to seed capture if the pattern hasn't been validated in practice.

I. The Workflow

This is a 4-step workflow for transforming a process into a skill.

Step 1: Identify and Document the Process

Goal: Create a detailed record of the valuable workflow with concrete examples.

1. Identify a Candidate Process: Select a recently completed workflow that was successful and is likely to be repeated.
2. Use the Process Example Template: Create a new markdown file and use the template at references/process_example_template.md to document the process.
3. Be Detailed: For each step, document the goal, actions taken, tools used, inputs, and outputs.
4. Extract Key Insights: Document the key learnings, non-obvious steps, and reusable patterns from the process.

Step 2: Convert the Process to a Skill

Goal: Use the seed-to-skill-converter to transform the documented process into a SKILL.md file.

1. Invoke the Converter: Use the seed-to-skill-converter skill on the process example document you just created.
2. Deconstruct the Process: The converter will guide you through deconstructing the process into its core components (insight, trigger, process, outcome).
3. Draft the Skill: The converter will then help you draft a SKILL.md file using the standard template.

Step 3: Refine and Enhance the Skill

Goal: Improve the generated SKILL.md file to be a production-ready skill.

1. Add a Quality Checklist: Include a checklist of yes/no questions to ensure the skill is used correctly.
2. Add Best Practices: Document any non-obvious best practices or pitfalls to avoid.
3. Create Bundled Resources: If the skill requires any scripts, templates, or reference files, create them in the skill's directory.

Step 4: Validate and Deliver the Skill

Goal: Ensure the skill is complete, correct, and ready for use.

1. Validate Structure: Check that the SKILL.md has all required sections and grades against the skill-audit rubric.
2. Test the Skill: Use the skill in a real scenario to verify the workflow is complete and the instructions are clear.
3. Place the Skill: Add the skill directory to the appropriate plugin in the repository.

II. Quality Checklist

Before delivering the skill, ensure you can answer "yes" to all of the following questions:

• Have you documented the process with concrete examples using the provided template?
• Have you used seed-to-skill-converter to generate the initial SKILL.md?
• Have you added a quality checklist and best practices to the skill?
• Have you created any necessary bundled resources (scripts, templates, references)?
• Have you validated the skill structure against the skill-audit rubric?
• Have you placed the skill in the appropriate plugin directory?

Output

• A process example document capturing the specific instance: steps, tools, inputs, outputs, and key insights (using references/process_example_template.md)
• A SKILL.md file generated by seed-to-skill-converter from the documented process, with a generalized workflow, quality checklist, and best practices
• Any bundled resources identified during documentation (scripts, templates, reference files) placed in the skill directory
• The completed skill placed in the appropriate plugin directory and validated against the skill-audit rubric

Examples

Scenario 1: "We just finished migrating our plugin directories for the third time — turn that into a skill" → Document the specific migration (which directories, which renames, which cross-reference updates) using the process template, then use seed-to-skill-converter to generalize it into a directory-reconciliation skill with a 5-step workflow.

Scenario 2: During a retrospective: "Every sprint we do the same release-verification sequence manually — can we capture it?" → Document the sequence from the last sprint with concrete tool calls and decision points, convert it to a skill, validate, and place it in the appropriate plugin.

Edge Cases

• Process has only been done once — do not extract yet; one instance is not enough to distinguish essential steps from accidental ones; wait for a second or third run before formalizing
• Process is highly environment-specific (e.g., depends on a particular server's file paths) — generalize paths to parameters during Step 2; if it cannot be generalized, document it as a runbook rather than a skill
• User wants to capture a half-formed idea, not a completed process — redirect to seed-extraction for capturing the insight as a seed; extract to a skill once the pattern has been validated in practice

Best Practices

• Capture the "why" at each step, not just the "what". A steps-only document produces a skill that breaks on any deviation, because there is no basis for adaptation. For each step, note what failure looks like if the step is skipped.
• Generalize parameters during Step 2, not Step 1. Record the specific instance (exact paths, names, tool calls) first, then abstract to parameters when converting to a skill. Premature abstraction loses the concrete anchors that make the skill trustworthy.
• Two-run minimum is a hard gate. One run is a procedure; two runs reveal which steps are essential and which were environmental. Document this explicitly in the process template.
• If the process cannot be generalized, write a runbook. Highly environment-specific workflows (dependent on a particular server's file paths, an org-specific API, etc.) should be documented as runbooks with named constants, not as installable skills.

Anti-Patterns

• Documenting too specifically: Recording every detail of the specific instance (exact file names, dates, one-off decisions) instead of the generalizable pattern — the resulting skill only works for that exact scenario
• Skipping the "why": A process document that lists steps without explaining why each step matters produces a skill that breaks on any deviation, because the user cannot adapt
• Extracting too early: Formalizing after one use encodes noise alongside signal — the second and third runs reveal which steps are truly essential

Related Skills

• skill-creation — for creating a skill from scratch when no prior process exists to extract
• skill-maintenance — for updating an already-extracted skill when the underlying process changes
• batch-normalize-and-package — for packaging multiple extracted skills for distribution