Agent Development

Use Lenso skills, scaffolds, checks, and Lenso Console status to develop with coding agents.

Lenso is agent-ready because the workflow has rails: public skills, explicit manifests, generated contracts, focused checks, and the configured Console Service URL verification. It does not require a custom agent runtime.

Use this path when a human or coding agent is turning a product idea into a host, linked module, service-backed module, or API integration.

Install the skills

Install the public Lenso skill pack before asking an agent to build a host or module:

npx skills add LioRael/lenso

If you are working from a local checkout, the same skill files live under skills/ in the Lenso repository. Copy or register those skill directories with your agent’s configured skills folder, then start with lenso-start.

Public skill routes

Goal	Skill	First command or source
Clarify a vague business idea	`lenso-business-planning`	choose the first useful slice
Pick the right public path	`lenso-start`	route to host, linked module, service-backed module, or API client
Compose or evolve a generated business app	`lenso-app-composition`	inspect the current `lenso app --help`
Create a reusable capability pack	`lenso-app-composition`	inspect the current `lenso capability --help`
Scaffold a host app	`lenso-starter-host`	`lenso host init <dir>`
Build a Rust module	`lenso-module-authoring`	`lenso module create <name>`
Build an out-of-process service module	`lenso-service-authoring`	`lenso service create <name> --lang ts`
Build or improve an operator surface	`lenso-console-surface-authoring`	inspect the current Console Module packages and owning Module declaration
Consume Lenso APIs	`lenso-api-client`	`contracts/openapi/app-api.v1.yaml`
Build an independently authoritative Service	`lenso-autonomous-service-authoring`	verify the current GA Support Manifest first
Evolve a Contract	`lenso-contract-evolution`	inventory producers, Consumers, and committed artifacts
Design a Durable Workflow	`lenso-durable-workflow`	define the immutable version and stable identities
Extract a linked Module	`lenso-module-extraction`	run the current extraction check
Diagnose an incident	`lenso-incident-recovery`	collect exact diagnostic records before recovery action
Prepare or recover a release	`lenso-reviewed-release`	read the owning repository’s release process

The public skill pack lives in the skills/ directory of the Lenso repository.

Agent loop

Start from the smallest business slice that can be verified.
Pick host, linked module, service-backed module, or API-client work.
Scaffold with the CLI instead of hand-building the shape.
Implement one useful capability.
Add one runnable check that fails if the capability is not wired.
Open the configured Console Service URL and confirm the Module status is visible.
Report the command, check result, and Lenso Console status.

For the public product slice, start from this prompt:

Build a support ticket module for a Lenso app.

The intended route is:

lenso-start -> lenso-business-planning -> lenso-app-composition -> implementation skill -> checks -> the Console Service root URL

For a reusable slice, route through a capability pack:

lenso capability init -> lenso capability library add -> lenso capability fit -> lenso app compose --pack -> lenso agent task --for-capability -> checks -> the Console Service root URL

Prompt shape

Give the agent a concrete module outcome instead of a generic framework task:

Build a support ticket module for a Lenso app.

First slice:
- tickets have title, status, priority, requester email, and assignee
- operators can list tickets and assign one
- escalation is a runtime function
- the module is visible in the Console Service root URL
- leave one smoke check

This gives the agent enough boundaries to avoid inventing a platform.

Checks by path

Path	Minimum useful check
Host starter	`cargo check --bins`
Capability pack	`lenso capability fit <pack> --repo-root .` plus the resulting app composition
Rust module	a manifest or smoke check plus the configured Console Service status
Service-backed module	owning Service contract checks plus the composed app binding
Contract/API work	the owning repository’s generation and freshness checks
Architecture-sensitive backend work	the owning repository’s architecture check

The check should be small, local, and tied to the capability. A compile-only pass is not enough when the change is supposed to appear in Lenso Console.

Console status

Use the configured Console Service URL to confirm that the connected System sees the work:

Modules shows the Module, manifest, and exact receipt-bound Surface state.
Services shows Provider, Workload, and Adapter connection details.
Stories shows correlated records contributed by the exact Story Module.
Workload operational state remains separate from connection state.

Keep out

Do not split a vague idea into microservices before ownership boundaries are real.
Do not build a generic CRUD framework before a real module needs it.
Do not cross-import another module’s internals.
Do not require cloning the framework monorepo when the public CLI, crate, npm package, or skill fits.
Do not treat agent-ready as a promise of autonomous deployment. The agent still has to leave checks and operator-visible status.