Meta Skill Generator
Turn a user's workflow brief into a concise, production-ready SKILL.md. Prefer shipping a minimal useful skill over an ornate one.
Default to English unless the user explicitly asks for another language.
Goal
Create or update skills that:
- trigger on the right requests
- encode only task-specific knowledge Codex would not already know
- use the lightest structure that still keeps execution reliable
Intake
Collect only the minimum inputs needed to design the skill:
- what job the skill should do
- what kinds of user requests should trigger it
- what output the skill should help produce
- whether the task needs
scripts/,references/, orassets/ - any required tone, constraints, frameworks, or file formats
If the brief is incomplete, infer sensible defaults and note assumptions briefly after the draft instead of blocking.
Workflow
- Distill the request into a one-sentence mission.
- Choose the simplest structure that fits:
- workflow-based for stepwise procedures
- task-based for multiple operations
- reference-based for policies or specifications
- capability-based for multi-feature systems
- Write frontmatter:
name: short, stable, hyphen-casedescription: explicit trigger conditions; start withUse when...
- Draft the body with only the sections the skill actually needs. Common sections:
# Title## Goalor## Overview## Intake## Workflowor## Task Guide## Resource Use## Output Contract## Quality Bar
- Add optional resources only when justified:
scripts/for deterministic or repeated automationreferences/for large or variant-specific materialassets/for templates or files consumed by outputs
- If the user asks for a full skill package, also add
agents/openai.yamlwith short UI text and a default prompt that explicitly mentions$skill-name.
Authoring Rules
- Keep the skill lean. Do not explain basics Codex already knows.
- Optimize for progressive disclosure. Put bulky details in
references/only if they are truly needed. - Be concrete about triggers, inputs, outputs, and failure modes.
- Prefer direct instructions over theory.
- Do not create auxiliary docs such as
README.md,CHANGELOG.md, or setup notes unless the user explicitly asks. - Use examples only when they remove ambiguity.
- Match guidance strictness to task fragility:
- high freedom for broad creative work
- medium freedom for preferred patterns
- low freedom for fragile operations
Updating Existing Skills
- Preserve sections that already work well and only tighten what is vague, repetitive, or misleading.
- Improve the
descriptionfirst if the trigger conditions are weak. - Remove generic filler before adding new sections.
- Do not expand scope unless the user clearly wants a broader skill.
Description Pattern
The description should answer:
- what the skill does
- when to use it
- which user phrases, tasks, or scenarios should trigger it
- what deliverable it helps produce
Preferred pattern:
description: Use when users ask to ...
Output Modes
When the user asks for only a SKILL.md, produce a complete SKILL.md and keep everything else optional.
When the user asks for a full skill package, produce:
SKILL.mdagents/openai.yamlif UI metadata would help- only the minimal extra directories required by the workflow
Minimal Template
---
name: skill-name
description: Use when users ask to ...
---
# Skill Title
## Goal
State the job in 1-2 sentences.
## Intake
List only the inputs needed to do the job well.
## Workflow
Give the execution steps or decision rules.
## Resource Use
Explain when to read or run bundled files.
## Quality Bar
State the constraints, failure modes, and expected output quality.
Quality Check
Before finalizing, verify that:
- the
nameis short and stable - the
descriptionwould actually trigger the skill - the body is concise and actionable
- optional resources are justified
- the draft matches the user's requested language and output scope