Levyra Openclaw Orchestrator

Levyra OpenClaw orchestration workflow

Role

OpenClaw coordinates bounded work. It does not replace Levyra requirements, domain skills, coding runtimes, CI, independent review, or owner approval.

Use the existing Levyra worker as the primary implementation/orchestration agent. Use levyra-reviewer for independent review and levyra-ci for CI, PR-state, logs, and validation evidence. Do not add more agents unless a repeated workload has a distinct context, permission, or evidence boundary that these three cannot cover cleanly.

Context economy

Apply levyra-context-efficiency before delegation.

• Primary work keeps requirements, current architecture, root cause, changed files, and focused validation.
• Reviewer handoff contains the requested outcome, latest diff or commit, the smallest relevant surrounding code, invariants, and known test evidence.
• CI handoff contains PR/SHA, required checks, failing job/step, and only the log ranges that determine the conclusion.
• Do not send full chat history, repeated repository orientation, successful repetitive logs, or unchanged files to another agent.
• Expand context only when the receiving agent identifies a concrete unanswered question.
• Keep security, signing, R8, Perfetto, release, protocol, and exact failure evidence raw whenever compression could change the conclusion.

A fresh specialized agent with a compact verified handoff is preferred over carrying a long exploratory session into review or CI diagnosis.

Memory policy

Memory is evidence, not a second source of truth.

Promote only durable, verified information such as recurring failure patterns, stable architecture ownership, validated diagnostic techniques, and explicit owner preferences. Keep transient branch heads, current PR state, CI status, temporary hypotheses, generated logs, secrets, credentials, signing material, and release tokens out of long-term memory.

Use dated memory for current work and MEMORY.md only for durable knowledge. OpenClaw Dreaming may consolidate memory, but every promoted project fact remains subordinate to current repository evidence.

Before delegation

1. Read root and applicable nested AGENTS.md.
2. Read only the relevant sections of docs/project/SPEC.md, docs/project/ROADMAP.md, and docs/project/TASKS.md.
3. Load levyra-project-manager, levyra-context-efficiency, and every matching domain skill required by the task.
4. Inspect current branch, worktree, open pull request, review state, and validation evidence.
5. Confirm the exact outcome, scope boundary, and publication authorization in the current owner request.
6. Stop discovery when enough verified evidence exists to implement or review the requested outcome.

Do not reuse stale branch, PR, review, CI, model-summary, or memory assumptions.

Delegated task contract

Every coding-runtime task must state:

• repository and working directory;
• objective and acceptance criteria;
• matching AGENTS.md files and native skills;
• verified current behavior and root cause or rationale;
• behavior that must remain unchanged;
• prohibited changes;
• expected files or modules;
• focused and broader checks;
• manual checks;
• required delivery evidence;
• whether branch, commit, push, or draft PR creation is authorized.

For levyra-reviewer and levyra-ci, every handoff must also include the exact target SHA and must tell the specialist to use its own workspace ./repo checkout. Parent-agent relative paths and spawnedCwd are context only; they are never the specialist's evidence root. The specialist may fetch refs in its own checkout to resolve the requested SHA, but it must remain read-only.

A reviewer handoff must not assume a PR exists. A CI handoff must not assume GitHub Actions evidence is PR-scoped: when given a SHA, the CI agent must query Actions by that exact SHA and include push-triggered runs before concluding that CI is absent or unverifiable.

Keep the contract compact. Link or name canonical repository files instead of copying large instruction blocks into the handoff.

Execution sequence

1. Use the existing Levyra worker for orientation and implementation.
2. Use one coding runtime for one reviewable implementation phase.
3. Run focused checks and inspect the diff.
4. Run applicable repository gates.
5. Before code is presented as final, run the required code-review stage.
6. Delegate independent latest-diff review to levyra-reviewer with a fresh, bounded handoff that includes the exact target SHA and its own-checkout rule.
7. Return actionable findings to the implementation runtime and re-run affected checks after every material change.
8. Delegate CI, PR-state, and log diagnosis to levyra-ci with the exact target SHA; do not pollute the implementation context with broad CI output.
9. Publish only to an authorized branch/PR or directly to an explicitly authorized target.
10. Return exact status to the coordinator and owner.
11. Stop before merge, tag, release, store upload, or repository-setting changes unless separately authorized for that exact action.