Mastering Workspace Skills: The Key to a Truly Autonomous AI Operator

Every Monday, someone pastes the code review standards into the AI again. Every incident, someone re-describes the runbook. Every weekly report, someone re-specifies the format: which columns, which projects, how long the summary should be. The AI does a decent job each time, and forgets all of it by the next conversation.

That's the automation equivalent of writing the same email template from scratch every time you send it.

The fix isn't a smarter model. It's an AI that remembers how your team works and applies it without being asked. That's what Workspace Skills are, and this post covers how they work, how the AI picks one, and how to write skills that actually get used.

Why prompt libraries and wikis don't stick

Teams have tried to solve this before. The usual attempts break for structural reasons.

Prompt libraries need someone to remember them. A shared doc of "good prompts" only works if the person at the keyboard knows it exists, finds the right one and pastes it. At 2 a.m., nobody does.

Wikis describe; they don't execute. The runbook in Confluence says what to check. A human still has to read it, interpret it and do it, and the wiki drifts from reality the moment nobody's looking.

Onboarding doesn't scale. New hires learn the conventions by getting things wrong in review. The unwritten rules stay unwritten.

Every conversation starts cold. Without a persistent procedure, each request is a fresh negotiation about format, scope and standards. The output varies with whoever wrote the prompt.

I've watched this pattern at every team size. The first three months with a new tool are productive, then entropy sets in. People forget the conventions, and the "standard process" becomes whatever the on-call remembers.

What a skill is

A skill is an instruction manual you hand to the AI once. From then on, whenever a relevant request comes in (a code review, an incident report, a weekly status update) the AI reads the right skill, follows the procedure and delivers output in exactly the format you defined. No per-request configuration, no prompt templates, no "let me explain how we do things here" for the hundredth time.

CloudThinker's Skills Hub offers 1000+ pre-built, composable skills in three categories:

01Public

Built-in toolkits

PDF, DOCX, XLSX and PPTX work. Zero setup, always on.

02Connection

Unlocked by tools

Link AWS, GitHub, Jira, Slack or Datadog and the matching skills switch on.

03Custom

Your workflows

Runbooks, review standards and report formats your team writes once.

Three kinds of skills. Custom Workspace Skills are where team knowledge becomes executable.

Public Skills are built-in toolkits for universal tasks: PDF processing, DOCX generation, XLSX analysis, PPTX building. Zero setup, always on.
Connection Skills are purpose-built for your stack: AWS, GitHub, GitLab, Jira, Slack, Datadog and dozens more. Link a tool through Connections and the matching skills unlock automatically.
Custom Workspace Skills are the ones you build: your incident runbooks, code review standards, reporting formats or any repeatable workflow, encoded into how the AI operates.

Skills overview showing Custom Workspace Skills with skill management interface

Most teams start with Public Skills, add Connection Skills as they link tools, then build Custom Skills as they spot workflows worth encoding. The Hub's 1000+ starting points cover Kubernetes operations, database management, security compliance and more.

Here's what that looks like for a new developer. She types "Review my PR before I push to main." Within seconds, the AI checks it against your branching rules and naming conventions, flags missing unit tests against your coverage threshold, and formats the result the way your team expects. She didn't configure anything. She didn't know a skill was running. That's institutional knowledge made executable: not a wiki page nobody reads, but procedure built into the tool everyone uses daily.

How the AI decides which skill to use

You never tell the AI which skill to run. On every message, CloudThinker runs a silent matching step:

01Read

Intent

Your message is read for what you are trying to get done.

02Match

Descriptions

Every enabled skill description is checked against that intent.

03Load

Instructions

The matching skill's full instructions enter the working context.

04Run

Workflow

The steps execute and the output follows the format you defined.

What happens on every message. You never name the skill; the description does the routing.

It reads your message and recognizes the intent.
It scans the descriptions of every enabled skill: Public, Connection and Custom.
If one matches, it pulls that skill's full instructions into its working context.
It runs the workflow with no further input from you.

So you just talk. "Review my login component" and /frontend-code-review kicks in on its own. "What happened with the production alert last night?" and /incident-analysis activates. Skills are applied proactively, not invoked by hand, and that's the main difference from a prompt library: the AI is the routing layer, and your team just works.

It also explains why the description matters more than anything else you write. The instructions only run if the description matched first.

Creating your own Custom Skill

There are two paths. Both produce the same thing: a SKILL.md that the AI reads and follows. The Skills Framework covers the full specification.

Method A: Build with AI (recommended)

Describe what you want and the AI writes the skill.

Open Skills from the sidebar and click New Skill.
Select Create with AI (labelled Create with CloudThinker in newer builds).
Describe your workflow in plain language.
The AI drafts a SKILL.md with frontmatter and instructions. Review the draft and click Save.

