Source to skill distiller

Source To Skill Distiller

Overview

Use this skill to turn source material into a compact, installable skill package that a future agent can use without rereading the original source. Distill mechanisms, not summaries.

Resource Guide

• Read references/source-to-skill-patterns.md for source intake rules, multilingual handling, mechanism cards, package shape decisions, and validation checklists.
• Use the target repository's own validator, registry generator, catalog generator, and eval conventions before adding new local scripts.

First Principle

The source is evidence. The skill is the reusable control surface: trigger, decision rules, workflow, output contract, boundaries, and validation.

Workflow

1. Name the evidence boundary: source paths, links, languages, formats, sections read, sections unavailable, assumptions, sensitivity, intended audience, license, and publication authority. Access to a private source or history is not authority to publish it.
2. Choose the smallest mode:
   • quick brief: short pasted method or memo;
   • source audit: multiple files, transcripts, repositories, media, or mixed languages;
   • package build: user asks for files, repo changes, installability, or validation;
   • repair: existing skill fails, over-triggers, summarizes, or cannot validate.
3. Extract mechanism cards from the source: trigger, user job, decision rule, procedure, output, quality signal, failure mode, and keep/merge/discard decision.
4. Choose one package shape before writing: single procedural skill by default, one skill with modes when source tasks share a route. Do not create meta skill routers. Put extra knowledge in references/ or merge into an existing owner unless the recurring jobs, independently accepted artifacts, and acceptance authorities are distinct.
5. Author the skill around action: concise front-loaded metadata naming the job, artifact, material contexts, and nearby exclusions; then a focused workflow, output protocol, boundaries, and linked references. Keywords are semantic anchors, not a list to stuff. Put long examples, rubrics, language tables, and edge cases in references.
6. Add deterministic helpers only when repeated mechanical work exists. Do not script judgment-heavy synthesis.
7. Add eval and behavior examples: positive prompts, nearby negative prompts, expected behaviors, and artifact-shape assertions.
8. Validate locally, patch validator failures once, and report the exact command results and remaining gaps.

Multilingual Handling

• Preserve source-language trigger phrases when they are likely future user wording.
• Keep code, commands, identifiers, product names, model names, citations, filenames, URLs, and technical tokens stable across languages.
• Separate source language from output language. A Cantonese source can produce an English public skill, but the evidence boundary should say what was translated, preserved, or normalized.
• For RTL, CJK, locale-specific punctuation, pluralization, politeness level, or code-switching, move the detailed rules into a reference instead of crowding SKILL.md.

Output format

Source-To-Skill Brief

Source boundary:
Languages and formats:
Root job:
Target users:
Mechanisms kept:
Mechanisms discarded:
Skill shape:
Files to create or patch:
Validation plan:
Open uncertainty:

Mechanism Card

Name:
Source evidence:
Trigger:
User job:
Decision rule:
Procedure:
Output:
Quality signal:
Failure mode:
Skill location:
Keep / merge / discard:

Package Report

Skill name:
Evidence boundary:
Package shape:
Files changed:
Validation run:
Trigger examples:
Negative trigger:
Rollback point:
Residual risks:

Boundaries

• Do not invent details from inaccessible documents, private repos, audio, video, screenshots, or links.
• Do not copy source wording into a public skill except short attributed quotes when licensing and policy allow it.
• Before writing a public package, remove or safely generalize secrets, customer/personal data, raw telemetry, private topology/process/migration state, control knobs, security-sensitive details, and other non-public identifiers. Redaction must preserve the reusable mechanism without making the hidden source reconstructable.
• Do not turn every chapter, anecdote, or example into a rule. Keep only mechanisms that change future agent behavior.
• Do not create a meta skill router or skill family when one procedural skill with modes or a references/ section is enough.
• Do not assume a long body repairs weak discovery metadata: current Codex and Claude select from name and description before loading the body and may shorten or omit descriptions under catalog pressure; verify other runtimes against their own documented behavior.
• Read the target repository's contributing contract and existing package descriptions before adding a new standalone skill; preserve one clear semantic owner and avoid near-neighbour routing collisions.
• Do not make a skill depend on private tools, credentials, or hidden chat context.
• Do not publish, push, or claim benchmark quality without the target repository's validation and delivery gates.

Quality Standard

A finished conversion:

• names what evidence was actually read;
• records the intended audience, sensitivity, license, and publication authority for reused material;
• extracts decisions and failure modes, not only themes;
• gives compact semantic metadata that can route without body context;
• runs without the original source in context;
• includes output contracts and validation signals;
• stores language, examples, and rubrics in references when they would bloat the main file;
• includes positive and negative eval prompts;
• passes structural validation for the target repository;
• reports skipped validation honestly.

When not to use

• Use skill-repository-curator when the job is repository-wide content curation, collision resolution, consolidation, or retirement rather than one bounded conversion.
• Use skill-eval-designer when the package already exists and the primary deliverable is a falsifiable routing/behavior evaluation.
• Do not use this workflow for a plain summary, translation, or knowledge-base note when no reusable procedure and independent trigger/output are required.