Automate coding-to-review handoff for OpenAB task threads

[vixenclawsastraagent]

Summary

OpenAB should support an AI SDLC handoff flow where a coding task thread can automatically start a separate PR review task thread after the coding agent finishes and the PR is ready for review.

The handoff must choose a reviewer from a configured review-agent pool, and the selected reviewer must not be the same agent that performed the coding task.

Motivation

Scott's current OpenAB workflow uses multiple Discord-bound coding agents:

• Astra: 1491367148583391242
• Scarlet: 1491377922953711677
• Lilith: 1491682772618575912
• Nova: 1491682897135141019

PR review work currently goes to a smaller reviewer pool:

• Astra: 1491367148583391242
• Nova: 1491682897135141019

The manual flow works, but it is repetitive:

1. Scott asks one OpenAB agent to perform a coding task.
2. OpenAB opens a coding task thread.
3. The coding agent finishes the code work and prepares or updates a PR.
4. Scott manually opens another OpenAB review task by mentioning a different reviewer agent.

Example from issue #462:

• Coding task thread: https://discord.com/channels/1489873082201018419/1543663735162404927
• Review task thread: https://discord.com/channels/1489873082201018419/1543673164742140005

The desired improvement is not just better thread naming. The main request is for OpenAB to make the coding-to-review handoff more automatic and less dependent on Scott manually selecting and invoking the reviewer every time.

Expected Behavior / Desired Outcome

OpenAB should support a configurable handoff policy for coding-to-review flows.

Required behavior:

• WHEN a coding task thread reaches a configured "ready for review" signal, DO resolve the associated issue number, PR number or PR URL, and coding agent identity, THEN decide whether a review handoff should be created.
• WHEN a review handoff is created, DO choose the reviewer from the configured reviewer pool, THEN ensure the reviewer is not the same logical agent as the coding agent.
• WHEN the coding agent is also in the reviewer pool, DO exclude that coding agent from reviewer selection, THEN pick another eligible reviewer or report that no eligible reviewer exists.
• WHEN the coding agent is not in the reviewer pool, DO choose from the full reviewer pool, THEN create exactly one review task for that PR unless explicitly retriggered.
• WHEN OpenAB opens a review thread, DO title the thread with a machine-readable status prefix and issue/PR context, THEN keep the thread discoverable as a review task.
• WHEN review is in progress, DO use a title/status prefix such as 🔄, THEN update the title/status to ✅ only when the review task actually completes successfully.
• WHEN OpenAB cannot resolve the PR, issue, or eligible reviewer, DO post a clear failure message in the coding thread, THEN do not silently create an ambiguous review task.

For Scott's current workflow, the routing examples are:

• Astra coding -> Nova review
• Nova coding -> Astra review
• Scarlet coding -> Astra or Nova review
• Lilith coding -> Astra or Nova review

The exact reviewer selection policy can be deterministic round-robin, least-recently-used, explicit config priority, or another simple policy, but it must be documented and stable.

Scope and Constraints

• This is an OpenAB framework capability, not only a one-off Scott deployment script.
• The first supported platform can be Discord, because the motivating workflow is Discord thread-based OpenAB.
• The implementation should be opt-in. Existing OpenAB users should not get automatic review handoffs unless they configure the policy.
• The "coding agent" and "review agent" comparison should use stable configured logical agent IDs, not only display names.
• OpenAB should not assume every task is a coding task. The handoff should trigger only from explicit configured signals.
• Review thread creation must be idempotent per source coding thread / PR pair, so a retry does not create duplicate review threads.
• ✅ must mean the review task completed successfully. Timeouts, failed PR resolution, or reviewer launch failures must not write ✅.

Possible config shape, for discussion:

[handoffs.pr_review]
enabled = true
trigger_signals = ["ready_for_review"]
review_agents = ["astra", "nova"]
require_distinct_agent = true
thread_title_template = "{status} #{issue} PR #{pr} review by {reviewer}"

Runtime implementation note:

• The handoff policy should be implemented in the OpenAB runtime that already knows the Discord thread, owning bot/session, and agent config. Any persistent dedupe state should be stored in OpenAB's existing session/thread state store, or in a clearly documented new runtime state store if the existing one is insufficient.

