Skills

Create and maintain reusable Agent capabilities that encode how a recurring operational task should be done.

A Skill is a reusable operating method for the Agent. Most Skill building happens from the Agent itself: give it representative work, examples, rules and corrections, and let the Agent write or update the Skill for review.

Use Intelligence → Skills as the canonical inventory, version-history and direct-edit surface.

The current Skills inventory in Intelligence.

One object, two doors

The Agent is where Skills are usually built and corrected. Intelligence is where the resulting Project Skills are listed, inspected, versioned and edited directly. A Skill published from the Agent is not a separate kind of Skill; it is the same maintained Project capability shown here.

For the complete builder method, including common Skill patterns and design guidance, see Skills and operating methods.

Common shapes you will see

Typical Skill shapes include:

• document generation from maintained templates and structured data;

• recurring data checks and exception lists;

• staged work with human checkpoints;

• connectors that wrap a system into reusable named operations;

• file intake and structured extraction;

• form/questionnaire completion from maintained facts;

• tender or bid responses;

• constraint-checked option generation;

• supporting report rendering and durable correction/rules loops.

These are reusable work shapes, not product templates a builder can currently select from a blueprint catalogue.

What a Skill contains

A useful Skill can define the intended outcome, rules and checks, authorised system actions, reference material, Project files, Tables, Workflows and the points where the Agent should bring a person into the work. That can include Agent-native tools such as Ask user for structured input or Propose a call to offer the user a live Call with Agent from the web Agent. The user starts the live call by pressing Call. It can also specify the presentation surface: an in-stream HTML widget for a compact interactive result, or an HTML artefact for richer standalone output.

The Connection remains separate: the Skill can use an authorised Connection, but the Skill does not own or grant that credential.

Skill detail, components and approval

The current Skill detail surface uses a two-pane layout: editable Skill fields on the left and Preview, Tests and Versions on the right.

Skills can attach components such as Workflows, files, credentials, Tables and Knowledge. Where the component can perform an action, the Skill surface can expose an Ask for approval control.

The Agent can also propose files and existing Project data as part of a Skill build. Review the proposed components as part of the draft gate; accepting the Skill means accepting the maintained capability it contains.

A current Skill detail view with Components and approval controls alongside Preview, Tests and Versions.

This Skill-level approval is separate from connection-level action policy and from explicit Workflow Request Decision or Request Input nodes.

Tests and evaluations

Eligible Project builders can open Tests from Skill detail and Skill proposal views to exercise representative cases during the build/review loop. The surface follows the normal Project and acting-user permission boundary.

Use tests to reduce uncertainty about known cases, then make an explicit review/publish decision. Test evidence does not silently publish or rewrite the live Skill, and operator feedback remains evidence to inspect rather than an automatic instruction change.

The current Tests surface on a Skill, showing representative cases and their pass or fail results before review and publishing.

Invocation, versions and publishing

When Allow the agent to invoke this skill automatically is enabled, the Skill is available for automatic use. When it is off, the Skill is hidden from the Agent's automatic Skill list and is invoked explicitly with /skill-name.

Skills also expose an enabled state, version information and a Publish action. Agent-authored updates are reviewed as proposed changes before they replace the live version; version history provides the maintained record of those published changes.

Treat these as capability lifecycle controls. An edited draft is not equivalent to a silently self-modifying production Skill.

Practical lifecycle

representative task → expected outcome → Agent writes or updates Skill → review → run representative cases → correct → review diff → rerun previously-good cases → publish → improve from evidence

Corrections are evidence for a reviewed improvement, not permission for the production Skill to rewrite itself silently.