# Pr Discussion Orchestration

> This skill should be used when /forge:process-pr-discussions needs to orchestrate its three-phase pipeline — analyze unresolved threads, delegate changes to specialized agents, then resolve threads. Do not use outside the PR discussion processing command.

- Skill: `flox/pr-discussion-orchestration` (Agent Skill)
- Install (CLI): `npx skillmds@latest add flox/pr-discussion-orchestration`
- Raw SKILL.md: https://api.skillmd.com/api/skills/flox/pr-discussion-orchestration/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: flox (https://skillmd.com/u/flox)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/flox/pr-discussion-orchestration

---


# PR Discussion Orchestration

Thin dispatcher pattern for processing PR discussion threads.
The main context manages the three-phase pipeline; all
analysis and change application happens inside sub-agents.

## When to Use

The `/forge:process-pr-discussions` command loads this skill
to orchestrate the PR discussion processor and any delegate
agents it spawns.

## Three-Phase Pipeline

### Phase 1: Analyze

Spawn the `pr-discussion-processor` to fetch the PR,
identify unresolved threads, group by theme, and produce
a delegation plan.

```
Use Task tool with:
- subagent_type: "PR Discussion Processor"
- prompt: |
    ## Inputs
    - pr_number: {number}
    - owner: {owner}
    - repo: {repo}
    - feature_path: {path}
```

**Read signal:**
```
{ delegation_plan, thread_count, pr_type }
```

### Phase 2: Delegate Changes

Based on the delegation plan, spawn the appropriate agent
to apply changes:

| PR Type | Delegate Agent |
|---------|---------------|
| Implementation | implementation-worker |
| Design | designer |
| Requirements | requirements-gatherer |
| Other markdown | pr-discussion-processor (direct) |

**Separation of concerns:** When Phase 2 delegates to the
implementation-worker, the worker applies changes and reports.
It does **not** chain into code review. Review is a separate
concern handled by the calling command after all three phases
complete. If review is needed, the command loads the review
orchestration skill step 2 only (the worker already ran).

**Read signal from delegate:**
```
{ commit_sha, changes_applied, status }
```

### Phase 3: Resolve

Spawn the pr-discussion-processor again (or continue if in
same context) to reply to threads and resolve them based
on the changes applied.

**Read signal:**
```
{ resolved: N, remaining: M, actions: [...] }
```

## Thin Dispatcher Contract

The main context manages phase transitions and reads signals.
It does not analyze PR content, classify threads, or apply
changes directly.

- Phase 1 output feeds Phase 2 input
- Phase 2 output feeds Phase 3 input
- Main context budget: ~35 lines of signals

## Nesting Rule

This skill is self-contained. It does not reference
or depend on any other orchestration skill. The calling
command may load the review orchestration skill after this
pipeline completes for a review gate, but that is sequential
command-level composition, not nesting.