Customize: Skills, Custom Agents and Automations
Every team has a rule that lives in one senior engineer's head. Tag every resource with a cost centre. Production security groups need a second reviewer. Check the queue depth before you blame the database.
An agent arrives knowing what good looks like in general. It doesn't know any of that. So people type the rule into the prompt, every time, and the day someone forgets is the day it mattered.
Frontier Investigation Agents are only as useful as their fit with how your team already works. Customize is where that fit lives, and its line is the whole brief: works the way your team works.
Why prompts aren't enough
A prompt lasts one conversation. Whatever context you put in it disappears when the conversation ends, and it differs between the engineer who wrote a careful one and the engineer who typed six words at 3 a.m.
The usual workarounds don't hold. A shared doc of good prompts drifts. One giant workspace instruction gets applied everywhere, including places it shouldn't. A separate bot per team means a separate set of credentials, guardrails and history per bot.
We wanted team knowledge stored once, applied where it belongs, and bound by the same guardrails as everything else. That became three pieces.
01Skills
How to act
Your rules and procedures, attached to Chat, Review, Incident or Assessment.
02Custom agents
Who acts
Your instructions, model tier and language, scoped by the connections you attach.
03Automations
When it runs
Stored instructions started by a schedule, a webhook call or a repository event.
04Guardrails
Same rules
Every write follows the workspace mode and tool permissions, whoever started it.
Skills: how to act
A skill is a workspace instruction package. At minimum it's a SKILL.md file: YAML frontmatter, then Markdown instructions. A .zip package can also carry scripts/, schemas/ and references/ directories, up to 5 MB.
---
name: sg-change-review
description: Apply our security group rules when a change touches production networking
---
## Production security groups
- Flag any ingress rule open to 0.0.0.0/0
- Require a second reviewer for changes in production accounts
- Name the owning team from the resource's tags
You can write one by hand, upload a package, or describe it in plain language and let CloudThinker draft it. The built-in /create-skill command interviews you and does the same.
01Create
Write, upload or describe
By hand, as a .zip package, or drafted by CloudThinker from plain language.
02Enable
On by default
A disabled skill stays saved but is eligible nowhere.
03Attach
Pick surfaces
New skills start on Chat. Add Review, Incident or Assessment where they belong.
04Apply
When relevant
Agents match eligible skills by description. Review always applies its attached skills.
The description is the trigger. Agents choose skills by reading descriptions. A skill without a usable one is listed as broken: it isn't offered in the / picker and the CloudThinker CLI won't install it. A skill that might or might not load is worse than no skill, so this one fails loudly.
Skills share the / picker with commands. Type / and you see your commands, the built-in ones and every enabled skill. When a skill and a command share a name, the skill wins.
Skills aren't the knowledge base. A skill tells an agent how to act. The knowledge base gives it facts to look up, such as runbooks and architecture docs. A skill can point an agent at specific documents.
Custom agents: who acts, with what reach
Every request goes to CloudThinker, the assistant built into each workspace. It's always on and can use every connection. A custom agent sits alongside it with its own name, @mention, role, goal, instructions and connections.
You build one under Settings → Agents, with Create with AI or Build with form. Instructions take up to 4,000 characters. You pick a Model Tier (Light, Pro or Ultra) and a reply Language. Skill Learning decides whether the agent saves new skills from your work automatically (Auto), asks first (Offer) or never does (Off).
Scope comes from connections, not tool toggles. Every agent has the same builtin tools. What a custom agent can reach is the set of connections you attach, up to 64. A database reviewer doesn't need production IAM access, so don't attach it. An agent with no connections turns itself off.
A connection is already the boundary that holds credentials and permissions (see The Agent Never Holds Your Keys). One boundary is easier to reason about than two.
Guardrails don't fork. A custom agent's write actions follow the same workspace Auto Mode setting and tool permissions as CloudThinker. You can't build an agent that steps around them.
Two details to plan for. The @mention is set once and can't be changed. Edits apply on the next message, so in-flight chats finish under the old settings. Customizing agents needs the workspace Admin role, and the number of custom agents depends on your plan, from one on Free to unlimited on Enterprise.
Automations: when it runs
An automation is one set of instructions plus any number of triggers. Whichever trigger fires starts a run, and Run now starts one by hand.
01Trigger
Whichever fires
A schedule, a webhook call, a repository event, or Run now.
02Instructions
Stored once
The same instructions every run, with a webhook body passed in as data.
03Workspace mode
Manual or Auto
Manual pauses on tools that need approval. Auto Mode decides each write.
04Runs view
Every run recorded
Pending, Running, Succeeded, Failed or Required Approval, each linked to its conversation.
Schedule. Daily, Weekly, Monthly, No Repeat, or Custom with a 5-field cron expression. You pick times in your own zone and CloudThinker stores them in UTC.
Webhook. CloudThinker issues a URL and a secret, and shows the secret once. The caller sends it with each request, as a bearer token by default. The request body reaches the agent as data alongside the instructions, so the run can act on what the sender reported. Rotating the secret keeps the URL.
Repository. A push, merge request, comment or pipeline result in a repository connected to Review. Branch filters take globs such as release/*. Comments from the CloudThinker review bot start no run, so an automation never fires on its own output.
Agents can propose automations too. When a piece of chat work is worth repeating, the reply ends with a card naming what would run and when. Enable creates it.
The workspace mode governs every run. It doesn't matter whether a schedule, a webhook or a person started it. In Manual, tools that need approval pause. In Auto, Auto Mode decides each write. A paused run shows Required Approval in the Runs view, so autonomous work never waits silently.
Failing runs stop themselves. After ten consecutive failures, CloudThinker turns the automation off and notifies its owner. Run now still works, so you can debug it.
Honest limits
- Skills apply when relevant, so a vague skill can be passed over. Shorter, focused skills are applied more reliably than long, broad ones. Split by domain.
- Skill instructions cap at 50,000 characters. Names already used by the public skills catalog are reserved.
- Custom cron accepts a single value,
*or a step such as*/15in the minute and hour fields. Lists and ranges there are rejected. - A recurring schedule keeps its local clock time and doesn't shift for daylight saving, so a run can land an hour off across a DST change.
- Bitbucket and AWS CodeCommit send no pipeline event, so pipeline triggers don't fire for them.
How to start
Find the instruction you've typed into more than two prompts. That's your first skill. Keep it attached to Chat, check a few real results, then attach it more widely.
"Create a skill for our tagging rules: every resource needs owner, cost-centre and environment tags."
"Build a custom agent for database reviews that only uses the production Postgres connection and replies in Vietnamese."
"Every weekday at 09:00, summarize yesterday's failed deployments and the errors behind them."
Start a trial or book a walkthrough.