Reusable skills and contracts

A reusable skill is a method with a defined purpose and explicit inputs and outputs. It should be usable independently and within a larger workflow. It should also be small enough that its behavior can be understood and evaluated.

Extract capabilities, not job titles

Consider three activities: comparing a document with a playbook, preparing a risk briefing, and recording an approved result in a repository. They have different inputs, evaluation criteria, and tool requirements. They are good candidates for separate capabilities.

The associate and partner are accountable participants in the process. Making one agent for each lane would mix their responsibilities with the mechanisms used to support them.

View the relationship model (Mermaid)

flowchart TB
    A["Associate responsibility"] --> C["Document comparison skill"]
    P["Partner responsibility"] --> B["Risk briefing skill"]
    P --> H["Human approval task"]
    C --> B
    B --> H
    H --> I["Repository integration"]

Before generating any of these, look for one that already exists. Delivery checks the domain library first and reuses a reviewed method where it fits, wraps an installed skill's existing method where it has no reviewed contract, and generates a new skill only when nothing fits.

The briefing skill can be reused in another workflow with a different senior reviewer. The repository integration can be reused without containing legal reasoning. The approval task retains its human authority in both cases.

A contract makes the handoff explicit

In software, a data contract defines the shape and meaning of information passed between components. It is not a client engagement contract. For a research capability, it might require a question, facts, forum, and two dates as inputs; the result might require a memo, authorities, coverage status, and limitations.

A schema can reject an output that lacks a required field. It cannot establish that a cited paragraph supports the asserted proposition. Contract validation and substantive verification are separate checks.

Two kinds of binding

View the relationship model (Mermaid)

flowchart TB
    N["Workflow task: research Singapore law"] --> S["Method binding<br/>Which skill and exact version?"]
    S --> M["Installed Singapore research skill"]
    N --> C["Tool binding<br/>Which actual host capability is available?"]
    C --> T["Observed search, source-reading and workspace tools"]
    M --> E["Active host performs the bounded task"]
    T --> E

The ecosystem binding names the installed method and its pinned revision. The runtime binding identifies actual available tools, or an approved human fallback, for the capabilities that method requires. A skill name does not create an authenticated API endpoint.

Before execution, the host must inspect what is actually available. A declared requirement such as source-read is not evidence of access. A synthetic test binding is not a substitute for a live tool.

Keep matter data out of the method

Reusable packages contain instructions, schemas, helpers, and approved reference material. Client names, documents, facts, and matter-specific dates arrive as runtime inputs. The task envelope should supply only what the task needs.

This distinction serves both reuse and review. A reviewer can inspect the method separately from the matter. A change to facts should not produce a new reusable skill containing those facts. A change to behavior, by contrast, should produce a new version so existing runs remain pinned to the method they began with.

Generation is only part of engineering

The compiler can assemble prompts and package supported helpers. It does not give generated prose permission to introduce arbitrary executable routing code. Conditions use a restricted structure, and unsupported process constructs fail compilation.

The generated result still needs evaluation: realistic examples, missing data, difficult exceptions, unsuitable outputs, and tool failures. The next chapter explains how a team turns that work into a manageable delivery plan.