Environment notes:

• [verified] OpenAB already creates one thread/session per Discord task in this workflow.
• [verified] The current Scott workflow uses four coding agents and two review agents as listed above.
• [assumed] OpenAB has or can add a reliable agent/session metadata field for the logical agent ID that created or owns the coding task thread.
• [assumed] The "ready for review" signal may come from an explicit agent directive, PR URL detection, GitHub metadata, or a configured command. The implementation should choose one documented initial contract instead of relying on fuzzy natural-language parsing only.

Acceptance criteria:

• OpenAB exposes an opt-in config for PR review handoff policies.
• A coding task can trigger a review task automatically when the configured ready-for-review signal is emitted.
• The selected review agent is never the same logical agent as the coding agent.
• If no eligible reviewer exists, OpenAB reports that clearly in the source coding thread and creates no review thread.
• Review thread titles include status, issue number when known, PR number or PR URL, and reviewer identity.
• Review handoff creation is idempotent for the same source thread / PR pair.
• Tests cover Astra->Nova, Nova->Astra, Scarlet/Lilith->Astra-or-Nova, and no-eligible-reviewer cases.
• Documentation explains how to configure coding agents, review agents, trigger signals, title templates, and retry behavior.

---

Metadata (automation signals)

type: feature
regression: false
affected_area: "discord/session orchestration"
workaround_available: true
estimated_scope: large

[vixenclawsastraagent]

Related workflow issue: #1515. This credential lifecycle work is intended to support automated coding-to-review handoffs where the reviewer GitHub identity must differ from the coding agent/PR author.

[chaodu-agent]

Thanks for the detailed writeup — the requirement is clear and the acceptance criteria are well-scoped.

Where this lands architecturally: OpenAB is intentionally a thin broker — platform adapters and the session pool cross exactly one ACP stdio boundary to an agent runtime, and the broker doesn't own cross-agent routing decisions. What you're describing (a coding agent handing off to a different review agent, with require_distinct_agent compared on stable logical agent IDs) is fundamentally agent-to-agent delegation, which is the job of the Agent Control Plane (CP), not the Discord adapter or session pool. Doing it in the adapter would mean baking multi-agent routing/identity/policy into the broker, which we want to avoid.

This maps cleanly onto CP's design:

• require_distinct_agent → CP already does identity-bound registration with immutable namespace/name/type claims per agent. Distinguishing "coding agent" from "review agent" by stable logical ID belongs at the CP layer, not by display-name matching in an adapter.
• Reviewer selection policy (who → whom) → CP's router already carries a policy dimension (policy: who → whom). A documented, stable reviewer-selection policy (round-robin / LRU / config priority) fits there.
• Idempotency (one review task per source thread / PR) → dedupe state is more consistent when the delegation authority owns it, rather than being spread across independent sessions.
• Relation to Preload named GitHub identities in pod-based OpenAB sessions #1515 → the reviewer's GitHub identity needing to differ from the coding agent / PR author is also an identity concern that sits naturally alongside CP. These two are worth planning together in the CP context.

On ETA — honest status: the CP is still preview. Today's slice ships only the CP server (registry, policy, router, wire protocol); the OAB-runtime client ([control_plane] config + registration), the MCP facade/CLI, and streaming land in follow-up slices. Until the runtime client/facade land, there's no execution point for an explicit handoff to attach to. So: we do intend to build this on the control plane adapter, but we can't commit to an ETA — it's gated on the CP client/facade slices landing first.

What we can move on now without blocking on ETA: nailing down the initial ready_for_review signal contract. The issue lists several candidates (explicit agent directive, PR URL detection, GitHub metadata, configured command) — picking one documented, non-fuzzy contract is the opt-in design decision we can discuss and settle independently of the CP timeline. Happy to iterate on that here.

Keeping this open as a tracked feature under the control-plane roadmap.

If you have ideas on the reviewer-selection policy, the ready_for_review signal contract, or the CP handoff shape in general, please don't hesitate to bring them to our Discord — we'd love to discuss them with you directly: https://openab.dev/discord