Agent 开发
使用 Lenso Skill、Scaffold、Check 与 Lenso Console 状态，和 Coding Agent 协作开发。
Lenso 通过公开 Skill、明确 Manifest、生成合约、Owner-local Check 与配置的 Console Service URL，为 Coding Agent 提供受约束工作流，不需要自定义 Agent Runtime。
当人类或编码 Agent将产品创意转变为产品时，请使用此路径 主机、链接模块、服务支持的模块或 API 集成。
安装技能
在要求代理构建主机之前安装公共Lenso技能包或 模块：
npx skills add LioRael/lenso如果您在本地结账处工作，相同的技能文件位于
Lenso 存储库中的 skills/。复制或注册这些技能目录
您的代理配置的技能文件夹，然后从 lenso-start 开始。
公共技能路径
| 目标 | 技能 | 第一个命令或来源 |
|---|---|---|
| 澄清模糊的商业想法 | lenso-business-planning |
选择第一个有用的切片 |
| 选择正确的公共路径 | lenso-start |
路由到主机、链接模块、服务支持模块或 API 客户端 |
| 组合或演进生成的业务应用 | lenso-app-composition |
检查当前的 lenso app --help |
| 创建可重用的能力包 | lenso-app-composition |
检查当前的 lenso capability --help |
| 创建 Host 应用脚手架 | lenso-starter-host |
lenso host init <dir> |
| 构建 Rust 模块 | lenso-module-authoring |
lenso module create <name> |
| 构建进程外服务模块 | lenso-service-authoring |
lenso service create <name> --lang ts |
| 构建或改进 Console Surface | lenso-console-surface-authoring |
检查当前 Console Module 包和所属 Module 声明 |
| 使用 Lenso API | lenso-api-client |
contracts/openapi/app-api.v1.yaml |
| 构建独立权威 Service | lenso-autonomous-service-authoring |
先验证当前 GA Support Manifest |
| 演进 Contract | lenso-contract-evolution |
盘点生产者、消费者和已提交制品 |
| 设计 Durable Workflow | lenso-durable-workflow |
定义不可变版本和稳定标识 |
| 提取 Linked Module | lenso-module-extraction |
运行当前 Extraction Check |
| 诊断事故 | lenso-incident-recovery |
恢复前收集精确诊断记录 |
| 准备或恢复发布 | lenso-reviewed-release |
读取所属仓库的发布流程 |
公共技能包位于Lenso存储库的skills/目录中。
Agent 循环
- 从可检查的最小业务切片开始。
- 选择 Host、Linked Module、Service-backed Module 或 API Client 工作。
- 使用 CLI Scaffold，不手工构建形态。
- 实现一项有用能力。
- 添加一项可运行 Check；能力未接入时，它必须失败。
- 打开配置的 Console Service URL，确认 Module 状态可见。
- 报告命令、Check 结果与 Lenso Console 状态。
公开产品切片从这个 Prompt 开始：
Build a support ticket module for a Lenso app.预计路由是：
lenso-start -> lenso-business-planning -> lenso-app-composition -> 实现 skill -> checks -> Console Service 根地址对于可重用切片，通过能力包进行路由：
lenso capability init -> lenso capability library add -> lenso capability fit -> lenso app compose --pack -> lenso agent task --for-capability -> checks -> Console Service 根地址Prompt 结构
为代理提供具体的模块结果，而不是通用的框架任务：
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 Console Service 根地址
- leave one smoke check这为代理提供了足够的边界，以避免发明平台。
按路径检查
| 路径 | 最低有用检查 |
|---|---|
| 主机首发 | cargo check --bins |
| Capability Pack | lenso capability fit <pack> --repo-root . 加上生成的 App Composition |
| Rust Module | Manifest 或 Smoke Check，以及配置的 Console Service 状态 |
| Service-backed Module | 所属 Service Contract Check 与已组合应用 Binding |
| 合约/API 工作 | 所属仓库的生成与新鲜度检查 |
| 架构敏感的后端工作 | 所属仓库的架构检查 |
检查应该是小型的、局部的，并且与能力相关。只编译 当更改应该出现在Lenso Console中时，通过是不够的。
Console 状态
使用配置的 Console Service URL 确认已连接 System 看到了这项工作：
- Modules 显示 Module、Manifest 与精确回执绑定的 Surface 状态。
- Services 显示 Provider、Workload 与 Adapter Connection 细节。
- Stories 显示由精确 Story Module 贡献的相关记录。
- Workload Operational State 与 Connection State 保持独立。
不要越过这些边界
- 在所有权边界确定之前，不要将模糊的想法拆分为微服务 真实的。
- 在真正的模块需要它之前，不要构建通用的 CRUD 框架。
- 不要交叉导入另一个模块的内部结构。
- 当公共 CLI、crate、npm 时，不需要克隆框架 monorepo 包装或技能适合。
- 不要把 Agent-ready 当作自主部署承诺。Agent 仍需留下 Check 与运维人员可见 的状态。