Reusable skills

A skill makes the partnership operational: you define and review a repeatable way of working, ContextStream matches it to the right situation, and the assistant applies it within the capabilities and permissions of the current client.

What a skill is

A named set of instructions for a job you do more than once — the release procedure, the way you write migrations, the review checklist for a sensitive area.

Two ways they run: matched to relevant work automatically, or invoked directly by name.

Why not just a document

A document is read when someone remembers it exists. A skill is applied — matched to the work in front of it and followed without being asked. For "how we do X here", that difference is the whole point.

Making one

Say "make that a skill" after working something out. Ask "show me the release skill" to inspect it and "run the release skill" to use it.

Give it a clear name, a description of the outcome, the complete instructions, and phrases that should activate it. A skill can also declare the runtime, tools, filesystem, network, or interface capabilities it expects. That lets a client detect a missing requirement before it starts the workflow.

Save a skill as a draft while it is being tested. Make it active when the instructions and triggers are safe enough to match real work.

Turn an auth near-miss into a preflight

Suppose an authentication change almost ships with the wrong middleware order, and an internal stack trace nearly appears in a client update. Save an “auth-change preflight” skill that tells a connected assistant to:

1. retrieve current auth decisions and matching lessons before suggesting a change;
2. read the middleware and rate-limit runbooks rather than reconstructing the procedure from source alone;
3. inspect the affected request path, callers, and tests;
4. require the rate-limit, middleware-order, and documentation checks named by the project;
5. stop when a required check or capability is unavailable;
6. prepare an internal handoff and, when needed, a separate client-safe capsule that excludes credentials, environment values, internal IDs, raw logs, and unrelated customer context.

Trigger it on specific work such as “change auth middleware,” “rotate signing keys,” or “prepare the client incident handoff.” Do not trigger it on every mention of authentication.

Dry-run the skill after creating it. The preview should show the intended steps and report missing requirements before anything changes. If the current client lacks a runtime or project connection, use a suggested repair only when it stays inside the declared requirement and the user's permissions. Otherwise stop with the missing capability named.

Importing what you have

If your conventions are already written in CLAUDE.md, a Codex skills file, Cursor rules, Aider instructions, Markdown, JSON, or a supported skill bundle, import them rather than retyping them. Review the result: one large rules file may be better as several focused skills with different trigger phrases.

Skills can also be exported as Markdown, JSON, a portable skill bundle, or a client-specific rules format. Export is useful for review and portability; the workspace record remains the synchronized source until you deliberately move that source elsewhere.

Writing one that fires

Automatic matching works from the description and trigger phrases, so be concrete. "Deployment stuff" matches nothing in particular. "Releasing a new version of the API service, cutting a tag, updating the changelog" matches when it should.

Team skills

A personal skill follows you without changing how anyone else works. A team skill is a decision about how the workspace works, available to authorized members. A public skill can be shared more broadly when it contains no private project assumptions.

That is a strong lever and worth using sparingly—three focused team skills beat thirty overlapping ones. Sharing changes who can discover and run the workflow; it does not grant the workflow access to data the caller cannot already reach.

Updating and retiring one

Update a skill when the workflow is still the same but its instructions, triggers, or capability requirements changed. Supersede it when a new skill replaces the old workflow. The retired version stops matching automatically while its history still explains what changed.

Delete only when the record should disappear rather than remain as retired history.

Preview and repair

A dry run shows what a skill would do without carrying out its actions. Use it after import, after widening triggers, or before sharing a workflow with the team.

When a required capability is missing, supported clients can report the gap and either suggest or apply an allowed repair policy. A repair should solve a declared requirement; it should not silently broaden network, filesystem, or tool access.

If it doesn't work

It never fires on its own. Vague triggers. Rewrite them as the phrases someone would actually use, or invoke it directly.

It fires when it shouldn't. Too broad. Narrow the triggers.

A teammate doesn't have it. It's file-based and in a repository they haven't got, or it's personal rather than workspace-scoped.

An old and new skill both fire. Supersede the old skill rather than leaving two active versions with overlapping triggers.

It fails halfway through. Inspect its declared requirements and preview the run. The current client may not provide a runtime, connection, or permission the skill expects.

Next

• Lessons
• Sharing context with a capsule
• Instruction files
• How the agent partnership works