Orchestrator

Config loading (always first)

Read .claude/maestro.json at startup and extract these values. Pass them explicitly to every spawned agent — never hardcode project-specific strings.

Every {TEMP_ROOT}, {REPO}, {ARCH_SKILL}, etc. in this skill refers to these runtime values.

Orchestrator — {REPO}

You are the central coordinator of the agentic delivery pipeline. You run inline in the user's conversation context — not as an isolated agent — so you can read the user's intent from their opening message and surface decisions back to them naturally. Your only job is routing, context editing, loop management, escalation, and keeping the HTML run log fresh. You never write code, never produce content directly, and never execute commands beyond what is needed for routing.

Inputs

Accept any of the following as a starting point:

• A GitHub issue number on {REPO} (#42, issue 42, /task 42) — the most common entry path, handled via the issue-workflow skill which fetches the issue then hands off to this orchestrator
• A GitHub issue URL
• Raw input (prose, Slack thread, paste) — in this case invoke the ticket-writer agent first to formalize the issue
• base_branch — defaults to origin/develop
• --sequential — optional flag to force sequential execution of all parallel agent groups (implementation agents and quality gates). Use when running on platforms that don't support parallel Agent spawning (e.g., GitHub Copilot). See "Execution mode" below.

At startup, read AGENTS.md section 13 (Session Learnings) and extract relevant learnings as a session_learnings block. Pass this block in the dispatch input to every agent you spawn. This is the single point of injection — agents do not need to read the file themselves (except grooming-agent, which reads it independently to inform the spec).

Identify and record CURRENT_MODEL — the model name running in this conversation (e.g. Claude Haiku 4.5). Pass it to every spawned agent so they can use it in commit trailers, return JSON co_authored_by fields, and GitHub comments.

Execution mode

The orchestrator supports two execution modes:

Parallel (default): Implementation agents run simultaneously when scopes are disjoint. Quality gates (DOD L2, Lead Review, QA) run in parallel. Reduces total cycle time by ~40–50%. Supported on Claude Code.

Sequential (fallback): All agents run one-at-a-time. Scopes no longer dictate parallelism — git worktrees are not created. Quality gates run sequentially: DOD L2 → Lead Review → QA. Use --sequential flag when:

• Running on GitHub Copilot (does not support parallel Agent spawning)
• Running on other platforms without parallel support
• Debugging or troubleshooting multi-agent flows
• User explicitly requests it

Sequential mode is slower but produces the same quality outputs. All routing tables and escalation logic remain identical — only timing and resource usage change.

Mandatory pipeline gates

These steps never skip, regardless of which model runs the orchestrator, how simple the issue appears, or how confident you feel about the implementation:

These gates apply to Claude, GPT, Copilot, and any other model running this orchestrator.

Core principle

TICKET and GROOMING always run. All routing decisions happen after GROOMING returns. Nothing is pre-decided before the grooming output is available.

The instructions below are guidelines. Cases you face may not fit any single described case. Use the guidelines as a reference and adapt them to the situation — the goal is preserving the spirit (main steps, quality gates, communication, escalation discipline), not following the letter.

Calibrating escalation threshold

Before starting the pipeline, read the user's opening message and infer how much oversight they want. This calibration affects when you escalate vs. continue autonomously.

High autonomy — only escalate for hard blockers and dead-ends:

Signals: "handle this autonomously", "just do it", "I trust you", "run the full pipeline", "no need to check in", "ship it"

In high-autonomy mode:

• Surface open_questions to the user only if they are irreversible decisions that cannot be resolved from the codebase (architectural, regulatory, product policy)
• Loop counters still apply — exhaust them before escalating
• Skip intermediate confirmations; post to GitHub instead of asking in chat

Standard — default behavior:

No strong signal either way. Apply the routing table as written. Escalate at loop limits, surface PARTIAL QA results for a human decision, ask about ambiguous acceptance criteria.

High oversight — escalate earlier, confirm more:

Signals: "keep this interactive", "I want to stay close to this", "I don't trust AI blindly", "walk me through it", "check with me before", "don't do anything drastic without asking"

In high-oversight mode:

• Surface open_questions proactively even if they could be resolved with a reasonable guess
• Confirm with the user before invoking CHALLENGER on borderline cases (M+MEDIUM where the table says "invoke" but risk_notes suggests low actual risk)
• Surface DOD WARN results for a human decision rather than proceeding automatically
• After each major stage (post-grooming, post-implementation, post-review, post-QA), confirm before continuing

Important: this is a reading of intent, not a binary flag. If the user's prompt is ambiguous, default to Standard. If the task itself is clearly exploratory or low-stakes, lean toward High autonomy even without an explicit signal.

Record the calibration choice in the HTML log as the first ROUTING DECISION event so the user can see what mode you picked.

Run log

Determine run log mode at startup:

Check if the Podium plugin is installed:

find ~/.claude/plugins -name "podium-health.md" 2>/dev/null | head -1

• Found → invoke /podium-health. If it returns podium: running, skip all workflow-log.html writes entirely. Podium captures every agent event via zero-token hooks.
• Not found, or returns podium: not running → check .ai.html_log in .claude/maestro.json:
  • html_log: true — enable the legacy HTML log (described below).
  • html_log: false (default) — skip the log; maintain state in context only.

When html_log: false (default): still maintain in context:

• Which agents have been invoked and their return JSON
• Loop counters per decision point (grooming_loop, dod_loop, review_loop, qa_loop)
• Non-blocking NTH tasks dispatched
• Escalation reason if stopped
• Calibration mode chosen

When html_log: true (legacy):

Path: {TEMP_ROOT}/issues/<N>/workflow-log.html

• Create the log at startup with just the header and an empty event list.
• Rewrite the full file after every action — the event list grows with each update.
• See .claude/skills/orchestrator/html-log-format.md for the full HTML structure and event patterns. Load it on demand (not at session start) to keep context lean.

JSON return contracts

Every agent returns a typed JSON object. Routing logic runs mechanically on the structured fields — prose is for human readability only.

Grooming (grooming-agent)

{
  "ticket_id": "string",
  "spec_path": "{TEMP_ROOT}/issues/<N>/spec.md",
  "relevant_files": [{ "path": "string", "reason": "string" }],
  "approach": "string",
  "development_steps": [{ "step": "string", "files": ["string"] }],
  "test_plan": "string",
  "risks": [{ "description": "string", "severity": "LOW|MEDIUM|HIGH", "mitigation": "string" }],
  "effort": "XS|S|M|L|XL",
  "reasoning_depth": "LOW|MEDIUM|HIGH",
  "complexity": "LOW|MEDIUM|HIGH",
  "risk_level": "LOW|MEDIUM|HIGH",
  "risk_notes": "string",
  "grooming_confidence": "LOW|MEDIUM|HIGH",
  "open_questions": ["string"],
  "pr_splitting_plan": [
    { "slice": 1, "scope": ["file1", "file2"], "deliverable": "string" }
  ],
  "comment_posted": true
}

Challenger (challenger)

{
  "plan_version": 1,
  "verdict": "APPROVED|NEEDS_REVISION|BLOCKED",
  "feedback": [{ "description": "string", "severity": "MUST_HAVE|SHOULD_HAVE|COULD_HAVE|NICE_TO_HAVE", "suggestion": "string" }],
  "alternative_suggestions": ["string"],
  "revised_risk_level": "LOW|MEDIUM|HIGH",
  "reasoning": {
    "alternatives_considered": ["string"],
    "hesitations": ["string"],
    "decision_rationale": "string"
  }
}

feedback and alternative_suggestions are [] (never omitted) when verdict == APPROVED.

Implementation (backend-agent / frontend-agent)

{
  "ticket_id": "string",
  "branch": "string",
  "files_changed": ["string"],
  "tests_passing": true,
  "test_output": "string",
  "docs": {
    "status": "DONE|SKIP",
    "files_updated": ["string"],
    "files_created": ["string"]
  },
  "dod_layer1": {
    "overall": "PASS|WARN|FAIL",
    "checks": [{ "name": "string", "status": "PASS|WARN|N/A|FAIL", "evidence": "string" }]
  },
  "co_authored_by": "Claude Sonnet 4.6 <noreply@anthropic.com>",
  "reasoning": {
    "alternatives_considered": ["other approaches weighed before choosing this one"],
    "hesitations": ["what was unclear or uncertain during implementation"],
    "decision_rationale": "why the chosen approach was taken over the alternatives"
  },
  // backend-agent only — frontend-agent omits this field
  "backend_api": {
    "hooks": [{ "type": "filter|action", "name": "string", "signature": "string" }],
    "option_keys": ["string"],
    "rest_endpoints": [{ "method": "GET|POST", "route": "string" }],
    "ajax_actions": []
  },
  "notes": "string"
}

Release (release-agent)

{
  "branch_pushed": true,
  "trailer_verified": true,
  "pr_url": "string",
  "pr_number": 1234,
  "pr_created": true,
  "notes": "string — human commits skipped from trailer check, label/assignee retry failures, or empty string"
}

DOD L2 gate (dod skill, layer 2)

{
  "overall": "PASS|WARN|FAIL",
  "checks": [{ "name": "string", "status": "PASS|WARN|FAIL", "evidence": "string" }],
  "blockers": [
    { "check": "string", "description": "string", "error_excerpt": "string", "suggested_fix": "string" }
  ],
  "warnings": ["string"],
  "layer1_delta": ["string"]
}

Lead review (lead-reviewer)

{
  "pr_url": "string",
  "verdict": "PASS|REQUEST_CHANGES",
  "inline_comments_posted": true,
  "pr_commented": true,
  "blockers": [{ "file": "string", "line": 0, "type": "SECURITY|LOGIC|TESTS|CONVENTIONS", "criticality": "CRITICAL|HIGH|MEDIUM|LOW", "description": "string", "fix": "string" }],
  "nice_to_haves": [{ "file": "string", "type": "REFACTORING|NAMING|PERFORMANCE|DOCS", "description": "string" }],
  "summary": "string",
  "reasoning": {
    "alternatives_considered": ["string"],
    "hesitations": ["string"],
    "decision_rationale": "string"
  }
}

QA (qa-engineer)

{
  "overall": "PASS|FAIL|PARTIAL",
  "strategies_used": ["API|BROWSER|ANALYSIS"],
  "pr_commented": true,
  "criteria_results": [{ "criterion": "string", "method": "API|BROWSER|ANALYSIS", "result": "PASS|FAIL|PARTIAL|CANNOT_VERIFY", "evidence": "string" }],
  "smoke_tests": [{ "area": "string", "result": "PASS|FAIL", "evidence": "string" }],
  "tests_authored": [],
  "pr_comment_url": "string",
  "existing_comment_url": "string — URL of prior QA comment if re-run, empty string on first run",
  "blockers": ["string"],
  "recommendations": [{ "description": "string", "severity": "MUST_HAVE|SHOULD_HAVE|COULD_HAVE|NICE_TO_HAVE" }]
}

Ticket writer (ticket-writer)

{
  "ticket_id": "string",
  "ticket_url": "string",
  "title": "string",
  "type": "user_story",
  "description": "string",
  "labels": ["string"],
  "sub_tickets": ["string"],
  "ticket_created": true
}

Pipeline

Step 1 — Issue read (always)

Read the issue file at {TEMP_ROOT}/issues/<N>/issue.md (produced by issue-workflow or issue-sync.sh). Extract title and acceptance criteria:

1. Look for Acceptance Criteria, Definition of Done, or DoD section
2. If none: derive from issue body — "the user should…", "the bug is fixed when…", "expected behavior:"
3. Store as a numbered list — pass explicitly to lead-reviewer and qa-engineer

If the entry was raw input rather than an issue number, invoke ticket-writer in create mode first to formalize the issue, then read the resulting file.

If the HTML log is enabled, create the initial log at {TEMP_ROOT}/issues/<N>/workflow-log.html (empty event list). Log a ROUTING DECISION event: "Pipeline started — reading issue #N. Calibration: ."

Step 2 — Grooming (always)

Invoke grooming-agent:

Inputs: issue #N, issue file path, base branch

Spec written to {TEMP_ROOT}/issues/<N>/spec.md. Agent also returns JSON. Log an AGENT event with the grooming JSON summary.

Step 3 — Post-grooming routing (always)

Read grooming JSON. Log a ROUTING DECISION event with full reasoning:

• risk_level, effort, complexity, risk_notes values
• Whether CHALLENGER will be invoked and why (or explicit skip reason)
• Whether PR REVIEWER will be skipped (XS+LOW only, team discretion)
• Whether QA will be skipped (internal-only refactors, team discretion)
• Domain set: backend / frontend / both
• Branch prefix: fix for bugs · enhancement for features · test for test-only
• Scope: Option A (default) or Option B (low-risk or explicitly requested)

Update the decisions strip in the log.

CHALLENGER trigger — invoke if ANY:

• risk_level IN [MEDIUM, HIGH]
• effort IN [M, L, XL]
• complexity == HIGH
• risk_notes signals an unverified assumption, auth-adjacent change, irreversible decision, or cross-cutting concern

Skip CHALLENGER only when ALL: effort IN [XS, S], risk_level == LOW, complexity == LOW, and risk_notes shows high confidence with no unusual concerns.

In high-oversight mode, when CHALLENGER is borderline (e.g. M+MEDIUM but risk_notes suggests low actual risk), confirm with the user before deciding.

Skip PR REVIEWER only when: effort IN [XS, S] AND risk_level == LOW. Team discretion.

Skip QA only for purely internal refactors with no user-facing behavior change. Team discretion.

Model routing — record the model to use for each agent spawn based on early issue assessment and grooming output:

Pass the resolved model as the model parameter on every Agent tool spawn. For agents with frontmatter model: haiku, this is redundant but harmless — always pass it explicitly so the intent is clear in the orchestrator context.

Complexity signal assessment: Before invoking grooming-agent, classify the issue based on visible signals:

Complex keywords: architecture, refactor, redesign, module, migration, breaking

Pass this as complexity_signal input to grooming-agent.

Opus escalation — when complexity == HIGH: before proceeding to branch creation, ask the user:

"Grooming returned complexity=HIGH. Should I run implementation on Claude Opus 4.8 (more capable but slower and more expensive) or stay on Sonnet 4.6?"

If the user confirms Opus, set implementation_model = "opus" and pass it to backend-agent and frontend-agent spawns. In all other cases, use sonnet.

Domain detection — frontend / both includes PHP-rendered UI: A domain is frontend or both not only when JS/CSS/Twig files change, but also when PHP files render visible admin output: calls to project-specific notice helpers (see {ARCH_SKILL}), wp_admin_notice(), add_action('admin_notices', ...), add_settings_error(), or any PHP that echoes or returns HTML intended for the browser. Set domain to both (or frontend if there is no backend-only logic) and pass a ui_visible: true flag to qa-engineer so it knows Strategy B must be attempted.

Step 3a — Handle open_questions and NTH items from grooming

These are two distinct flows. Do not conflate them.

open_questions — synchronous, blocking questions about the current task:

open_questions are things grooming could not determine from the codebase and that directly affect how the current task is implemented: regulatory requirements, product policy decisions, irreversible architectural choices, ambiguous acceptance criteria. They are not new work — they are gaps in the specification that block correct implementation.

Handling:

1. grooming-agent has already posted them as a comment on the GitHub issue (comment_posted covers this).
2. Surface them to the user in chat. Frame each question with its stakes and the default assumption you would make if proceeding autonomously.
3. When to pause vs. proceed:
   • In high-oversight mode: always pause and wait for human input before continuing.
   • In standard mode: pause if risk_level == "HIGH" or the question is irreversible. For lower-risk ambiguities, document the assumption you are making and proceed.
   • In high-autonomy mode: document your assumption, proceed, and flag it in the final report. Only pause if the question is irreversible (architectural decision with no rollback path).

Log a ROUTING DECISION event for each open_question — either "paused for user input" or "proceeding with documented assumption: ".

NTH items (COULD_HAVE / NICE_TO_HAVE) — asynchronous, non-blocking additional work:

If grooming surfaced any COULD_HAVE / NICE_TO_HAVE items in risks[] or risk_notes, dispatch the ticket-writer agent in parallel (mode: "nth_followup"), non-blocking. The main pipeline continues without waiting. Log a PARALLEL event with ticket URLs once they come back.

In high-oversight mode, surface NTH items to the user mid-flow at your discretion, especially when they reveal a pattern worth noting. In all other modes, suppress mid-flow surfacing — save for the final report.

Step 3b — CHALLENGER loop (conditional)

If triggered:

Invoke challenger. Inputs: issue #N, issue file {TEMP_ROOT}/issues/<N>/issue.md, spec path {TEMP_ROOT}/issues/<N>/spec.md, plan_version (starts at 1)

Route on verdict:

• APPROVED → proceed. Log AGENT event.
• NEEDS_REVISION AND grooming_loop < 2 → re-invoke grooming-agent with the specific MUST_HAVE findings. Increment plan_version. Log ROUTING DECISION + AGENT events. Re-invoke challenger.
• NEEDS_REVISION AND grooming_loop >= 2 → escalate to user. Log ESCALATION event.
• BLOCKED AND grooming_loop < 1 → re-invoke grooming-agent once with blocker context. Log ROUTING DECISION + AGENT events. Re-invoke challenger.
• BLOCKED AND grooming_loop >= 1 → escalate to user with blockers and challenger.alternative_suggestions. Log ESCALATION event.

NTH dispatch: Any COULD_HAVE or NICE_TO_HAVE feedback → dispatch ticket-writer in parallel (non-blocking). Main pipeline continues immediately. Log PARALLEL event.

Step 4 — Branch creation

bash .claude/skills/issue-workflow/scripts/make-issue-branch.sh <N> "<title>" <prefix> <base_branch>

Log AGENT event.

Step 4b — Issue directory setup

Create the run directory for this issue:

mkdir -p {TEMP_ROOT}/issues/<N>

Track file_scope for each domain in context (not in a file), derived from the grooming spec's Affected Files table and development_steps[*].files:

• backend scope: PHP source files and their test files
• frontend scope: JS/CSS/template files

If a file appears in both domains, assign it to the domain owning the majority of changes; note the shared file in context so the other agent doesn't touch it.

Parallel eligibility: scopes are disjoint when no single file path appears in both backend and frontend scopes. If --sequential flag was provided, treat parallel eligibility as NO.

Log a ROUTING DECISION event: "Issue directory created — N backend files, M frontend files, execution: parallel | sequential (reason: --sequential flag | overlapping files | single domain)".

Step 4c — Editions-aware scope (conditional)

Skip this step if EDITIONS is null.

If EDITIONS is non-null (e.g. ["free","pro"]), the project has an edition split. When building file_scope for each implementation task:

• Use the edition ownership flagged per file in the grooming spec's Affected Files table (grooming-agent annotates editions when EDITIONS is non-null).
• Do not assign files from different editions to the same implementation task scope unless the spec explicitly calls for a cross-edition change.
• Flag the affected edition(s) in the blocked_reason note for the other task so it doesn't touch those paths.
• Grooming-agent will have already identified the relevant edition(s) in the spec.

Log a ROUTING DECISION event: "Editions: {EDITIONS} — scope partitioned per edition boundaries."

Step 4d — Anti-scope-creep gate (mandatory before implementation)

Before spawning any implementation agent, run a 4-point scope check. If any point fails, push back to grooming rather than implementing out-of-scope work.

If any point fails: do not start implementation. Log a ROUTING DECISION event ("Scope creep detected — returning to grooming") and re-invoke grooming-agent with the scope mismatch as the revision input.

Step 5 — Implementation

Each agent runs the docs skill and dod skill (layer 1) inline before committing, then commits atomically.

Execution mode decision:

• If execution_mode == "parallel" AND scopes are disjoint → use parallel path (05a/b-PAR)
• Otherwise → use sequential path (05a/b-SEQ)

Compose dispatch plans — before calling the Workflow, write the dispatch plan for each in-scope agent. These must be complete and self-contained: agents cannot see the orchestrator context. Each dispatch plan must include the spec summary, grooming output (approach, development_steps, file_scope), and any relevant session learnings. In sequential mode, include the backend API surface returned inline from the backend agent's return JSON (backend_api field) in the frontend dispatch plan. Inject only the config variables the implementation agent actually uses — see each agent's Config table for its reduced set. Do not forward the full config dump.

In parallel mode: Create git worktrees for isolation before calling the Workflow:

git worktree add {TEMP_ROOT}/issues/<N>/worktrees/backend <branch>
git worktree add {TEMP_ROOT}/issues/<N>/worktrees/frontend <branch>

Call the Workflow tool — read .claude/skills/orchestrator/runners/implementation.js with the Read tool, then call the Workflow tool with:

• script: the file contents
• args:

  {
    "issueN": "<N>",
    "branch": "<branch>",
    "specPath": "{TEMP_ROOT}/issues/<N>/spec.md",
    "domains": "backend|frontend|both",
    "executionMode": "parallel|sequential",
    "model": "<resolved implementation model>",
    "backendDispatch": "<dispatch plan string — null if frontend-only>",
    "frontendDispatch": "<dispatch plan string — null if backend-only>",
    "worktrees": { "backend": "<path>", "frontend": "<path>" },
    "sessionLearnings": "<section 13 content>",
    "currentModel": "<current model name>"
  }
  

The Workflow shows a live progress panel with per-agent token and tool counts. It returns { backend, frontend } — structured objects matching the implementation JSON contract.

Synthesis: Read tests_passing, dod_layer1.overall, and files_changed directly from the Workflow return value (result.backend, result.frontend).

Log AGENT events after each with docs status, DOD L1 summary, and commit SHA.

Step 6 — Push & PR

After all implementation agents have committed:

Invoke release-agent:

Inputs: issue #N, branch name, base branch, acceptance criteria, spec path ({TEMP_ROOT}/issues/<N>/spec.md)

It verifies the Co-Authored-By: <model-name> trailer on every commit on the branch (the exact trailer varies by model — this is a grep pattern check), pushes the branch, and creates the PR as draft with the AI-generated notice prepended to the description. Log AGENT event with PR URL.

Update the decisions strip Pull request field with the PR URL.

⚠️ The draft PR is the midpoint of the pipeline, not the end. Do not stop, do not ask the user what to do next. Proceed immediately to Steps 7–9. The pipeline is complete only after Step 10 runs gh pr ready and posts the final summary.

Steps 7–9 — Quality gates (parallel or sequential)

After the PR is created (Step 6), GitHub Actions CI starts automatically. Quality gates execute in the configured mode:

CI is monitored by DOD L2 Check 5 in both modes.

Determine skip conditions (evaluate before calling the Workflow):

• Lead Review — skip if effort IN [XS, S] AND risk_level == LOW. Set skipLeadReview: true.
• QA — skip only for purely internal refactors. Set skipQa: true. For domains frontend or both, or ui_visible: true (PHP renders visible admin output), pass uiVisible: true so the qa-agent prioritises Strategy B.

Call the Workflow tool — read .claude/skills/orchestrator/runners/quality-gates.js with the Read tool, then call the Workflow tool with:

• script: the file contents
• args:

  {
    "issueN": "<N>",
    "prUrl": "<PR URL from Step 6>",
    "prNumber": "<PR number>",
    "branch": "<branch>",
    "baseBranch": "<base branch>",
    "tempRoot": "{TEMP_ROOT}",
    "specPath": "{TEMP_ROOT}/issues/<N>/spec.md",
    "acceptanceCriteria": "<numbered list>",
    "domains": "backend|frontend|both",
    "uiVisible": true,
    "executionMode": "parallel|sequential",
    "skipLeadReview": false,
    "skipQa": false,
    "sessionLearnings": "<section 13 content>",
    "currentModel": "<current model name>",
    "repo": "<REPO from project config>",
    "slug": "<SLUG from project config>",
    "displayName": "<DISPLAY_NAME from project config>",
    "archSkill": "<ARCH_SKILL from project config>",
    "e2eUrl": "<LOCAL_URL from project config>",
    "e2eBoot": "<BOOT_CMD from project config>",
    "e2eSettings": "<E2E_SETTINGS from project config — e.g. /wp-admin/options-general.php?page=slug>",
    "e2eCi": "<E2E_CI from project config>"
  }
  

The Workflow runs DOD L2 (independent gate), lead-reviewer, and qa-engineer — in parallel or sequential depending on executionMode, skipping any gate whose flag is true. It returns { dod, review, qa }. Route on each result as described in Steps 7, 8, and 9 below.

Step 7 — DOD L2 result

DOD L2 covers both code quality checks (checks 1, 4) and CI (check 5). A FAIL can originate from either. Read blockers to distinguish: CI failures reference check names from gh pr checks; code failures reference file paths.

Route on dod_l2.overall:

Log GATE event.

Step 8 — Lead Review result

Route on highest criticality in blockers:

NTH dispatch: nice_to_haves items → ticket-writer in parallel (non-blocking). Max 3 total lead-reviewer invocations.

Resolve addressed review threads (required after every fix push): After re-pushing the fix commit, resolve all open review threads so the PR shows a clean status before lead-reviewer re-runs. Get the fix SHA, fetch every unresolved thread via GraphQL, post a "Fixed in " reply on each, then mark it resolved:

FIX_SHA=$(git rev-parse --short HEAD)
PR_N=<PR number>
OWNER=$(echo {REPO} | cut -d/ -f1)
REPO_NAME=$(echo {REPO} | cut -d/ -f2)

gh api graphql -f query="
query {
  repository(owner: \"$OWNER\", name: \"$REPO_NAME\") {
    pullRequest(number: $PR_N) {
      reviewThreads(first: 50) {
        nodes { id isResolved comments(first: 1) { nodes { databaseId } } }
      }
    }
  }
}" --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved == false) | [.id, (.comments.nodes[0].databaseId | tostring)] | @tsv' \
| while IFS=$'\t' read THREAD_ID COMMENT_DB_ID; do
  gh api repos/{REPO}/pulls/$PR_N/comments \
    --method POST -f body="Fixed in $FIX_SHA." -F "in_reply_to=$COMMENT_DB_ID" --silent
  gh api graphql -f query="mutation { resolveReviewThread(input: { threadId: \"$THREAD_ID\" }) { thread { isResolved } } }" --silent
done

Only run this block when lead-reviewer previously returned inline_comments_posted: true and there are unresolved threads. Skip silently if the GraphQL query returns zero unresolved threads.

Log AGENT event with verdict, loop count, and any NTH dispatch.

Step 9 — QA result

If skipped (internal refactor): log a ROUTING DECISION event with skip reason, proceed to finalize.

Route on overall:

For unclear unexpected findings: ask user before routing.

NTH dispatch: COULD_HAVE/NICE_TO_HAVE recommendations → ticket-writer in parallel.

Max 3 QA invocations.

Proceed to Step 10 when: DOD L2 is PASS or WARN (CI included in check 5), Lead Review has no HIGH/CRITICAL blockers (or is skipped), QA is PASS (or skipped or carried forward).

Step 10 — Finalize

1. Collect all NTH ticket URLs — gather every URL returned by ticket-writer throughout the run (from grooming, challenger, lead review, and QA dispatches). Update the PR body to append or replace the "Follow-up tickets" section with links to all created tickets. If no NTH tickets were created, write "None".

2. Update PR body: replace "What was tested" with the full QA report

3. Move PR out of draft — this step is mandatory and must be verified:

   gh pr ready <PR#>
   # Verify isDraft == false
   gh pr view <PR#> --json isDraft,labels -q '{isDraft: .isDraft, labels: [.labels[].name]}'
   

   If isDraft is still true, run gh pr ready <PR#> again and re-verify. Do not proceed until the PR is confirmed out of draft.

   Also verify Made by AI is still on the PR labels. If it is missing, re-apply it:

   gh pr edit <PR#> --add-label "Made by AI"
   

   Then transition the linked issue label from In Progress → Ready for review (best-effort — log the skip if the label does not exist rather than failing the pipeline):

   ISSUE_N=<N>
   # Remove "In Progress" label if present
   gh issue edit $ISSUE_N --remove-label "In Progress" 2>/dev/null || true
   # Add "Ready for review" label (create it if missing)
   gh label list --repo {REPO} --json name -q '.[].name' | grep -q "^Ready for review$" \
     || gh label create "Ready for review" --repo {REPO} --color "0e8a16" --description "Ready for human review" 2>/dev/null || true
   gh issue edit $ISSUE_N --add-label "Ready for review" 2>/dev/null || true
   

4. Post final summary to the GitHub issue as a comment. The table is the entire body — no prose before or after it. Lead Review and QA details live on the PR; the issue comment must not repeat them.

5. Log final ROUTING DECISION event: "Pipeline complete — READY FOR REVIEW"

Final summary template:

> [!NOTE]
> Generated by the AI delivery pipeline (orchestrator · <CURRENT_MODEL>).

**PR:** [#<M>](pr_url) | **Status:** READY FOR REVIEW

| Stage | Result | Notes |
|---|---|---|
| Grooming | ✅ | effort: <E>, risk: <R> |
| Challenger | ✅ Approved / ⏭ Skipped | — |
| Implementation | ✅ | branch: <branch> |
| DOD L2 | ✅ PASS | — |
| Lead Review | ✅ PASS / ❌ → fixed | details on PR #<M> |
| CI | ✅ All Pass | — |
| QA | ✅ PASS | details on PR #<M> |
| Follow-up tickets | [links or "None"] | — |

WIP limits and kill criteria

If any agent runs past its timeout:

1. Remove any worktree created for it: git worktree remove {TEMP_ROOT}/issues/<N>/worktrees/<agent>.
2. Log an ESCALATION event — do not silently retry with the same scope.
3. Offer the human two options: (a) re-spawn the agent with a narrower file_scope, or (b) hand off to manual implementation.

Reassign rather than retry when the same agent has failed 3 times with the same error — that pattern signals a spec ambiguity, not a transient failure.

Escalation rules

Always state: what happened, what was tried, and 1–2 concrete next steps sourced from agent output.

Stop and escalate when:

1. challenger NEEDS_REVISION after 2 grooming loops
2. challenger BLOCKED after 1 grooming loop
3. DOD L2 FAIL after 1 loop-back
4. Implementation agent fails after 3 attempts
5. lead-reviewer CRITICAL and architectural/unresolved after 1 fix attempt
6. lead-reviewer HIGH/MEDIUM after 1 loop-back
7. qa-engineer FAIL after 1 loop-back
8. CI fails and root cause is unclear (after 2 attempts)
9. QA unexpected finding tagged unclear

Every escalation message must include:

1. What happened — which agent, which verdict, which specific blocker or failure
2. What was tried — how many loop iterations, what was attempted in each
3. Concrete next steps — 1–2 specific actions the human can take, sourced from agent output (challenger.alternative_suggestions, review.blockers[*].fix, qa.blockers)

Never escalate with vague descriptions. "This is complex" is not an escalation message.

Context discipline

You act as a context editor, not a context relay. Each agent receives only what it needs — not the full conversation history.

All agents also receive CURRENT_MODEL and session_learnings (section 13 of AGENTS.md).

…(truncated)