> ## Documentation Index
> Fetch the complete documentation index at: https://docs.salesfinity.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Creating Skills

> Three ways to create a skill, the structure that makes one reliable, and the guided Skill Creator flow the AI Companion follows.

There are three ways to create a skill. Pick by how much you already know about the workflow.

| You want to                                    | Do this                                                                                               |
| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Save something you just did with the companion | Say **"save this as a skill"** in the conversation.                                                   |
| Build a skill for a workflow you can describe  | Say **"help me create a skill that…"**, or click "Help me create a skill together" in the Skills tab. |
| Write it yourself                              | Open the Skills tab and click **New Skill**.                                                          |
| Reuse one someone else wrote                   | [Import it](/ai-companion/agent-skills).                                                              |

## The guided flow

When you ask the companion to create or improve a skill, it loads the **Skill Creator** guide, a
platform skill that scripts the whole authoring process, before asking you anything. The flow is
the same whether you start from a conversation or from scratch.

<Steps>
  <Step title="It infers what it can">
    From the conversation and your request, the companion works out the trigger (when should a
    future run reach for this?), the inputs that vary per run, the tools and integrations
    involved, what "done" looks like, and any guardrails. Starting from a conversation, most of
    this is already in the transcript, and it does not re-interview you about it.
  </Step>

  <Step title="It asks only the open questions">
    At most three or four questions, in one round, each with a suggested default. It always
    confirms the trigger and the output, because those decide whether the skill ever gets used
    correctly.
  </Step>

  <Step title="It drafts with the standard structure">
    Goal, inputs, steps, output, guardrails. See [structure](#the-structure-of-a-good-skill)
    below.
  </Step>

  <Step title="It checks its own draft">
    Would a fresh run with no memory of this conversation succeed? Is every step a concrete tool
    call or decision? Does it reference only tools this team can use? Did today's dates or a
    specific contact leak in where a placeholder belongs?
  </Step>

  <Step title="It shows you a preview and waits">
    You see the name, description, and full body, with **Yes, create it** and **Cancel**
    suggestions. Nothing is saved until you confirm.
  </Step>

  <Step title="It saves and offers a test">
    The skill appears in the Skills tab, marked as generated. The companion offers to run it on a
    real example right away, and suggests a routine if the workflow is recurring.
  </Step>
</Steps>

## The structure of a good skill

A skill is instructions for a future run that has none of today's context. Write it so that run
succeeds first time.

**Name** says what the skill does, not how. "Monday pipeline review", not "HubSpot query plus
summary v2". No dates, no instance data.

**Description** is the one line the companion matches on. Say when to use it and what it
produces: "Weekly pipeline summary from HubSpot deals, posted as a table. Use for 'pipeline
review' or Monday check-ins."

**Content** follows this shape:

```markdown theme={null}
## Goal
One or two sentences: what a successful run produces.

## Inputs
What to ask the user (or infer) at run time, with defaults.
- time range — default: last 7 days

## Steps
Numbered, concrete, in order. Name the actual tools. Put decision
points inline ("if no deals match, say so and stop — don't broaden
the filter silently").

## Output
The exact shape of the result — format, columns, links to include,
where it gets delivered.

## Guardrails
What this skill must not do; when to stop and ask the user.
```

Leave a section out only when it is genuinely empty. Keep the body tight; a skill is instructions,
not documentation.

## Example

A skill a manager might save after doing this once by hand:

```markdown theme={null}
---
name: Monday pipeline review
description: Weekly summary of open HubSpot deals by stage with the
  week's call activity per deal, posted as a table. Use for "pipeline
  review", "Monday check-in", or "what moved this week".
---

## Goal
A table of open deals showing stage, amount, owner, days in stage,
and the number of dials and connects to the deal's contacts in the
last 7 days.

## Inputs
- time range — default: last 7 days
- owner — default: the whole team

## Steps
1. Ask the HubSpot specialist for open deals, with stage, amount,
   owner, and the date the stage last changed.
2. For each deal, get the associated contacts.
3. Pull call history for those contacts in the time range and count
   dials and connects per deal.
4. If there are no open deals, say so and stop.

## Output
One table sorted by amount descending. Columns: Deal, Stage, Amount,
Owner, Days in stage, Dials, Connects. Link each deal to HubSpot.
End with three deals that had zero dials this week.

## Guardrails
Read-only. Never change a deal stage or amount.
```

## Checklist before you save

* The trigger is in the description, in the words a user would actually say.
* Every step names a real capability the team has connected. A skill that says "check Salesloft"
  on a team without Salesloft will fail on step one.
* Inputs that vary per run are inputs, not hardcoded values.
* The output section says exactly what to deliver and where.
* Anything the skill must never do is in guardrails, so an unattended routine run honors it.