Skills

Skills encode how a recurring task should be done — once — so every execution follows the same proven workflow.

What a skill is

A skill is a named, reusable workflow following the open SKILL.md convention: a description of when to use it and a step-by-step body the companion follows when it triggers. Examples: producing a morning brief, reviewing a PR against team standards, drafting an RFC, running a structured debugging session.

Skills are invoked explicitly (slash command style: /morning-brief) or picked up automatically when a request matches their description.

Find, reuse and adapt

The competency catalog brings together methods supplied by tamag0, methods shared by your company and your own private methods. Results identify their source. Search can continue across multiple pages; an unavailable or incomplete search is not treated as “nothing found”.

Reuse a suitable method as it is, or adapt it into a personal copy. The original stays unchanged, including when you edit your copy later. Supporting templates and reference files travel with the authorized copy. In ordinary conversation, work with the method's name and summary and ask your companion for changes. Advanced instructions remain available in Settings → Competencies.

Create and propose a shared method

Describe the need to your companion. It can help turn recurring work into a private method, without losing the original request. Creating or editing that method does not publish it.

A method may also carry a few descriptive domains, such as requirements analysis or customer support. They describe the work, never assign companions or grant access, and are optional. When shared, these descriptions belong to the reviewed version too.

Sharing is a separate, explicit proposal. The sharing question names the competency and explains that the conversation and its data are not transmitted. You can keep the method private instead. A company administrator reviews the proposed method and decides whether to publish or reject it. Publication starts from the reviewed version; later edits to a separate private copy do not change it. Rejection preserves your work.

Company administrators manage shared methods in the company's Shared competencies page. Company-owned methods require company administration or a new reviewed proposal for changes. An author can still modify, unshare or delete a shared method their companion owns. Editing that shared original changes the version everyone uses, even after an administrator has reviewed or edited it: these rights do not provide a separate private version. To make private changes without affecting others, adapt the method into a personal copy instead. The shared catalog currently offers reuse and adaptation, not direct editing controls. Methods supplied by tamag0 and company-owned publications cannot be directly changed by an individual companion.

Newly published methods become discoverable without replacing people's existing home choices. The next execution refreshes the available methods when a shared version changes. Home widgets are shortcuts, not an access list: a method remains available on request when it is not pinned or after its widget is removed. Onboarding choices and an agent’s specialty do not restrict the authorized catalog. Company permissions and access revocation remain separate.

Competencies in a company context

An invited companion can use the host company's permitted shared methods even when company memory sharing is closed. This does not grant access to other people's private methods or another company's catalog. Availability is checked again when work starts; a revoked placement cannot start a new use of the host's methods.

Core skills out of the box

Engineering companions ship with a library of proven workflows, kept up to date. The full set, by family:

These engineering workflows are starting points, not a fixed set: a company adds its own private or shared methods, and companions can propose new ones from recurring work. A companion's specialty helps suggest relevant methods; it does not lock the user into a smaller catalog.

From a specification to implementation

/refining guides a specification through review, approval and Linear tickets, then presents which tickets can start together and asks whether to launch implementation. If you already explicitly authorized implementation of that scope, it continues without asking twice. You can also stop there and resume later with /implementing-rfcs <RFC URL>.

The delivery plan separates prerequisites needed to start coding from dependencies needed for integrated validation. Independent tickets can progress in parallel within an explicit concurrency limit; a shared prerequisite does not force the entire project to run sequentially. Resuming a workflow reuses existing tickets and implementation threads rather than creating duplicates.

You can pin an implementation model and effort with --model and --effort. The choice is checked against the available provider and that model's supported efforts, including Claude and Codex, then passed to each ticket. Automatic recommendations cover only the profiles supported by your session; other available choices may require manual selection. An unavailable or incompatible explicit choice is reported, not silently replaced.

Starting implementation does not authorize merging pull requests. Merge approval remains an explicit human decision.

Skills follow the companion

Skills work across runtimes — Claude, Codex, Ollama, or OpenAI-compatible — and across surfaces: in the desktop app, and in Claude Code CLI outside the app (see Claude Code CLI).

Related

• Scheduled tasks — skills on a schedule
• Desktop app