$npx -y skills add Undertone0809/rudder --skill conversation-to-skillTurn the current conversation's workflow into a reusable agent skill. Use this whenever the user wants to make a workflow reusable, standardize a successful thread, package an agent capability, or convert an ad hoc process into a repeatable skill. Read the thread first, extract t
| 1 | # Conversation To Skill |
| 2 | |
| 3 | This skill turns the work happening in the current conversation into a reusable |
| 4 | agent skill. |
| 5 | |
| 6 | Its job is not just to write `SKILL.md`. |
| 7 | Its job is to identify the durable workflow, separate it from one-off thread |
| 8 | noise, decide the right packaging and placement, and produce a skill that will |
| 9 | actually help a future agent perform better. |
| 10 | |
| 11 | When useful, this skill should borrow the practical methods of `skill-creator`: |
| 12 | good descriptions, clean skill structure, eval-friendly organization, and an |
| 13 | improve-via-feedback loop. When this skill owns evaluation, bundle the relevant |
| 14 | toolchain locally under `agents/`, `assets/`, `eval-viewer/`, `scripts/`, and |
| 15 | `references/` so it stays self-contained instead of depending on another skill |
| 16 | directory at runtime. |
| 17 | |
| 18 | ## Use This Skill For |
| 19 | |
| 20 | Use this skill when the user is trying to: |
| 21 | |
| 22 | - turn the current task or workflow into a reusable skill |
| 23 | - capture a successful collaboration pattern for future runs |
| 24 | - standardize how a class of tasks should be handled |
| 25 | - extract a repeatable agent workflow from the current thread |
| 26 | - package a reasoning framework, execution sequence, or artifact pattern into a skill |
| 27 | - upgrade an existing draft skill so it is general, usable, and easier to trigger |
| 28 | |
| 29 | Typical prompts: |
| 30 | |
| 31 | - "Turn what we're doing into a skill." |
| 32 | - "I want this conversation to become an agent capability." |
| 33 | - "Make this reusable for next time." |
| 34 | - "Abstract this workflow into a Codex skill." |
| 35 | - "This should be a standard operating pattern, not a one-off chat." |
| 36 | - "Clean up this skill and make it actually reusable." |
| 37 | |
| 38 | ## Do Not Use This Skill For |
| 39 | |
| 40 | Do not use this skill when the user mainly wants: |
| 41 | |
| 42 | - a summary of the conversation without creating a reusable skill |
| 43 | - immediate execution of the task with no abstraction step |
| 44 | - a skill generated from multiple unseen threads you cannot inspect |
| 45 | - a rigid template that blindly copies file paths, project names, or temporary constraints |
| 46 | - a generic skill factory that ignores what was actually valuable in the conversation |
| 47 | |
| 48 | If the conversation does not yet reveal a stable workflow, say that plainly and |
| 49 | help the user clarify the reusable part first. |
| 50 | |
| 51 | ## Core Principles |
| 52 | |
| 53 | ### Capture The Repeatable Value |
| 54 | |
| 55 | The skill should capture the repeatable value, not the accidental details. |
| 56 | |
| 57 | A good abstraction preserves: |
| 58 | |
| 59 | - the job to be done |
| 60 | - the trigger conditions |
| 61 | - the critical inputs and outputs |
| 62 | - the sequence of reasoning or execution |
| 63 | - the judgment criteria that make the workflow valuable |
| 64 | - the boundaries and non-goals |
| 65 | |
| 66 | A bad abstraction copies: |
| 67 | |
| 68 | - temporary filenames |
| 69 | - irrelevant project-specific paths |
| 70 | - incidental tools that happened to be used once |
| 71 | - order-of-operations that are not actually essential |
| 72 | - user wording that does not generalize |
| 73 | |
| 74 | ### Explain Why, Not Just What |
| 75 | |
| 76 | Prefer instructions that explain why a step matters. |
| 77 | Avoid brittle mandates unless the workflow truly requires them. |
| 78 | |
| 79 | If you find yourself writing a long list of rigid commands with no reasoning, |
| 80 | you are probably transcribing the thread instead of building a skill. |
| 81 | |
| 82 | ### Choose The Smallest Useful Shape |
| 83 | |
| 84 | Do not overbuild the skill. |
| 85 | Use the smallest structure that preserves the capability: |
| 86 | |
| 87 | - `SKILL.md` only, when the workflow is mostly reasoning and sequencing |
| 88 | - `SKILL.md` plus `references/`, when the skill needs domain guidance |
| 89 | - `SKILL.md` plus `scripts/`, when deterministic repeated work should be bundled |
| 90 | - `SKILL.md` plus `evals/`, when the skill benefits from repeatable testing |
| 91 | |
| 92 | ### Decide Placement Before Writing Files |
| 93 | |
| 94 | Pick the skill location before creating files so the paths stay stable: |
| 95 | |
| 96 | - **Global**: `~/.agents/skills/<skill-name>` |
| 97 | - **Project-based**: `<project-path>/.agents/skills/<skill-name>` |
| 98 | |
| 99 | If the user wants a global skill to be discoverable by Codex immediately, also |
| 100 | create: |
| 101 | |
| 102 | - `~/.codex/skills/<skill-name>` as a symlink to the global skill directory |
| 103 | |
| 104 | If you plan to run evals, place the workspace next to the skill directory as: |
| 105 | |
| 106 | - `<skill-name>-workspace/` |
| 107 | |
| 108 | ## Default Workflow |
| 109 | |
| 110 | Follow this sequence unless the user already provided enough structure. |
| 111 | |
| 112 | ### 1. Extract The Candidate Skill From The Current Thread |
| 113 | |
| 114 | Read the current conversation first. |
| 115 | Pull out the real workflow before asking the user to restate everything. |
| 116 | |
| 117 | Capture: |
| 118 | |
| 119 | - what the user was trying to achieve |
| 120 | - what sequence of steps the agent followed or should follow |
| 121 | - which tools or artifacts mattered |
| 122 | - what correcti |