# Process Extraction > Process-to-Skill Workflow - Skill: `dojogenesis/process-extraction` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add dojogenesis/process-extraction` - Raw SKILL.md: https://api.skillmd.com/api/skills/dojogenesis/process-extraction/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity, Integrations & APIs - Author: DojoGenesis (https://skillmd.com/u/dojogenesis) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dojogenesis/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