Laizy
Use Laizy as the control plane around existing coding agents, not as a replacement for them.
Core workflow
- 1. Create or refresh a local milestone plan file for the target repo.
- Use a local
IMPLEMENTATION_PLAN.md by convention.
- Keep it out of git unless the user explicitly wants it committed.
- If the repo does not have actionable milestones yet, use the planner-needed bootstrap template in
{baseDir}/references/planner-bootstrap.md.
- 2. Bootstrap the run once with
laizy start-run. - Use
laizy supervisor-tick as the source of truth for every later decision. - Read the emitted bundle and follow the bounded next action instead of improvising the next step in chat.
Commands
Bootstrap a run:
CODEBLOCK0
Evaluate the next action:
CODEBLOCK1
Decision map
Read {baseDir}/references/decision-map.md for the full artifact map. The short version is:
- Read the emitted
planner.request document.
- Spawn or steer a planner worker to author/repair the plan.
- If the run was bootstrapped in
needs-plan mode, re-run
start-run after the planner lands the first actionable milestone queue.
- Read the emitted implementer contract.
- Execute exactly one bounded milestone.
- Read the emitted recovery plan.
- Resume safely without widening scope.
- Run the emitted verification command.
- Record the result before marking a milestone complete.
- Disable or pause the watchdog.
- Stop the loop.
Runtime-profile rules
Use the runtime profile emitted by Laizy when spawning planner, implementer, recovery, or verifier workers.
- - Prefer the selected
model, thinking, and reasoningMode when the platform allows them. - If the exact model is rejected by account policy, fall back to an allowed model while preserving the same bounded contract and intended thinking level.
- In shared/group chat surfaces, keep reasoning visibility conservative by default.
Repo hygiene
Treat generated run artifacts as local state:
- - keep
state/runs/ out of git - keep
state/verification/ out of git - keep generated
.tgz files out of git - keep local maintainer plan files out of git unless the user explicitly wants them committed
References
- - Read
{baseDir}/references/decision-map.md for emitted artifact names and what to do for each supervisor decision. - Read
{baseDir}/references/planner-bootstrap.md when you need a clean planner-needed starting point for a new multi-step run.
Laizy
将Laizy作为现有编码代理的控制平面，而非替代品。
核心工作流程
- 1. 为目标仓库创建或刷新本地里程碑计划文件。
- 按惯例使用本地IMPLEMENTATION_PLAN.md文件。
- 除非用户明确要求提交，否则不要将其纳入Git管理。
- 如果仓库尚无可执行的里程碑，请使用{baseDir}/references/planner-bootstrap.md中的规划器引导模板。
- 2. 使用laizy start-run一次性引导运行。
- 将laizy supervisor-tick作为后续所有决策的权威依据。
- 读取生成的绑定包并遵循限定的下一步操作，而非在聊天中即兴决定下一步。
命令
引导运行：
bash
laizy start-run \
--goal <用户目标> \
--plan IMPLEMENTATION_PLAN.md \
--out state/runs/<运行名称>.json
评估下一步操作：
bash
laizy supervisor-tick \
--snapshot state/runs/<运行名称>.json \
--out-dir state/runs/<运行名称>.supervisor
决策映射
阅读{baseDir}/references/decision-map.md获取完整的工件映射。简要版本如下：
- 读取生成的planner.request文档。
- 生成或引导规划器工作节点编写/修复计划。
- 如果运行以needs-plan模式引导，则在规划器完成首个可执行里程碑队列后重新运行start-run。
- 读取生成的执行器合约。
- 精确执行一个限定的里程碑。
- 读取生成的恢复计划。
- 在不扩大范围的情况下安全恢复。
- 运行生成的验证命令。
- 在标记里程碑完成前记录结果。
- 禁用或暂停监控程序。
- 停止循环。
运行时配置文件规则
在生成规划器、执行器、恢复或验证工作节点时，使用Laizy生成的运行时配置文件。
- - 在平台支持的情况下，优先使用选定的model、thinking和reasoningMode。
- 如果账户策略拒绝使用特定模型，则回退到允许的模型，同时保持相同的限定合约和预期的思考级别。
- 在共享/群聊界面中，默认保持推理可见性保守。
仓库卫生
将生成的运行工件视为本地状态：
- - 将state/runs/排除在Git管理之外
- 将state/verification/排除在Git管理之外
- 将生成的.tgz文件排除在Git管理之外
- 除非用户明确要求提交，否则将本地维护者计划文件排除在Git管理之外
参考
- - 阅读{baseDir}/references/decision-map.md了解生成的工件名称以及每个监督决策对应的操作。
- 当需要为新的多步骤运行提供清晰的规划器引导起点时，阅读{baseDir}/references/planner-bootstrap.md。
