> For the complete documentation index, see [llms.txt](https://docs.kula.digital/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kula.digital/skills/build-your-own.md).

# Build your own & share with your team

The best way you've found to look at your studio shouldn't live only in your head. Turn it into a **skill** — a saved playbook — and **share it with your team**, so everyone connected to your studio runs it the same way.

You don't need to write code. You describe what you want; the AI writes the skill; you review and publish it.

## Build a skill in three steps

**1. Get the analysis right once.** Work through the questions with your AI assistant until the answer is exactly what you want — the right time window, your own definition of terms, your studio's language.

**2. Ask the AI to save it as a skill.** When you're happy, say:

> *"Turn this into a reusable skill called 'Monday Check-in' so I can run it every week."*

The AI captures the steps and saves the skill to your studio. New skills land as a **draft** first, so nothing goes live to your team until you've looked it over.

**3. Review and publish.** Read the draft, run it once to confirm it does what you meant, then publish it. From that moment it's available to **everyone connected to your studio**.

## Sharing with your team

A published skill is **org-wide**: every AI assistant connected to your studio — yours, your manager's, a coach's — sees the same skill and runs it the same way. You don't send anything around; publishing *is* the sharing.

This is how a studio builds its own playbook: your "Monday Check-in", your "End-of-month review", your "New member 30-day follow-up" — each one captured once and run by anyone.

## Keeping skills good

* **Test before you trust.** Run a new skill on a period you already understand, and check the answer matches what you know to be true.
* **Save a few examples.** You can attach known questions-and-answers to a skill so the AI can check itself against them over time. This is the same quality-check the built-in **Eval Runner** uses.
* **Retire what you outgrow.** If a skill stops being useful, mark it deprecated — it stays in the record but drops out of everyday use.

## Want to go deeper?

Skills can do a lot more — load reference notes, follow a strict procedure, build on each other. The built-in **Studio Ignition** diagnostic is a large example of a multi-step skill set. If you (or a technical teammate) want to author skills in depth, the [developer tools reference](/for-developers/tools.md) documents the skill tools in full.

## Related

* [What skills are](/skills/skills.md) · [The built-in library](/skills/library.md)
* [Your weekly rhythm](/get-started/your-rhythm.md) — a natural home for your own skills.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.kula.digital/skills/build-your-own.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.