Adopt a useful capability, then compose further

Choose one operation to make explicit

A practical first step is an operation that appears in several places: an application action, API endpoint or agent tool. Define its input, result and expected behavior, then connect the existing implementation. The first-operation guide and minimal contract example provide source-guided starting points. Check their execution and package status before treating them as a runnable setup.

Choose an evaluation that can teach you something.Explore a situation · 3 ways to look closer

Keep the existing application. Make one operation explicit, then decide what the next useful proof would be.

Which situation sounds closest?

A CONCRETE SITUATION

Start with behavior you can compare.

An existing account lookup already returns a useful result to an API consumer.

What changes

The operation gains an explicit input, result, errors and ownership boundary.

What stays explicit

Its business implementation can remain in place.

FOLLOW THE CONSEQUENCE

Compare the current route with the new binding using the same valid and invalid cases. Widen the scope only after the difference is understood.

CONTINUE WITH THE DETAIL

Follow the first operation Adopt ContractSpec in an existing codebase Test the promise at the boundary

Where this explanation comes from

An authored situation, grounded in the linked source guides. Choosing a case explores its expected responsibilities; it does not execute an operation.

Adopt ContractSpec in an existing codebase Test the promise at the boundary

Choose a situation to inspect its explanation.

The API already works

A CONCRETE SITUATION

Start with behavior you can compare.

An existing account lookup already returns a useful result to an API consumer.

What changes

The operation gains an explicit input, result, errors and ownership boundary.

What stays explicit

Its business implementation can remain in place.

FOLLOW THE CONSEQUENCE

Compare the current route with the new binding using the same valid and invalid cases. Widen the scope only after the difference is understood.

An agent needs access

A CONCRETE SITUATION

A second entry point makes consistency observable.

An operation already used by the application needs a tool interface.

What changes

Tool discovery and transport handling are added around the registered behavior.

What stays explicit

The host still supplies identity, validation, policy and provider dependencies.

FOLLOW THE CONSEQUENCE

Exercise the actual API and MCP bindings. Compare meaningful error codes and effect counts rather than expecting identical wire payloads.

A rule is duplicated

A CONCRETE SITUATION

Make the invariant the center of the evaluation.

A required reason or approval rule is repeated across several interfaces.

What changes

The shared declaration makes the intended obligation visible to each consumer.

What stays explicit

Business logic and trusted runtime enforcement must still be implemented and tested.

FOLLOW THE CONSEQUENCE

Choose one denied request that would expose a bypass. Show that it cannot enter the handler through either selected entry point.

Reuse the next layer when it earns its place

Once the behavior is clear, explore the blocks that address the next concrete need: an interface, a provider adapter, a workflow or feature composition. Keep existing code where it still serves the product. The existing-codebase guide explains how to approach adoption without assuming a wholesale rewrite.

Use source and documentation together

Resolve examples and references against the package versions you actually use. Installation and release channels distinguish source snapshots from published packages. Follow the repository on GitHub for the implementation, and agent-readable documentation for the coding-tool path. Source access and public distribution are separate questions. Establish the availability of a required component before building a dependency on it.

Give an agent a coherent slice of the system.Trace the mechanism · 3 ways to look closer

An agent is asked to change one operation. A useful context packet keeps the task, source identity and execution responsibilities together.

What does the agent need to do?

A CONCRETE SITUATION

Start with orientation and a bounded reference.

The task names a capability but not the package that owns it.

01 / Orient

Read the relevant area and task context.

What changes

An area overview and package overview narrow the source set.

What stays explicit

A package listing does not establish registry availability or permission to edit it.

FOLLOW THE CONSEQUENCE

Choose the relevant package and source identity, then follow the exact manual or structured source data.

CONTINUE WITH THE DETAIL

Open the agent index Browse package overviews Use the docs with coding agents

Where this explanation comes from

An authored situation, grounded in the linked source guides. Choosing a case explores its expected responsibilities; it does not execute an operation.

Use the docs with coding agents

Choose a situation to inspect its explanation.

Find the relevant piece

A CONCRETE SITUATION

Start with orientation and a bounded reference.

The task names a capability but not the package that owns it.

Orient — Read the relevant area and task context.
Select — Identify the package and its declared purpose.
Inspect — Follow its imports, dependencies and source links.

What changes

An area overview and package overview narrow the source set.

What stays explicit

A package listing does not establish registry availability or permission to edit it.

FOLLOW THE CONSEQUENCE

Choose the relevant package and source identity, then follow the exact manual or structured source data.

Propose a change

A CONCRETE SITUATION

Keep declared behavior, implementation and host separate.

The agent needs to adjust an operation used by an API and a tool.

Task — State the intended behavior and relevant constraints.
Source — Pin the guide, contract and owning runtime references.
Proposal — Identify consequences and the checks that would test them.

What changes

The context packet should include the contract, owning implementation, relevant consumers and selected version.

What stays explicit

Documentation lookup does not authorize repository writes, provider actions or deployment.

FOLLOW THE CONSEQUENCE

Ask for exact source links and a reviewable proposal with assumptions stated. Apply the actual work permissions separately.

Review the result

A CONCRETE SITUATION

A confident explanation still needs the relevant check.

The agent returns code or a command that appears plausible.

Verify sources — Check that the proposed APIs belong to the selected release.
Exercise behavior — Use the owning implementation and intended entry point.
Report scope — Separate authored snippets, source assertions and observed execution.

What changes

Review its sources, version alignment and the expected runtime case.

What stays explicit

Citing a guide does not establish that the proposed change worked.

FOLLOW THE CONSEQUENCE

Run the owning checks and a meaningful allowed or denied path in the intended environment. Preserve the actual scope of the result.

Source & scope

Proposed page for lssm.tech, based on the existing source narrative at bcc79fcc. Source describes intent and scope; it does not independently qualify a deployed feature.

Inspect the existing source ↗

Adopt a useful capability, then compose further

What is the smallest useful adoption?

Choose one behavior

Choose one operation to make explicit

Start with behavior you can compare.

Reuse the next layer when it earns its place

Use source and documentation together

Start with orientation and a bounded reference.

Make room for your context.

Your context

Choose a starting point

Support the way you begin and return

Reading comfort

Choose your language

Search the website

Find something to explore.

A few places to go deeper

Look before you leave

Stay with the context

Open the possibilities

A separate button for a closer look