Oma Skill Creator

Skill Creator - SSL-lite Skill Authoring Specialist

Scheduling

Goal

Create, revise, and validate OMA skills using the SSL-lite Markdown structure derived from Scheduling-Structural-Logical skill representation while keeping the result readable, executable, and maintainable.

Intent signature

• User asks to create a new OMA skill, agent skill, specialist skill, or .agents/skills/*/SKILL.md.
• User asks to convert or normalize a skill into the project skill format.
• User asks whether a skill has enough scheduling, structural, logical, reference, or canonical execution detail.
• User mentions SSL-lite, Scheduling / Structural / Logical, skill format, skill template, or skill creator.

When to use

• Creating a new skill under .agents/skills/{name}/SKILL.md
• Updating an existing OMA skill to the SSL-lite format
• Adding Canonical command path or Canonical workflow path to an execution-heavy skill
• Auditing whether a skill is usable by routing, execution, validation, and recovery logic
• Deciding whether detailed examples belong inline or in resources/

When NOT to use

• Installing third-party skills into $CODEX_HOME/skills -> use skill installer
• Creating a Codex plugin bundle -> use plugin creator
• Writing a general project plan unrelated to skill authoring -> use PM Agent
• Editing product code, infrastructure, frontend, backend, or mobile implementation directly -> use the matching specialist skill

Expected inputs

• skill_name: target directory name, preferably oma-{domain}
• skill_goal: capability the skill should add
• trigger_intents: user prompts or domains that should activate the skill
• boundaries: when the skill should not be used and which skill should handle those cases
• execution_model: whether the skill is command-heavy, workflow-heavy, judgment-heavy, or reference-heavy
• Existing files, tools, commands, resources, or standards the skill must preserve

Expected outputs

• A complete SKILL.md using the SSL-lite top-level sections
• Optional resources/*.md, config/*.yaml, scripts/*, or assets/* only when progressive disclosure or deterministic execution requires them
• A validation report with structure checks, routing checks, execution checks, and unresolved assumptions

Dependencies

• Existing OMA skill conventions in .agents/skills/*/SKILL.md
• SSL-lite template in resources/ssl-lite-template.md
• Validation checklist in resources/validation-checklist.md
• Local filesystem and search tools for reading adjacent skills and checking output

Control-flow features

• Branches by new skill vs existing skill update
• Branches by command-heavy vs workflow-heavy vs reference-heavy skill type
• Reads and writes local skill files
• Must preserve user edits and avoid unrelated rewrites

Structural Flow

Entry

1. Identify whether the task is creating a new skill, updating an existing skill, or auditing a skill.
2. Read nearby or analogous OMA skills before choosing wording and structure.
3. Determine the skill type: command-heavy, workflow-heavy, judgment-heavy, or reference-heavy.

Scenes

1. PREPARE: Collect skill purpose, trigger intents, boundaries, inputs, outputs, dependencies, and risk/resource constraints.
2. ACQUIRE: Read analogous skills, existing resources, project conventions, and any user-provided source material.
3. REASON: Decide what belongs inline in SKILL.md and what belongs in resources/, config/, scripts/, or assets/.
4. ACT: Create or update the skill using the SSL-lite template.
5. VERIFY: Run structural, routing, execution, resource, and formatting checks.
6. FINALIZE: Report created/changed files, validation result, and any remaining assumptions.

Transitions

• If the skill performs fragile or repeated commands, include ### Canonical command path inline.
• If the skill is mostly human judgment or investigation, include ### Canonical workflow path inline.
• If detailed examples are long, variant-specific, or optional, move them to resources/ and reference them explicitly.
• If a skill already exists, preserve working content and normalize only what is needed for the target format.
• If the trigger description is too broad, narrow it before writing the skill.

Failure and recovery

Exit

• Success: the skill has the four SSL-lite top-level sections, a canonical path, clear routing boundaries, resource constraints, and validation evidence.
• Partial success: the structure is valid but missing commands, tools, source material, or user decisions are reported.
• Failure: no skill file is written or the blocking ambiguity is explicit.