Reframing as Skill.md
Converts descriptions of automated AI actions, tasks, mechanics, logic, hooks, scaffolding, systems, cognition, architecture, workflows, pipelines, schedules, logic gates, methods, benchmarking, prompts, user preferences/personalization, generative deliverables, payloads, assets, components, products, or any other operational construct into a properly formatted Claude Code SKILL.md file. Use when the user has a process, system, mechanic, or piece of functionality they want packaged as a reusable skill, or asks to "turn this into a skill," "make this a SKILL.md," or "reframe this as a skill.
Reframing as SKILL.md
Takes any input — a workflow, a prompt chain, a scheduling rule, a piece of architecture, a personalization system, a benchmarking method, a generative pipeline, a "hook," an asset spec, whatever — and reframes it into a valid, self-contained SKILL.md file.
Given raw input like:
"I have a cron-like system that re-scores user preference vectors every night and adjusts prompt injection weights for the next day's generations."
Immediately produce:
YAML--- name: rescoring-preference-vectors description: Recalculates user preference vectors on a schedule and adjusts prompt-injection weighting for subsequent generations. Use when personalization signals need periodic refresh or when generation quality drifts from stated user preferences over time. --- # Rescoring Preference Vectors
Run the nightly rescore job, diff against prior weights, apply capped deltas to injection weights.
- Pull latest interaction/feedback signals
- Recompute preference vector per user
- Diff against previous vector, cap max delta (e.g. ±15%)
- Update prompt-injection weight table
- Log change for auditability
Example 1: Input: User favorited 12 sci-fi outputs, skipped 8 romance outputs this week. Output: sci-fi weight +0.08, romance weight -0.05, applied to next injection cycle.
- Cap deltas to avoid whiplash personalization
- Keep an audit trail of weight changes
- Separate "signal collection" from "weight application" as distinct steps
- Don't apply uncapped deltas from small sample sizes
- Don't overwrite weights without versioning/rollback capability
No matter the input category, output follows this same shape.
Progress:
- Identify the core mechanic — is it a schedule, a logic gate, a pipeline stage, a prompt template, an asset spec, a benchmarking method, etc.?
- Name it — gerund-form, kebab-case, ≤64 chars, reflects the action, not the noun (e.g.
scoring-preferencesnotpreference-scores) - Write the description — third person, states what it does + when to trigger it, ≤1024 chars
- Extract the actionable core — strip narrative/backstory, keep only the mechanic: inputs, transforms, outputs, conditions
- Map to skill sections — Quick Start, Workflow (with checklist if multi-step), Examples, Best Practices, Common Pitfalls
- Fill gaps with sane defaults — if the source is vague on thresholds/formats, supply a reasonable concrete default rather than leaving placeholders
- Compress — target ~500 lines; if the source describes multiple distinct mechanics, split into multiple SKILL.md outputs, one per mechanic
| Input type | How to reframe |
|---|---|
| Logic gates / conditionals | Turn into an explicit decision table or if/then Workflow steps |
| Hooks / triggers | Becomes the "Use when..." clause in the description + a "Triggers" subsection |
| Schedules / pipelines | Becomes a numbered Workflow checklist, ordered by execution sequence |
| Prompts / prompt chains | Becomes Quick Start template + variables to fill |
| User preferences/personalization | Becomes a Workflow for signal → transform → applied state, with capping/versioning as Best Practices |
| Benchmarking methods | Becomes Workflow (setup → run → score → compare) + Examples with sample metrics |
| Generative deliverables/assets/payloads/components | Becomes a spec: required fields, format, validation step, example payload |
| Architecture/systems/scaffolding | Becomes a structural Workflow (layers/components in dependency order) + a diagram-in-words if useful |
| Cognition/reasoning methods | Becomes a step-by-step reasoning Workflow with an example trace |
Example 1:
Input: "A benchmarking rig that scores generated images on 4 axes (fidelity, prompt-adherence, novelty, artifact-count) and ranks model checkpoints weekly."
Output: A benchmarking-image-checkpoints skill with Workflow steps (generate fixed prompt set → score 4 axes → weight/aggregate → rank → archive), Examples with sample scores, pitfalls around prompt-set drift.
Example 2:
Input: "Scaffolding that spins up a new agent with default tools, memory store, and a system prompt template."
Output: A scaffolding-new-agents skill with a Quick Start showing the exact file/config layout, a Workflow checklist (tools → memory → prompt → validation), defaults for each piece.
Example 3: Input: Garbled/unclear fragment with no discernible mechanic. Output: Minimal placeholder skill:
YAML--- name: clarifying-vague-mechanic description: Placeholder skill for an unspecified automated mechanic. Use when input lacks enough detail to determine a concrete workflow. --- # Clarifying Vague Mechanic
Restate the intended mechanic in one sentence: trigger → action → output.
- Identify trigger condition
- Identify transformation/action
- Identify output/deliverable
- Prefer one concrete example over abstract description
- One skill = one mechanic. If input bundles several unrelated systems, output several skill files.
- Always convert passive descriptions ("this handles...") into active Workflow steps.
- Prefer concrete defaults (numbers, formats, thresholds) over vague qualifiers ("some," "periodically").
- Keep the "why" (rationale/backstory) out of the skill body — only "what to do."
- If the source uses jargon specific to the user's domain, keep it in the
name/descriptionfor discoverability, but define it plainly in Quick Start.
- Don't write descriptions in first/second person.
- Don't leave name as a noun phrase — always gerund-form.
- Don't produce a skill with no Quick Start — every skill must be immediately actionable.
- Don't merge unrelated mechanics into one bloated skill just because they came from the same input blob.
- Don't ask the user clarifying questions — infer and default instead.