A skill is the durable form of a team's earned playbook. The way you actually review code, ship releases, triage incidents, scope epics, onboard new hires. In Ambience a skill is a first-class memory type. Any teammate's agent can call it by name. The skill loads the right context from the right scopes, redacts what shouldn't leave its boundary, and runs the procedure the way your team does it.
The point isn't to teach the agent a generic best practice. The point is to encode your team's choices: the conventions, the past failures, the decisions, the references. And let any agent in the org invoke them as one named action.
What a skill is
In Ambience, a skill is a memory of type skill. It carries:
A name the agent calls it by, e.g. review-a-pr.
A scope, usually team, sometimes project or org.
A procedure, what the agent does when the skill runs, in the team's voice.
Linked context, the related decisions, conventions, failures, and references the skill loads automatically.
Redaction rules, what gets stripped before any output leaves the boundary.
When an agent calls a skill, Ambience resolves the linked context against the caller's scope grants. The agent never sees memories the caller isn't entitled to read, even if the skill links them.
Skill vs memory
A regular memory (a decision or convention) is information an agent might retrieve in passing. “Here's what we decided about X.” A skill is an actionthe agent takes. “Run our PR review.” Skills are how the team's operating playbook becomes executable, not just citable.
Five skills your team probably already has
The universal worked examples. The skills almost every team has, hand-rolled into Notion pages or tribal knowledge. Captured as Ambience skills, any teammate's agent can run them on day one.
review-a-pr
scope: team
Run the team's review checklist on a diff before a human ever sees it.
Trigger
Someone asks Claude Code: 'review this PR'.
What the agent does
The agent loads the review-a-prskill and walks the diff against the team's actual checklist, not a generic one. It checks typed return signatures the way your team prefers, flags error-handling patterns your team has explicitly rejected before, looks for security antipatterns surfaced by past failure-type memories, and matches naming and comment conventions captured as convention-type memories. Output is a structured review comment shaped like the ones the senior people on your team already write.
Pulls from
· team conventions (naming, formatting, comment style)
· team failures (past bugs the review catches)
· team decisions (architectural choices the diff might violate)
· customer names mentioned in past failure memories
· internal API keys referenced inline
· any tenant DLP-listed identifiers
onboard-a-teammate
scope: team
Get a new hire's agent up to speed on two years of team conventions on day one.
Trigger
A new joiner runs Claude Code on day one. Their agent calls onboard-a-teammate in the SessionStart hook.
What the agent does
The agent pulls the team's active conventions, the most-cited decisions of the last quarter, the failure modes most likely to catch a newcomer, and the references they'll need (deploy runbook, on-call playbook, code review style). It surfaces them in priority order as a single pinned context block. Then it suggests the first three tickets the team has tagged as good first issues. Their first PR is shaped like their tenth.
Walk an on-call through severity, escalation, and runbooks the way your team actually does it.
Trigger
On-call tells the agent: 'PagerDuty just paged me about elevated 5xx in checkout. Help me triage.'
What the agent does
The agent calls triage-an-incident, which loads your team's severity matrix (a convention-type memory), the on-call rotation and escalation order (a reference-type memory pointing at PagerDuty), the relevant runbooks for the affected service, and any past failure-type memories that match the symptom. It proposes a sev-level, drafts the customer-comms message in the team's standard tone, and lists the next three steps the runbook says to take.
Pulls from
· team conventions (severity matrix, comms tone)
· team references (PagerDuty, status page, runbooks)
· team failures matching the symptom signature
· project decisions (recent architectural changes that might be relevant)
Redacts before output
· customer names referenced in past incident memories
· internal credentials or webhook URLs
· tenant DLP-listed identifiers
ship-a-release
scope: team
Run the team's pre-release checklist, version bump, changelog, and deploy gate without anyone having to remember each step.
Trigger
Someone tells the agent: 'I'm ready to release. Walk me through it.'
What the agent does
The agent calls ship-a-release, which loads the team's release-branch convention, version-bump rule (semver or calver, your team's call), changelog format, the deploy gate (e.g. “don't ship Fridays after 3pm” if that's a captured convention), and the post-deploy verification steps. It runs the gate, drafts the changelog, and posts the release notes in the team's standard format. If the team has a recent “rolled back a Friday release” failure memory, that gets surfaced before the gate.
Pulls from
· team conventions (semver vs calver, branch naming, deploy windows)
· team failures (past botched releases)
· team references (changelog template, release-notes channel)
· project decisions (recent feature flags or migration order)
Redacts before output
· customer-specific feature-flag values
· internal deploy credentials
· any DLP-listed identifiers in past failure memories
scope-an-epic
scope: team
Take a Linear or Jira epic from one-line title to a sized, dependency-mapped, acceptance-criteria-shaped ticket the team can actually start.
Trigger
Someone tells the agent: 'Scope the auth-rewrite epic for me.'
What the agent does
The agent calls scope-an-epic, which loads the team's estimation framework (T-shirt sizes, story points, or whatever you actually use), acceptance-criteria template, dependency-mapping conventions, and the time-budget sanity check the team has captured. It pulls related team decision-type memories that constrain the work (e.g. “we use WorkOS, not Auth0”) and failure-type memories that shape the risk model (e.g. “the last auth migration broke SSO for two days”). Output is a structured ticket draft, not a wall of text.
Pulls from
· team conventions (estimation framework, AC template)
· team decisions (architectural constraints relevant to the epic)
· team failures (past migrations that bit)
· project references (Linear board, RFC repo)
Redacts before output
· customer identifiers in past failure memories
· third-party-vendor private terms
· any DLP-listed identifiers
How to create one
Skills are written in plain language and committed via the CLI or the workspace. The author picks the scope, the linked context, and the redaction rules. Team admins approve promotion from personal draft to team, then to org if it generalises.
The shape that works: write the skill the way you'd describe it to a teammate joining the team. Capture the implicit rules. Link to the failure memories that shaped them. Skills age well when they reference the team context that makes them true. Not when they restate generic best practices.
Your team already has these skills.
They're in your senior people's heads, in scattered Notion pages, in PR comments nobody re-reads. Ambience is where they become callable.