## Key Takeaways

- **A prompt that only one person can run is not a process.** It is that person's private shortcut, and it leaves when they go on holiday.
- **A skill is the written version of how your team does a job.** Steps, sources, format, edge cases, saved once and run by anyone by name.
- **The best first candidate is boring and weekly.** If somebody rebuilds the same report every Monday from memory, that is the one.
- **Skills now behave like files, not folklore.** Since 2026-08-08 you can upload a skill as a folder or zip, download one with its full files, edit its SKILL.md in place, and start it by typing / and picking it from the command list, per the [Viktor changelog](https://viktor.com/changelog).
- **Every skill needs an owner and a review date.** Unowned instructions rot quietly and produce confidently outdated work.
- **Write it after a real run, not before.** The corrections you made this week are the content of the skill.

Your ops lead has a message she sends Viktor every Monday morning. It pulls last week's numbers from three systems, ignores the two campaigns that are always miscategorized, formats the table the way your CFO likes it, and lands in the leadership channel before the 10am call. It took her four rounds of corrections in April to get right. It works perfectly.

Then she takes a week off, somebody else tries to run the Monday report, and the output is wrong in ways nobody notices until the call. The knowledge was never in the tool. It was in her sent messages.

That is the gap a shared skill closes. Not a smarter model, not a bigger prompt. A written, named, reusable version of the job that anybody on the team can start and everybody gets the same result from.

![A personal prompt versus a shared skill](/images/blog/how-to-turn-a-recurring-task-into-a-shared-skill/prompt-vs-skill.webp)

## What is a shared skill?

**A shared skill is a written procedure your AI employee follows, saved in the workspace so anyone can run it by name.** It holds the steps, the systems to read, the format of the output, the exceptions, and the things that are never allowed. It is the difference between explaining a job and having a job description.

The mechanics are ordinary on purpose. A skill is a folder of text with one main file that explains when to use it and how the work runs. Because it is text, it can be reviewed like a document, corrected in place, and handed to a new hire on their first day.

| Personal prompt | Shared skill |
| --- | --- |
| Lives in one person's message history | Lives in the workspace, visible to the team |
| Runs when they are online | Anyone can run it by name |
| Improves when they remember to fix it | Improves when anyone corrects it, for everyone |
| Gets rebuilt from memory after two months | Gets read, updated, and dated |
| Tribal knowledge | Written procedure |

This is a different thing from memory. Memory covers what your AI employee has picked up about you: your accounts, your format preferences, the correction you gave last week. A skill is a repeatable job it can perform. If you want the distinction in full, we wrote it up in [memory and SOPs](https://viktor.com/blog/how-to-give-your-ai-employee-memory). The short version: memory keeps the tone right, a skill makes the whole deliverable repeatable.

## Which recurring task should you turn into a skill first?

Pick the one that is boring, weekly, and currently trapped in one head. Three tests, and a task that passes all three is your first skill:

- **It repeats on a calendar.** Weekly report, monthly close checklist, quarterly funder update, every-new-client setup.
- **It has a known-good output.** You can point at last month's version and say "like that".
- **Somebody has already corrected it into shape.** The corrections are the valuable part. If nobody has ever run it, you are writing fiction.

Strong first candidates we see in real workspaces: the Monday performance summary, new-client onboarding setup across your tools, the weekly pipeline hygiene sweep, the month-end reconciliation checklist, and the recruiter's candidate summary format. Weak candidates: anything that needs a judgment call every time, anything where the output has no agreed shape, and anything that touches a system your team is still arguing about.

## How do you actually write it?

Run the job once with a human watching, then dictate the skill from what happened. In practice that means four steps.

**Step one: do the real run and keep the corrections.** Ask for the deliverable in plain language and correct the output until it is right. Those corrections are the spec.

```prompt
@Viktor build the weekly performance summary for last week: spend and
results from Google Ads and Meta Ads, revenue from Stripe, exclude the two
brand campaigns, table first then three bullets on what changed. Post it
here for me to check.
```

**Step two: ask for the skill in the same thread, while the context is live.**

```prompt
@Viktor save how we just did that as a shared skill called weekly-perf-summary.
Include the sources, the campaign exclusions, the table format, the three
bullet rule, and the note that anything unreconciled gets flagged instead of
guessed. Show me the SKILL.md before you save it.
```

**Step three: read it like a document, not like output.** Names of systems correct? Exclusions written down? Does it say what to do when a number does not reconcile? Does it say who approves before anything is posted outside the team? Fix that text now, because you are writing it for the colleague who has never done this job.

**Step four: have somebody else run it cold.** Not the author. If a second person gets the same result without asking a question, you have a skill. If they need to ask anything, the answer belongs in the file.

## What changed recently, and why it matters

Skills used to be something you built and trusted. As of the 2026-08-08 release notes on the [Viktor changelog](https://viktor.com/changelog), they behave like files your team owns:

- **Upload a skill as a folder or zip**, validated file by file before it lands, so a process you wrote outside the tool can come in whole.
- **Download any shared skill with its full files**, which means you can read it, diff it, or keep a copy with your other documentation.
- **Admins can edit any text file in place, including SKILL.md**, and edits take effect on the next turn. No rebuild, no re-teaching.
- **Type / in the composer** and your workspace's shared skills appear alongside system commands, so running the Monday report is picking it by name instead of remembering the prompt.

The last one sounds cosmetic and is not. A procedure nobody can find is a procedure nobody runs. Putting the team's skills in the same list as the system commands is what turns a library into a habit.

![The lifecycle of a shared skill](/images/blog/how-to-turn-a-recurring-task-into-a-shared-skill/skill-lifecycle.webp)

## Who owns a skill, and how do you stop it rotting?

Give every skill one named owner and a review date, the same way you would with a document your auditors might read. Unowned instructions are how a workspace ends up producing confidently outdated work months after a system was replaced.

A lightweight discipline that survives real teams:

1. **One owner per skill**, written in the file. Usually whoever ran the job before it was written down.
2. **A review date**, also in the file, and a monthly sweep of anything older than a quarter.
3. **Corrections go into the file, not just into the thread.** When somebody fixes an output, the fix belongs in the skill or it will be fixed again next month.
4. **Retire loudly.** When a process dies, delete the skill. Half-true procedures are worse than none.
5. **New hires read skills, not shoulders.** Point them at the skill library on day one and let them run the job under review.

This is ordinary management applied to a written procedure, which is the point. The same delegation habits that make a new joiner productive are the ones that make skills work, and we wrote that up in [how to manage an AI coworker](https://viktor.com/blog/how-to-manage-an-ai-coworker).

## Where does this go wrong?

Four failure modes, all of them avoidable and all of them common.

**Writing the skill before the first real run.** You end up with a description of how you imagine the job works. The version written after four corrections is the one that survives.

**One giant skill that does everything.** A file covering reporting, onboarding, and invoicing is a file nobody reads and nobody can correct safely. One job, one skill.

**No approval line.** If the skill produces something that goes to a customer, a board, or a funder, the file has to say who approves before it leaves. Review-first is a default worth writing into the procedure so it does not depend on the mood of the day.

**Nobody checks the output any more.** A skill that has worked for three months earns a spot-check, not blind trust. Systems change, categories shift, and a broken source usually shows up as a plausible number. Keep the checking habit from [how to verify your AI employee's work](https://viktor.com/blog/how-to-verify-your-ai-employees-work), and remember that recurring jobs [die quietly](https://viktor.com/blog/why-automations-die-quietly) rather than loudly.

## What does a good skill library look like after a month?

Small. Five to ten skills, each covering a job somebody used to do by hand, each with an owner, each run by more than one person. That is a better outcome than forty half-written files, and it is achievable in a month if you write one skill per real run instead of holding a documentation workshop.

The test is not how many skills you have. It is whether the Monday report still lands correctly during a holiday week, and whether a new hire can produce your standard deliverable in week one. If both are true, the process has left the individual and joined the team.

## Frequently Asked Questions

### What is the difference between a skill and a prompt?

A prompt is one request. A skill is a saved procedure, stored in the workspace with the steps, sources, format, and exceptions, that anyone can run by name and get the same result from.

### How is a skill different from AI memory?

Memory covers what your AI employee has picked up about your team: preferences, facts, and past corrections. A skill is a job it can repeat end to end. Memory keeps answers consistent, skills make whole deliverables repeatable.

### How long should a skill be?

Long enough that a colleague who has never done the job could follow it, short enough that its owner will actually reread it. One job per file, the real exceptions written down, no essay.

### Who should own the skills in a workspace?

Whoever owns the underlying process. Reporting skills belong to whoever signs off the reports, onboarding skills to whoever owns onboarding. Admins can edit any shared skill in place, so a bad instruction is a five-minute fix rather than a rebuild.

### Can we bring a process we already documented elsewhere?

Yes. Since the 2026-08-08 release, a skill can be uploaded as a folder or zip and is validated file by file before it lands, so an existing runbook can move in as-is and be corrected from there.

### How does someone run a shared skill?

Ask for it by name in the channel, or type / in the composer and pick it from the list of shared skills and system commands.

### What if the skill produces something wrong?

Correct the output, then correct the file. A fix that lives only in the thread will be needed again next month, which is the single most common reason a skill library stops being trusted.

---

**Viktor is an AI employee that lives in Slack, connects to 3,200+ integrations, and does real work for your team.** [Add Viktor to your workspace -- free to start →](https://viktor.com/?utm_source=blog&utm_medium=cta&utm_campaign=how-to-turn-a-recurring-task-into-a-shared-skill)