[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K32NT1GYTENN3QCGTPR7KA":3,"skill-same:01M6K32NT1GYTENN3QCGTPR7KA":164},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6K32NT1GYTENN3QCGTPR7KA","conversation-to-skill",null,"Turn 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 the stable pattern, decide whether the skill should live in `~\u002F.agents\u002Fskills\u002F\u003Cname>` or `\u003Cproject-path>\u002F.agents\u002Fskills\u002F\u003Cname>`, write the skill, and when quality matters add lightweight evals and iteration instead of just transcribing the chat.","Undertone0809\u002Frudder","Undertone0809","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72488598?v=4","01M6K2XANP3QJEF503JX2C693T","Zeeland","01M6K2XATQXEYF7N2QG8KZVEEY",296,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"conversation to skill","conversation","pattern","thread","path","make","add","live","agent skill","iteration","project","workflow","reusable","evals","use","write","read","decide","just","package","2026-11-10 10:12:30",false,"---\nname: conversation-to-skill\ndescription: >\n  Turn the current conversation's workflow into a reusable agent skill. Use this\n  whenever the user wants to make a workflow reusable, standardize a successful\n  thread, package an agent capability, or convert an ad hoc process into a\n  repeatable skill. Read the thread first, extract the stable pattern, decide\n  whether the skill should live in `~\u002F.agents\u002Fskills\u002F\u003Cname>` or\n  `\u003Cproject-path>\u002F.agents\u002Fskills\u002F\u003Cname>`, write the skill, and when quality\n  matters add lightweight evals and iteration instead of just transcribing the\n  chat.\n---\n\n# Conversation To Skill\n\nThis skill turns the work happening in the current conversation into a reusable\nagent skill.\n\nIts job is not just to write `SKILL.md`.\nIts job is to identify the durable workflow, separate it from one-off thread\nnoise, decide the right packaging and placement, and produce a skill that will\nactually help a future agent perform better.\n\nWhen useful, this skill should borrow the practical methods of `skill-creator`:\ngood descriptions, clean skill structure, eval-friendly organization, and an\nimprove-via-feedback loop. When this skill owns evaluation, bundle the relevant\ntoolchain locally under `agents\u002F`, `assets\u002F`, `eval-viewer\u002F`, `scripts\u002F`, and\n`references\u002F` so it stays self-contained instead of depending on another skill\ndirectory at runtime.\n\n## Use This Skill For\n\nUse this skill when the user is trying to:\n\n- turn the current task or workflow into a reusable skill\n- capture a successful collaboration pattern for future runs\n- standardize how a class of tasks should be handled\n- extract a repeatable agent workflow from the current thread\n- package a reasoning framework, execution sequence, or artifact pattern into a skill\n- upgrade an existing draft skill so it is general, usable, and easier to trigger\n\nTypical prompts:\n\n- \"Turn what we're doing into a skill.\"\n- \"I want this conversation to become an agent capability.\"\n- \"Make this reusable for next time.\"\n- \"Abstract this workflow into a Codex skill.\"\n- \"This should be a standard operating pattern, not a one-off chat.\"\n- \"Clean up this skill and make it actually reusable.\"\n\n## Do Not Use This Skill For\n\nDo not use this skill when the user mainly wants:\n\n- a summary of the conversation without creating a reusable skill\n- immediate execution of the task with no abstraction step\n- a skill generated from multiple unseen threads you cannot inspect\n- a rigid template that blindly copies file paths, project names, or temporary constraints\n- a generic skill factory that ignores what was actually valuable in the conversation\n\nIf the conversation does not yet reveal a stable workflow, say that plainly and\nhelp the user clarify the reusable part first.\n\n## Core Principles\n\n### Capture The Repeatable Value\n\nThe skill should capture the repeatable value, not the accidental details.\n\nA good abstraction preserves:\n\n- the job to be done\n- the trigger conditions\n- the critical inputs and outputs\n- the sequence of reasoning or execution\n- the judgment criteria that make the workflow valuable\n- the boundaries and non-goals\n\nA bad abstraction copies:\n\n- temporary filenames\n- irrelevant project-specific paths\n- incidental tools that happened to be used once\n- order-of-operations that are not actually essential\n- user wording that does not generalize\n\n### Explain Why, Not Just What\n\nPrefer instructions that explain why a step matters.\nAvoid brittle mandates unless the workflow truly requires them.\n\nIf you find yourself writing a long list of rigid commands with no reasoning,\nyou are probably transcribing the thread instead of building a skill.\n\n### Choose The Smallest Useful Shape\n\nDo not overbuild the skill.\nUse the smallest structure that preserves the capability:\n\n- `SKILL.md` only, when the workflow is mostly reasoning and sequencing\n- `SKILL.md` plus `references\u002F`, when the skill needs domain guidance\n- `SKILL.md` plus `scripts\u002F`, when deterministic repeated work should be bundled\n- `SKILL.md` plus `evals\u002F`, when the skill benefits from repeatable testing\n\n### Decide Placement Before Writing Files\n\nPick the skill location before creating files so the paths stay stable:\n\n- **Global**: `~\u002F.agents\u002Fskills\u002F\u003Cskill-name>`\n- **Project-based**: `\u003Cproject-path>\u002F.agents\u002Fskills\u002F\u003Cskill-name>`\n\nIf the user wants a global skill to be discoverable by Codex immediately, also\ncreate:\n\n- `~\u002F.codex\u002Fskills\u002F\u003Cskill-name>` as a symlink to the global skill directory\n\nIf you plan to run evals, place the workspace next to the skill directory as:\n\n- `\u003Cskill-name>-workspace\u002F`\n\n## Default Workflow\n\nFollow this sequence unless the user already provided enough structure.\n\n### 1. Extract The Candidate Skill From The Current Thread\n\nRead the current conversation first.\nPull out the real workflow before asking the user to restate everything.\n\nCapture:\n\n- what the user was trying to achieve\n- what sequence of steps the agent followed or should follow\n- which tools or artifacts mattered\n- what corrections or preferences the user introduced\n- what output the user actually wanted\n- what makes this reusable instead of one-off\n\n### 2. Separate Stable Pattern From Incidental Context\n\nClassify each detail into one of three buckets:\n\n- **Core**: must stay because the skill breaks without it\n- **Contextual**: useful examples or defaults, but not universal\n- **Incidental**: this-thread noise that should not be baked into the skill\n\nUseful heuristic:\n\n- if the detail would still matter in six months on a different project, it is probably core\n- if it only mattered because of this repository, filename, or user phrasing, it is probably contextual or incidental\n\n### 3. Fill Gaps With Minimal Interview Or Research\n\nDo not ask the user to restate the whole workflow if the thread already tells\nyou most of it.\nOnly ask for the missing pieces that affect the resulting skill:\n\n- what this skill should enable the agent to do\n- when the skill should trigger\n- what output format or artifact the user expects\n- whether lightweight test prompts would help validate the result\n\nIf examples, edge cases, dependencies, or adjacent skills matter, gather that\ncontext before writing the final version.\n\n### 4. Produce An Abstraction Brief Before Writing Files\n\nBefore generating the final skill, write a short abstraction brief for the user\nto review unless they already said to just build it.\n\nUse this structure:\n\n```markdown\n## Skill Intent\n- Name:\n- Goal:\n- Why this should exist:\n\n## Trigger\n- Use when:\n- Do not use when:\n\n## Inputs\n- Required inputs:\n- Optional inputs:\n\n## Outputs\n- Main deliverable:\n- Secondary artifacts:\n\n## Workflow\n1. ...\n2. ...\n3. ...\n\n## Judgment Rules\n- What must stay true:\n- What to avoid:\n\n## Open Questions\n- ...\n```\n\nIf the conversation already settles these points, keep the brief short and move\non.\n\n### 5. Challenge Weak Abstractions\n\nDo not act like a passive stenographer.\nIf the proposed skill is overfit, under-scoped, or missing the real judgment\nlogic, say so and correct it.\n\nCommon failure modes to call out:\n\n- \"This is a transcript, not a skill.\"\n- \"These instructions depend on this exact repo, but the user asked for a global skill.\"\n- \"The workflow says what to do, but not how to decide when a step is necessary.\"\n- \"The description would under-trigger because it only names one phrasing.\"\n- \"This skill repeats manual work that should be moved into a bundled script.\"\n\n### 6. Decide Location, Shape, And Scope\n\nMake these decisions before writing:\n\n- whether the skill is global or project-based\n- whether to preserve an existing name and directory\n- whether `SKILL.md` alone is enough\n- whether the skill needs `references\u002F`, `scripts\u002F`, `assets\u002F`, or `evals\u002F`\n- whether a sibling workspace should be created for testing\n\nDefault location rules:\n\n- **Global skill**: `~\u002F.agents\u002Fskills\u002F\u003Cskill-name>`\n- **Project-based skill**: `\u003Cproject-path>\u002F.agents\u002Fskills\u002F\u003Cskill-name>`\n\nIf updating an existing skill, preserve the directory name and frontmatter name\nunless the user asked for a rename.\n\n### 7. Write The Skill Like A Real Skill\n\nWhen writing `SKILL.md`, include:\n\n- frontmatter with `name` and a trigger-oriented `description`\n- what the skill is for\n- when to use it and when not to use it\n- the default workflow\n- output expectations\n- edge cases and boundaries when they materially affect quality\n\nBring in the `skill-creator` quality bar here:\n\n- make the description a little aggressive so hosts do not under-trigger it\n- include both what the skill does and the contexts that should trigger it\n- prefer imperative instructions\n- explain the reasoning behind important steps\n- keep the file readable; if it grows too large, move detail into references\n\n### 8. Use Clean Skill Structure\n\nPrefer this structure when it helps:\n\n```text\nskill-name\u002F\n├── SKILL.md\n├── references\u002F\n├── scripts\u002F\n├── assets\u002F\n└── evals\u002F\n```\n\nUse progressive disclosure:\n\n1. metadata in frontmatter should be enough to trigger the skill\n2. `SKILL.md` should explain the workflow clearly\n3. large reference material should be loaded only when relevant\n\nWhen the skill supports multiple variants or domains, organize references by\nvariant and tell the future agent which file to read for which case.\n\nIf the user wants more than a draft, or explicitly asks for testing,\nbenchmarking, or trigger tuning, add local references that capture the\nevaluation workflow instead of leaving that logic implicit.\n\nIf the workflow needs actual tooling, prefer bundling it inside this skill\nrather than pointing at another repo's copy.\n\n### 9. Bundle Repeated Deterministic Work\n\nIf multiple runs of the workflow would obviously repeat the same deterministic\nsteps, package that work into `scripts\u002F` instead of forcing future agents to\nreinvent it every time.\n\nGood candidates:\n\n- file conversions\n- formatting helpers\n- benchmark aggregation\n- schema validation\n- packaging helpers\n\nDo not add scripts just because you can.\nOnly bundle work that is repeated, stable, and cheaper to reuse than to re-derive.\n\n### 10. Add Evals With The Full Suite When The Skill Warrants Them\n\nNot every conversation-derived skill needs evals.\nBut if the skill produces objectively testable outputs, if the user asks for\nbenchmarking, or if you are iterating on quality instead of just drafting, do\nnot stop at a hand-wavy \"light eval.\"\n\nWhen you choose to evaluate, use the full evaluation suite:\n\n- create 2-3 realistic test prompts and store them in `evals\u002Fevals.json`\n- create a sibling `\u003Cskill-name>-workspace\u002F` for iteration outputs\n- compare `with_skill` against `without_skill` or an old snapshot\n- draft assertions while runs are executing\n- capture timing and grading artifacts per run\n- aggregate results into a benchmark\n- generate a reviewable viewer artifact for the human\n- read feedback, improve the skill, and rerun into the next iteration\n\nThe detailed procedure lives in:\n\n- `references\u002Fevaluation-suite.md` for test execution, grading, benchmark aggregation, feedback, and iteration\n- `references\u002Fdescription-optimization.md` for trigger-query generation and description tuning\n- `references\u002Fcompatibility.md` and `references\u002Fschemas.md` for host differences and file formats\n\nThe local support toolchain lives in:\n\n- `agents\u002F` for grader, comparator, and analyst instructions\n- `assets\u002F` for review UI assets\n- `eval-viewer\u002F` for viewer generation\n- `scripts\u002F` for aggregation, optimization, validation, and packaging\n\nIf you decide evals are needed, read those reference files before proceeding.\n\nPrefer qualitative review for subjective skills.\nPrefer assertions and benchmarks for objective skills.\n\n### 11. Iterate Instead Of Fossilizing Bad Drafts\n\nIf the first draft feels narrow, ambiguous, or weakly triggered, improve it.\nUseful improvement passes include:\n\n- description tuning for better triggering\n- removing overfit instructions\n- generalizing from user feedback\n- turning repeated ad hoc steps into bundled resources\n- simplifying sections that make the model do busywork\n\nDo not force a full benchmark loop if the user only wants a draft.\nBut do not pretend the first draft is final if it clearly is not.\n\n### 12. Close With A Clear Hand-off\n\nAfter creating or revising the skill, report:\n\n- the chosen skill name\n- whether it is global or project-based\n- the final path\n- whether a Codex symlink was created\n- whether eval files or a workspace were created\n- what still needs evaluation, if anything\n\n## Naming Guidance\n\nChoose names that are short, clear, and capability-oriented.\n\nPrefer names like:\n\n- `conversation-to-skill`\n- `workflow-standardizer`\n- `task-to-playbook`\n\nAvoid names that depend on this thread's temporary wording unless the user\nexplicitly wants that.\n\nIf updating an existing skill, preserve the existing directory name and\nfrontmatter name unless the user asked for a rename.\n\n## Output Format\n\nUnless the user wants files written immediately, start with:\n\n1. a compact abstraction brief\n2. the proposed skill name and placement\n3. any risks of overfitting or under-specification\n\nIf the user asks to proceed, then write the files.\n\nWhen the user already said \"build it\" or \"just make it\", go straight from the\nbrief into file creation in the same turn.\n\nIf you also set up evals, mention:\n\n- the test prompts\n- what is being compared\n- where the reviewable output lives\n\n## Quality Bar\n\nThe resulting skill should make a future agent meaningfully better at the task.\n\nThat usually means it captures at least one of these:\n\n- a reusable workflow\n- a reusable decision framework\n- a reusable artifact format\n- a reusable boundary or escalation rule\n\nStrong skills often also have at least one of these:\n\n- a well-targeted description that triggers reliably\n- a clean placement and file layout\n- a bundled helper for repeated deterministic work\n- a full eval loop that makes improvements testable\n\nIf it captures none of those, it is probably not a real skill yet.\n\n## Safety And Boundaries\n\nDo not create misleading, hostile, or surprise-heavy skills.\nThe skill should do what its description honestly suggests.\n\nDo not package instructions that facilitate unauthorized access, harmful\nautomation, or disguised exfiltration.\n\nRoleplay, stylistic framing, and benign workflow abstraction are fine.\n","# Conversation To Skill\n\nThis skill turns the work happening in the current conversation into a reusable\nagent skill.\n\nIts job is not just to write `SKILL.md`.\nIts job is to identify the durable workflow, separate it from one-off thread\nnoise, decide the right packaging and placement, and produce a skill that will\nactually help a future agent perform better.\n\nWhen useful, this skill should borrow the practical methods of `skill-creator`:\ngood descriptions, clean skill structure, eval-friendly organization, and an\nimprove-via-feedback loop. When this skill owns evaluation, bundle the relevant\ntoolchain locally under `agents\u002F`, `assets\u002F`, `eval-viewer\u002F`, `scripts\u002F`, and\n`references\u002F` so it stays self-contained instead of depending on another skill\ndirectory at runtime.\n\n## Use This Skill For\n\nUse this skill when the user is trying to:\n\n- turn the current task or workflow into a reusable skill\n- capture a successful collaboration pattern for future runs\n- standardize how a class of tasks should be handled\n- extract a repeatable agent workflow from the current thread\n- package a reasoning framework, execution sequence, or artifact pattern into a skill\n- upgrade an existing draft skill so it is general, usable, and easier to trigger\n\nTypical prompts:\n\n- \"Turn what we're doing into a skill.\"\n- \"I want this conversation to become an agent capability.\"\n- \"Make this reusable for next time.\"\n- \"Abstract this workflow into a Codex skill.\"\n- \"This should be a standard operating pattern, not a one-off chat.\"\n- \"Clean up this skill and make it actually reusable.\"\n\n## Do Not Use This Skill For\n\nDo not use this skill when the user mainly wants:\n\n- a summary of the conversation without creating a reusable skill\n- immediate execution of the task with no abstraction step\n- a skill generated from multiple unseen threads you cannot inspect\n- a rigid template that blindly copies file paths, project names, or temporary constraints\n- a generic skill factory that ignores what was actually valuable in the conversation\n\nIf the conversation does not yet reveal a stable workflow, say that plainly and\nhelp the user clarify the reusable part first.\n\n## Core Principles\n\n### Capture The Repeatable Value\n\nThe skill should capture the repeatable value, not the accidental details.\n\nA good abstraction preserves:\n\n- the job to be done\n- the trigger conditions\n- the critical inputs and outputs\n- the sequence of reasoning or execution\n- the judgment criteria that make the workflow valuable\n- the boundaries and non-goals\n\nA bad abstraction copies:\n\n- temporary filenames\n- irrelevant project-specific paths\n- incidental tools that happened to be used once\n- order-of-operations that are not actually essential\n- user wording that does not generalize\n\n### Explain Why, Not Just What\n\nPrefer instructions that explain why a step matters.\nAvoid brittle mandates unless the workflow truly requires them.\n\nIf you find yourself writing a long list of rigid commands with no reasoning,\nyou are probably transcribing the thread instead of building a skill.\n\n### Choose The Smallest Useful Shape\n\nDo not overbuild the skill.\nUse the smallest structure that preserves the capability:\n\n- `SKILL.md` only, when the workflow is mostly reasoning and sequencing\n- `SKILL.md` plus `references\u002F`, when the skill needs domain guidance\n- `SKILL.md` plus `scripts\u002F`, when deterministic repeated work should be bundled\n- `SKILL.md` plus `evals\u002F`, when the skill benefits from repeatable testing\n\n### Decide Placement Before Writing Files\n\nPick the skill location before creating files so the paths stay stable:\n\n- **Global**: `~\u002F.agents\u002Fskills\u002F\u003Cskill-name>`\n- **Project-based**: `\u003Cproject-path>\u002F.agents\u002Fskills\u002F\u003Cskill-name>`\n\nIf the user wants a global skill to be discoverable by Codex immediately, also\ncreate:\n\n- `~\u002F.codex\u002Fskills\u002F\u003Cskill-name>` as a symlink to the global skill directory\n\nIf you plan to run evals, place the workspace next to the skill directory as:\n\n- `\u003Cskill-name>-workspace\u002F`\n\n## Default Workflow\n\nFollow this sequence unless the user already provided enough structure.\n\n### 1. Extract The Candidate Skill From The Current Thread\n\nRead the current conversation first.\nPull out the real workflow before asking the user to restate everything.\n\nCapture:\n\n- what the user was trying to achieve\n- what sequence of steps the agent followed or should follow\n- which tools or artifacts mattered\n- what corrections or preferences the user introduced\n- what output the user actually wanted\n- what makes this reusable instead of one-off\n\n### 2. Separate Stable Pattern From Incidental Context\n\nClassify each detail into one of three buckets:\n\n- **Core**: must stay because the skill breaks without it\n- **Contextual**: useful examples or defaults, but not universal\n- **Incidental**: this-thread noise that should not be baked into the skill\n\nUseful heuristic:\n\n- if the detail would still matter in six months on a different project, it is probably core\n- if it only mattered because of this repository, filename, or user phrasing, it is probably contextual or incidental\n\n### 3. Fill Gaps With Minimal Interview Or Research\n\nDo not ask the user to restate the whole workflow if the thread already tells\nyou most of it.\nOnly ask for the missing pieces that affect the resulting skill:\n\n- what this skill should enable the agent to do\n- when the skill should trigger\n- what output format or artifact the user expects\n- whether lightweight test prompts would help validate the result\n\nIf examples, edge cases, dependencies, or adjacent skills matter, gather that\ncontext before writing the final version.\n\n### 4. Produce An Abstraction Brief Before Writing Files\n\nBefore generating the final skill, write a short abstraction brief for the user\nto review unless they already said to just build it.\n\nUse this structure:\n\n```markdown\n## Skill Intent\n- Name:\n- Goal:\n- Why this should exist:\n\n## Trigger\n- Use when:\n- Do not use when:\n\n## Inputs\n- Required inputs:\n- Optional inputs:\n\n## Outputs\n- Main deliverable:\n- Secondary artifacts:\n\n## Workflow\n1. ...\n2. ...\n3. ...\n\n## Judgment Rules\n- What must stay true:\n- What to avoid:\n\n## Open Questions\n- ...\n```\n\nIf the conversation already settles these points, keep the brief short and move\non.\n\n### 5. Challenge Weak Abstractions\n\nDo not act like a passive stenographer.\nIf the proposed skill is overfit, under-scoped, or missing the real judgment\nlogic, say so and correct it.\n\nCommon failure modes to call out:\n\n- \"This is a transcript, not a skill.\"\n- \"These instructions depend on this exact repo, but the user asked for a global skill.\"\n- \"The workflow says what to do, but not how to decide when a step is necessary.\"\n- \"The description would under-trigger because it only names one phrasing.\"\n- \"This skill repeats manual work that should be moved into a bundled script.\"\n\n### 6. Decide Location, Shape, And Scope\n\nMake these decisions before writing:\n\n- whether the skill is global or project-based\n- whether to preserve an existing name and directory\n- whether `SKILL.md` alone is enough\n- whether the skill needs `references\u002F`, `scripts\u002F`, `assets\u002F`, or `evals\u002F`\n- whether a sibling workspace should be created for testing\n\nDefault location rules:\n\n- **Global skill**: `~\u002F.agents\u002Fskills\u002F\u003Cskill-name>`\n- **Project-based skill**: `\u003Cproject-path>\u002F.agents\u002Fskills\u002F\u003Cskill-name>`\n\nIf updating an existing skill, preserve the directory name and frontmatter name\nunless the user asked for a rename.\n\n### 7. Write The Skill Like A Real Skill\n\nWhen writing `SKILL.md`, include:\n\n- frontmatter with `name` and a trigger-oriented `description`\n- what the skill is for\n- when to use it and when not to use it\n- the default workflow\n- output expectations\n- edge cases and boundaries when they materially affect quality\n\nBring in the `skill-creator` quality bar here:\n\n- make the description a little aggressive so hosts do not under-trigger it\n- include both what the skill does and the contexts that should trigger it\n- prefer imperative instructions\n- explain the reasoning behind important steps\n- keep the file readable; if it grows too large, move detail into references\n\n### 8. Use Clean Skill Structure\n\nPrefer this structure when it helps:\n\n```text\nskill-name\u002F\n├── SKILL.md\n├── references\u002F\n├── scripts\u002F\n├── assets\u002F\n└── evals\u002F\n```\n\nUse progressive disclosure:\n\n1. metadata in frontmatter should be enough to trigger the skill\n2. `SKILL.md` should explain the workflow clearly\n3. large reference material should be loaded only when relevant\n\nWhen the skill supports multiple variants or domains, organize references by\nvariant and tell the future agent which file to read for which case.\n\nIf the user wants more than a draft, or explicitly asks for testing,\nbenchmarking, or trigger tuning, add local references that capture the\nevaluation workflow instead of leaving that logic implicit.\n\nIf the workflow needs actual tooling, prefer bundling it inside this skill\nrather than pointing at another repo's copy.\n\n### 9. Bundle Repeated Deterministic Work\n\nIf multiple runs of the workflow would obviously repeat the same deterministic\nsteps, package that work into `scripts\u002F` instead of forcing future agents to\nreinvent it every time.\n\nGood candidates:\n\n- file conversions\n- formatting helpers\n- benchmark aggregation\n- schema validation\n- packaging helpers\n\nDo not add scripts just because you can.\nOnly bundle work that is repeated, stable, and cheaper to reuse than to re-derive.\n\n### 10. Add Evals With The Full Suite When The Skill Warrants Them\n\nNot every conversation-derived skill needs evals.\nBut if the skill produces objectively testable outputs, if the user asks for\nbenchmarking, or if you are iterating on quality instead of just drafting, do\nnot stop at a hand-wavy \"light eval.\"\n\nWhen you choose to evaluate, use the full evaluation suite:\n\n- create 2-3 realistic test prompts and store them in `evals\u002Fevals.json`\n- create a sibling `\u003Cskill-name>-workspace\u002F` for iteration outputs\n- compare `with_skill` against `without_skill` or an old snapshot\n- draft assertions while runs are executing\n- capture timing and grading artifacts per run\n- aggregate results into a benchmark\n- generate a reviewable viewer artifact for the human\n- read feedback, improve the skill, and rerun into the next iteration\n\nThe detailed procedure lives in:\n\n- `references\u002Fevaluation-suite.md` for test execution, grading, benchmark aggregation, feedback, and iteration\n- `references\u002Fdescription-optimization.md` for trigger-query generation and description tuning\n- `references\u002Fcompatibility.md` and `references\u002Fschemas.md` for host differences and file formats\n\nThe local support toolchain lives in:\n\n- `agents\u002F` for grader, comparator, and analyst instructions\n- `assets\u002F` for review UI assets\n- `eval-viewer\u002F` for viewer generation\n- `scripts\u002F` for aggregation, optimization, validation, and packaging\n\nIf you decide evals are needed, read those reference files before proceeding.\n\nPrefer qualitative review for subjective skills.\nPrefer assertions and benchmarks for objective skills.\n\n### 11. Iterate Instead Of Fossilizing Bad Drafts\n\nIf the first draft feels narrow, ambiguous, or weakly triggered, improve it.\nUseful improvement passes include:\n\n- description tuning for better triggering\n- removing overfit instructions\n- generalizing from user feedback\n- turning repeated ad hoc steps into bundled resources\n- simplifying sections that make the model do busywork\n\nDo not force a full benchmark loop if the user only wants a draft.\nBut do not pretend the first draft is final if it clearly is not.\n\n### 12. Close With A Clear Hand-off\n\nAfter creating or revising the skill, report:\n\n- the chosen skill name\n- whether it is global or project-based\n- the final path\n- whether a Codex symlink was created\n- whether eval files or a workspace were created\n- what still needs evaluation, if anything\n\n## Naming Guidance\n\nChoose names that are short, clear, and capability-oriented.\n\nPrefer names like:\n\n- `conversation-to-skill`\n- `workflow-standardizer`\n- `task-to-playbook`\n\nAvoid names that depend on this thread's temporary wording unless the user\nexplicitly wants that.\n\nIf updating an existing skill, preserve the existing directory name and\nfrontmatter name unless the user asked for a rename.\n\n## Output Format\n\nUnless the user wants files written immediately, start with:\n\n1. a compact abstraction brief\n2. the proposed skill name and placement\n3. any risks of overfitting or under-specification\n\nIf the user asks to proceed, then write the files.\n\nWhen the user already said \"build it\" or \"just make it\", go straight from the\nbrief into file creation in the same turn.\n\nIf you also set up evals, mention:\n\n- the test prompts\n- what is being compared\n- where the reviewable output lives\n\n## Quality Bar\n\nThe resulting skill should make a future agent meaningfully better at the task.\n\nThat usually means it captures at least one of these:\n\n- a reusable workflow\n- a reusable decision framework\n- a reusable artifact format\n- a reusable boundary or escalation rule\n\nStrong skills often also have at least one of these:\n\n- a well-targeted description that triggers reliably\n- a clean placement and file layout\n- a bundled helper for repeated deterministic work\n- a full eval loop that makes improvements testable\n\nIf it captures none of those, it is probably not a real skill yet.\n\n## Safety And Boundaries\n\nDo not create misleading, hostile, or surprise-heavy skills.\nThe skill should do what its description honestly suggests.\n\nDo not package instructions that facilitate unauthorized access, harmful\nautomation, or disguised exfiltration.\n\nRoleplay, stylistic framing, and benign workflow abstraction are fine.\n",{"name":5,"description":7},"main","26d5d68bcbc55caeac1dc6a266d973e8c3831f1c","server\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill",31,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder","https:\u002F\u002Frudderhq.dev","https:\u002F\u002Fgithub.com\u002FUndertone0809","Creator of Rudder, Spark Lab. I design SDKs, infra and software for human and the NEW WORLD.","2026-11-08 00:09:15",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add Undertone0809\u002Frudder --skill conversation-to-skill",{"tool":64,"command":65},"bunx","bunx skills add Undertone0809\u002Frudder --skill conversation-to-skill",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Undertone0809\u002Frudder --skill conversation-to-skill","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002FSKILL.md",true,[72,78,82,86,92,98,102,108,112,116,120,124,128,132,136,140,144,148,152,156,160],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"agents\u002Fanalyzer.md","REFERENCE","参考文档",10376,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fagents\u002Fanalyzer.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"agents\u002Fcomparator.md",7287,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fagents\u002Fcomparator.md",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"agents\u002Fgrader.md",9049,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fagents\u002Fgrader.md",{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"assets\u002Feval_review.html","ASSET","资产文件",7058,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fassets\u002Feval_review.html",{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":97},"eval-viewer\u002Fgenerate_review.py","SCRIPT","脚本",16365,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Feval-viewer\u002Fgenerate_review.py",{"path":99,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":100,"sourceHtmlUrl":101},"eval-viewer\u002Fviewer.html",44984,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Feval-viewer\u002Fviewer.html",{"path":103,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":106,"sourceHtmlUrl":107},"LICENSE.txt","LICENSE","许可证",11357,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002FLICENSE.txt",{"path":109,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Fcompatibility.md",1504,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Freferences\u002Fcompatibility.md",{"path":113,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Fdescription-optimization.md",3241,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Freferences\u002Fdescription-optimization.md",{"path":117,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":118,"sourceHtmlUrl":119},"references\u002Fevaluation-suite.md",10491,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Freferences\u002Fevaluation-suite.md",{"path":121,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":122,"sourceHtmlUrl":123},"references\u002Fschemas.md",12114,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Freferences\u002Fschemas.md",{"path":125,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":126,"sourceHtmlUrl":127},"scripts\u002F__init__.py",0,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fscripts\u002F__init__.py",{"path":129,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":130,"sourceHtmlUrl":131},"scripts\u002Faggregate_benchmark.py",14386,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fscripts\u002Faggregate_benchmark.py",{"path":133,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":134,"sourceHtmlUrl":135},"scripts\u002Fgenerate_report.py",12910,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fscripts\u002Fgenerate_report.py",{"path":137,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":138,"sourceHtmlUrl":139},"scripts\u002Fimprove_description.py",7424,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fscripts\u002Fimprove_description.py",{"path":141,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":142,"sourceHtmlUrl":143},"scripts\u002Fmodel_backends.py",3394,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fscripts\u002Fmodel_backends.py",{"path":145,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":146,"sourceHtmlUrl":147},"scripts\u002Fpackage_skill.py",4234,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fscripts\u002Fpackage_skill.py",{"path":149,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":150,"sourceHtmlUrl":151},"scripts\u002Fquick_validate.py",4050,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fscripts\u002Fquick_validate.py",{"path":153,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":154,"sourceHtmlUrl":155},"scripts\u002Frun_eval.py",13177,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fscripts\u002Frun_eval.py",{"path":157,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":158,"sourceHtmlUrl":159},"scripts\u002Frun_loop.py",13249,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fscripts\u002Frun_loop.py",{"path":161,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":162,"sourceHtmlUrl":163},"scripts\u002Futils.py",7018,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fconversation-to-skill\u002Fscripts\u002Futils.py",[165,178,189,215,244,267],{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":44},"01M6K33ZG45BN249F4DZRCCSJN","Source Synthesis","Synthesize evidence into a concise conclusion.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Ftests\u002Fe2e\u002Ffixtures\u002Fcodex-plugin-research\u002Fskills\u002Fsynthesis\u002FSKILL.md",[],[172,173,174,175,176,177],"Synthesis","source","source synthesis","concise","synthesize","evidence",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":187,"publishedAt":44},"01M6K33XMZXRM31H2SG618C37F","Evidence Research","Gather and cite evidence before reaching a conclusion.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Ftests\u002Fe2e\u002Ffixtures\u002Fcodex-plugin-research\u002Fskills\u002Fevidence\u002FSKILL.md",[184],{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[188,177,180],"research",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":196,"publishedAt":44},"01M6K33RHAPNGPCM2FGPWTZQ8G","deep-research","Conducts enterprise-grade research with multi-source synthesis, citation tracking, and verification. Produces citation-backed reports through a structured pipeline with source credibility scoring, and grounds abstract findings in concrete examples, cases, counterexamples, or mini-scenarios when helpful. Triggers on \"deep research\", \"comprehensive analysis\", \"research report\", \"compare X vs Y\", \"analyze trends\", or \"state of the art\". Not for simple lookups, debugging, or questions answerable with 1-2 searches.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fcommunity-skills\u002Fdeep-research\u002FSKILL.md",[195],{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},[197,198,188,199,200,201,174,202,203,204,205,206,207,208,209,210,211,212,213,214],"deep research","deep","state","debugging","triggers","for","with","multi","compare","verification","scoring","Art","reports","analyze","analysis","pipeline","Enterprise","examples",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":224,"publishedAt":44},"01M6K33JPMYXHY9E4WR0K9EK0V","visualize","Create safe inline visual explanations in Rudder Chat. Use when asked for a chart, plot, diagram, timeline, comparison, static map, simulator, scenario view, or compact visual that materially improves understanding. Prefer Mermaid for static node-and-edge structures; use Rudder's runtime-neutral HTML\u002FSVG\u002FCSS message envelope for custom geometry. Rudder visuals are declarative and scriptless: convert simulator requests to static scenarios or disclosure-based comparisons and never rely on JavaScript, network access, or external assets.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fvisualize\u002FSKILL.md",[221],{"categoryNo":222,"categoryName":223,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[217,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243],"static","inline","chart","scenario","access","geometry","map","message","compact","back","never","node","mermaid","network","create","diagram","safe","css","markdown",{"skillNo":245,"name":246,"nameZh":6,"description":247,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":248,"categories":249,"keywords":251,"publishedAt":44},"01M6K339S5PWH9RTZZA71CPD32","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fskill-creator\u002FSKILL.md",[250],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[252,253,254,255,256,257,258,259,202,260,261,262,37,38,263,264,211,265,266,239],"skill creator","creator","run evals","performance","variance analysis","existing skill","Existing","accuracy","From Scratch","users","optimize","edit","improve","benchmark","run",{"skillNo":268,"name":269,"nameZh":6,"description":270,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":271,"categories":272,"keywords":273,"publishedAt":44},"01M6K333T855082YFXZ4FW0SE7","rudder-docs","Use when the user asks how Rudder works; needs current Rudder docs, exact behavior, commands, contracts, APIs, or source evidence; asks to create, hire, or configure Rudder agents; or asks to scaffold, develop, or verify Rudder plugins. For explicit creation requests, verify the current interface before acting within existing authorization. Do not use for greetings, ordinary work merely running inside Rudder, routine actions already clear from the active context and typed tools, non-Rudder plugin work, or general coding and research tasks that do not ask about Rudder.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Frudder-docs\u002FSKILL.md",[],[274,275,276,173,277,278,279,280,281,282,283,284,285,286,287,288,289,290,239,291],"rudder docs","docs","context","interface","hire","creation","commands","active","do","contracts","ask","work","coding","configure","how","Tools","actions","tasks"]