New Skill dropdown showing Create with AI, Write skill instructions, and Create with Template options

"Create a skill called weekly-status-report. Whenever I ask for a weekly report, read my recent commits from the last 7 days, format them into a markdown table grouped by project, and add a 2-sentence executive summary at the top."

It's the fastest path from idea to a working skill. Teams have converted whole runbooks this way in under an hour.

Method B: Write it yourself

When you want precise control over trigger conditions, guardrails and output, write it by hand.

Open Skills from the sidebar and click New Skill.
Select Write skill instructions.
Fill in the Name: letters, digits, hyphens and underscores, no spaces, for example frontend-code-review.
Write the Description. This is the trigger logic; the AI reads it to decide when to activate. The form lets you skip it, but a skill without a description can't be selected and won't load.
Write the Instructions: the step-by-step logic the AI follows once activated, in Markdown.
Click Save.

Write skill instructions modal with Skill name, Description, and Instructions fields

A worked example

Here are the three fields filled in for an incident write-up skill, laid out the way they read together in the skill file:

---
name: incident-report
description: Use when the user asks for an incident summary, a postmortem
  draft, or "what happened" with a production alert or outage. Not for
  routine status updates.
---

1. Identify the incident window from the alert or the user's message.
2. Pull the triggering alert, related alerts in the same window, and any
   deploys or config changes in the hour before.
3. State the impact: affected services, user-facing symptoms, duration.
4. Give the root cause if confirmed; otherwise list open hypotheses with
   the evidence for and against each.
5. List follow-up actions with an owner placeholder for each.

Output: a Markdown document with the headings Summary, Impact, Timeline,
Root cause, Follow-ups. Timeline is a table (time UTC, event, source).
Keep Summary under 60 words. Change nothing; this skill only reads.

Read it the way the AI does. The description says when to fire and, as important, when not to. The steps are numbered, so every run checks the same things in the same order. The output section removes guesswork about format. And the last line sets a guardrail.

Three rules for skills that actually work

01Rule 1

Specific trigger

The description is the IF statement. Name the requests that should fire it.

02Rule 2

Numbered steps

Sequential instructions give predictable runs. Prose gives guesses.

03Rule 3

Explicit output

A table, a checklist, a Slack message: say which, and what goes in it.

What separates skills that get used from skills that gather dust.

After working with teams across engineering, DevOps, security and finance, these are what separate skills that get used from ones that gather dust.

1. Make the description specific. It's your activation logic, and vague descriptions misfire or never fire.

Weak: "Use this for code reviews."
Strong: "Trigger when the user asks to review React or TypeScript code, requests a PR checklist, or mentions checking component performance."

2. Break instructions into numbered steps. The AI follows sequential logic well. Prose creates ambiguity; steps create predictability. For a review skill:

Check for missing error handling.
Verify variable naming follows the camelCase convention.
Flag any function longer than 30 lines.
Output findings as a GitHub-ready markdown checklist.

3. Define the output format explicitly. A Markdown table, a Confluence template, a Slack message, a JSON object: say which, and what goes in it. The more precise the output spec, the more often your team can use the result without editing it.

Skills versus the old way

	Prompt library or wiki	Workspace Skills
How it's triggered	Someone remembers it and pastes it	Matched from the description on every message
Who benefits	Whoever knows it exists	Everyone in the workspace, including new hires
Consistency	Varies with who wrote the prompt	Same steps, same format, every run
Keeping it current	Drifts from reality quietly	One place to edit; the next run uses the new version
Tools and data	Copy-pasted into the chat	Connection Skills reach the linked tools directly

The deeper difference is that a skill is procedure, not documentation. A wiki tells a person what to do. A skill is what the AI does, and it shapes the output for whoever asked, whether or not they knew the procedure existed.

Skills that only read (reports, reviews, summaries) can run freely. A skill that changes something in production, like a remediation runbook, runs within Auto Mode, so you decide what runs on its own and what waits for approval.

Start with the Hub, then make it yours

The fastest start isn't a blank page. Browse the Skills Hub: with 1000+ pre-built skills across Kubernetes, databases, CI/CD, security, observability and cost optimization, one probably does 80% of what you need already. Fork it, adapt the instructions to your environment and deploy.

Browse the Skills Hub for skills in your domain.
Customize the instructions to your team's standards and tools.
Deploy it from Customize → Skills in your workspace.

Then ask for what you need, in plain words:

"Create a skill that reviews Terraform pull requests against our tagging policy and flags any resource missing an owner or cost-center tag. Output a checklist I can paste into the PR."

"Which of our custom skills fired this week, and on which requests?"