tri-agent-looplisted

# Tri-Agent Loop A delivery protocol that splits work across **three roles** and keeps each artifact rigorously vetted before it advances: 1. **Planner** — drafts the artifact: an SRS, design doc, or per-task implementation plan. Decides *what* and *how*, not the code. 2. **Reviewer** — adversarially reviews the artifact through a shared markdown thread, returning concrete deltas until convergence. 3. **Implementer** — writes the actual code/change after the plan converges, and opens a PR. The roles are **pluggable**: any agent can fill any role, in any order. The agent running this skill is the **orchestrator** — it authors artifacts when it holds a role, relays handoffs when a role belongs to an external agent, monitors the review thread, and reviews the implementer's PR. The orchestrator is usually also one of the three roles (commonly planner+reviewer), but need not be. > This is the generalized form of the workflow captured in the user's `feedback_planner_reviewer_codex_loop` memory: planner+reviewer authored by one agent, a separate implementer, every artifact Codex-reviewed before handoff. Here the agent behind each role is a parameter. ## When to use Fire when the user wants multi-agent delivery with separation of concerns: - "Run the planner/reviewer/implementer loop on X." - "Use Claude to plan, Codex to review, Cursor to implement" — or **any** role permutation. - "Tri-agent loop", "plan-review-implement", "the docs-first Codex-reviewed loop." - A substantial