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.

Specialized agents

Primary Levyra worker

Owns implementation and orchestration. It may edit only within the requested scope and may delegate review/CI work. It must never ask another agent to bypass repository publication controls.

levyra-reviewer

Independent and read-only by default. It reviews the latest requested diff and surrounding ownership from its own ./repo checkout. A PR is optional: commit reviews must resolve the requested SHA and reconstruct the local patch when no PR exists. It reports severity, confidence, exact location, triggering scenario, consequence, smallest compatible fix, and missing regression coverage. It does not implement its own findings or certify stale commits.

levyra-ci

Read-only by default. It inspects PR/SHA state, required checks, Actions jobs, exact failing steps, logs, review state, and reproducible validation evidence from its own ./repo checkout. For a SHA, it checks Actions runs keyed by exact head_sha, including push runs, before reporting that CI is absent. It separates stale runs from current-head evidence and returns only actionable state changes.

Tool policy

The primary Levyra worker may use repository, command, Git, build/test, GitHub PR, review, and CI tools needed for the current authorized task.

levyra-reviewer and levyra-ci should use read-only filesystem policies and agent-scoped read-only sandboxes when the VPS supports them. They may use shell commands only for inspection and non-mutating validation.

Keep personal messaging, email, calendar, unrelated browser accounts, system-wide administration, release credentials, signing material, and repository settings outside Levyra agents unless the owner explicitly requires and authorizes a narrowly scoped action.

Recurring audit

A twice-daily levyra-ci audit may inspect open PRs, required CI, unresolved review threads, and stale branches. Use isolated light-context runs so routine monitoring does not load the full workspace memory. The audit is read-only and must not edit code, create branches, push, merge, release, or change settings.

Use scripts/setup-openclaw-levyra.sh to provision or refresh this profile on the OpenClaw VPS. The script preserves an existing levyra-worker or levyra primary agent and adds only the specialized reviewer and CI agents.

Review rules

• A reviewer must inspect the latest diff and surrounding code.
• CodeRabbit is a signal, not the source of requirements.
• The implementation agent does not independently certify its own work.
• Every finding needs severity, confidence, exact location, triggering scenario, consequence, smallest compatible fix, and missing regression coverage.
• Stale findings are closed only after checking the current commit.
• Remaining findings require an evidence-backed explanation.

Status vocabulary

Use these states precisely:

• planned;
• edited;
• locally validated;
• committed;
• pushed;
• pull request opened;
• CI passed;
• independently reviewed;
• merged;
• released.

Never collapse several states into done.

Final handoff

Return:

• delegated agents and runtimes used;
• final scope;
• files changed;
• checks and exact results;
• blocked or skipped checks;
• review findings and resolution;
• branch and commit;
• pull request URL and current state;
• manual checks still required;
• explicit statement that merge and release did or did not occur.