Omni Skill Creator

A skill for creating new skills from teaching videos and validating what it creates.

At a high level, the process of creating a skill goes like this:

• Perceive the video — read references/perceiver.md and perceive the teaching video, building a timestamped event log (video_events.md) as you go.
• Decide what you want the skill to do and roughly how it should do it
• Write a draft of the skill, along with a media plan for multimodal assets
• Run validate_skill (L1 structural check) before proceeding to evals
• Create a few test prompts and test the skill with them
• Review the results both qualitatively and quantitatively according to the selected feedback mode
  • While the runs happen in the background, draft quantitative assertions if there aren't any; in human-feedback mode explain them to the user, and in agent-self-iterate mode record their rationale in the iteration analysis
  • In human-feedback mode, present each test case's outputs and benchmark metrics to the user; in agent-self-iterate mode, inspect the same artifacts yourself without inventing human feedback
• Turn evidence-backed improvements into a proposal; apply them only when the affected test cases can be rerun
• Repeat the measured pass when the selected feedback mode calls for another revision
• Expand the test set and try again at larger scale when the workflow warrants it

Your job when using this skill is to turn the supplied teaching video or demonstration into a new skill. Help the user narrow down what the skill should do, perceive the recording to ground it, write a draft, write the test cases, run them, and present the evidence. Begin by reading references/perceiver.md and perceiving the recording into video_events.md; if that timeline was already produced earlier in the same conversion, continue from it rather than repeating the read.

Of course, you should always be flexible and if the user is like "I don't need to run a bunch of evaluations, just vibe with me", you can do that instead.

Then after the skill is done (but again, the order is flexible), you can also run the skill description improver, which we have a whole separate script for, to optimize the triggering of the skill.

Cool? Cool.

Communicating with the user

Users of this skill range from non-developers who have just opened a terminal to seasoned engineers, so read the context cues and pitch your wording accordingly. For calibration: "evaluation" and "benchmark" are borderline but usually fine; "JSON" and "assertion" want real evidence the user knows them before you use them unexplained. When in doubt, define the term in a clause and move on.

Creating a skill

Capture Intent

Start by understanding what the user wants the skill to do. For this skill the primary source is usually a teaching video or demonstration — the video_events.md timeline (and its highlights lines) is where you read off the demonstrated workflow: the steps and their order, the tools/UI used, and the corrections or gotchas the presenter surfaced. A prior conversation can be a secondary source (e.g., they say "turn this into a skill" about something you just did together). Either way, the user may need to fill the gaps, and should confirm the intent before you proceed.

1. What should this skill enable you to do?
2. When should this skill trigger? (what user phrases/contexts)
3. What's the expected output format?
4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.

Interview and Research

Proactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out.

Check available MCPs - if useful for research (searching docs, finding similar skills, looking up best practices), research in parallel via subagents if available, otherwise inline. Come prepared with context to reduce burden on the user.

Bound exploratory debugging. After two materially different failed attempts to resolve the same non-blocking fact, record the uncertainty and the best reversible verification step, then continue drafting. Do not spend the authoring budget perfecting behavior in an unavailable application; reaching a complete, source-grounded first draft is more valuable than exhausting the context before any skill exists.