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
| Failure | Recovery |
|---------|----------|
| Skill scope overlaps heavily with another skill | Add a clear `When NOT to use` boundary and cross-route |
| Execution path is vague | Add canonical command or workflow path inline |
| `SKILL.md` becomes too long | Move detailed examples to `resources/` and keep navigation in `References` |
| No reliable validation command exists | Use structural grep/awk checks and manual checklist validation |
| User input is underspecified | Make conservative assumptions and list them, unless the target behavior would be unsafe |

### 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.

## Logical Operations

### Actions
| Action | SSL primitive | Evidence |
|--------|---------------|----------|
| Read analogous skills | `READ` | Existing `.agents/skills/*/SKILL.md` |
| Select skill type | `SELECT` | Command/workflow/judgment/reference-heavy classification |
| Infer boundaries | `INFER` | Trigger intents and adjacent skill overlap |
| Write skill file | `WRITE` | New or updated `SKILL.md` |
| Add resources | `WRITE` | `resources/`, `config/`, `scripts/`, or `assets/` |
| Validate structure | `VALIDATE` | Heading and canonical-path checks |
| Report result | `NOTIFY` | Changed files and validation summary |

### Tools and instruments
- `rg`, `find`, `awk`, `sed`, `git diff --check`
- `apply_patch` for manual file edits
-