Creating a Useful Skill and Automate Repetitive Workflows

Get a skill right and a piece of work you used to do by hand just runs automatically - the UI migration, the bug triage, the setup before every prototype. That's all a skill is: a workflow you teach Bezi once. You describe the steps you'd normally walk it through, Bezi saves them, and the next time that work comes up you run the skill instead of re-explaining anything. Same steps, same order, and no setup. The work you've already figured out runs itself, and your time goes back to building the game.

Bezi ships with six skills built in, covering workflows most Unity developers run into: prototyping a feature, converting your UI to UI Toolkit, documenting your project. But game development has thousands of workflows, and the ones you repeat most are usually specific to your project and how you work. No built-in set will cover them, so we’ve made a short guide to building your own.

What's in a skill

Under the hood, a skill is a folder with a SKILL.md file: a name, a description, and the steps you'd normally walk Bezi through by hand. You don't need to write that file yourself, just describe the workflow in a thread and Bezi drafts it for you, then you refine it from there. Once it exists, you run it with a slash command, or let Bezi recognize the request on its own and run it for you.

How to write a good one

Whether a skill earns a permanent spot in your workflow comes down to four things.

1. Scope it to a workflow you actually repeat

Have you walked Bezi through the same workflow from scratch three times already? If so, that workflow is a great fit for a skill.

Skills reward bounded, repeatable procedures. "Triage a physics bug" is a good one: you run it constantly and it ends somewhere specific. "Fix my game" is not; that's just a conversation. Keep the scope tight. A skill that tries to do everything does nothing reliably.

2. Describing it in detail

The description is the most important line in the file. It's what Bezi reads to decide whether the skill fits what you just asked for. Leave it vague and the skill either never fires or fires at the wrong time.

Bezi writes this line for you, but only as well as what you give it. When you ask for a skill, describe the exact situation that should trigger it and the steps you actually take, not the general topic.

• Vague ask: "make me a skill for physics bugs"

• Specific ask: "make me a skill that triages a physics bug: reproduce it, check the Rigidbody and collider setup, read the relevant FixedUpdate code, and report the likely cause before changing anything"

Give Bezi enough and it writes a description that names the exact trigger and what the skill commits to, so the skill shows up when you need it. Give it too little and it drafts something generic, and you end up with a skill you forget you built.

3. Lock the steps that need locking, leave the rest open

A skill runs the same way every time. That's the whole value. But "the same way" doesn't mean rigid from start to finish. Pin down the order where order matters, and leave room where judgment matters.

Take /debug-physics. The sequence is the point: reproduce, inspect the configuration, read the code, diagnose, then propose a fix. The order stays fixed; what Bezi finds at each step doesn't. You're describing how you investigate, not deciding the answer in advance. "Diagnose before you change anything" is the kind of step worth making non-negotiable.

A few hard rules earn their place here too. Bezi's built-in UI migration skill never deletes your original GameObjects; it deactivates them and waits for you to confirm. Write down the lines you never want crossed, and let Bezi handle the rest.

4. Treat it as living, not one-time setup

Your first version won't be right, and it doesn't need to be. A skill gets better the more you run it.

When a run goes wrong — it skips a step, checks the wrong thing, assumes something you didn't intend — fix it. Describe the change in a thread, Bezi rewrites the skill, and you review the diff before it saves. After a few weeks it matches how you actually work, and it keeps up as your project changes.

The skill you've run twenty times and tweaked as you went beats the one you set up once and forgot about. Keep tuning it.

Skills worth building

If you want to build one now, start from a workflow you already repeat:

• A triage skill for the bug you hit most. Physics desyncs, null refs in one system, UI that lays out wrong. Write down how you track it down before you touch any code.

• A "new content type" skill. The exact steps to add a ScriptableObject-driven item, quest, or enemy, with your folder structure and naming built in.

• A profiler pass. Capture a profile, find the worst frame-time offenders, and propose fixes the way you would by hand.

• A pre-PR check. Run the right tests through the Test Runner, check naming and folders, and summarize the change before you push.

• Your prototype setup. Start from the built-in prototype skill, run it once, then cut it down to your own patterns.

Pick the one you've explained to Bezi most often. Open a thread, describe how you run it, and let Bezi draft the skill. Then run it, watch where it goes wrong, and fix it. That last part is what makes a skill worth keeping.