// 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.
| name | pr-discussion-orchestration |
| type | orchestration |
| description | 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. |
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.
The /forge:process-pr-discussions command loads this skill
to orchestrate the PR discussion processor and any delegate
agents it spawns.
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 }
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 }
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: [...] }
The main context manages phase transitions and reads signals. It does not analyze PR content, classify threads, or apply changes directly.
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.
Create and manage Flox development environments. Use when setting up a project environment during /forge:init, when a user asks to add a Flox environment, or when detecting and installing project dependencies. Covers flox init, search, install, manifest basics, and language-specific patterns. For advanced topics (services, builds, CUDA, layering, containers), suggest the full flox plugin.
This skill should be used when "restructuring commits", "organizing PR history", "making commits reviewable", or planning how to split work into atomic commits. The intellectual foundation for /reviewable. Do not use for writing commit messages (see git workflow guideline).
This skill should be used when the user redirects, corrects, or refines agent output — "no, actually", "that's not right", "you missed something". Captures correction moments to improve Forge workflows over time. Always active during feature work; log corrections as they occur.
This skill should be used when the user asks "what is an effort", "effort phases", "how do efforts work", "effort vs slice", or needs to understand the effort lifecycle. Covers the five phases: initialize, story capture, requirements, slice identification, and slice spawning.
Surface Forge plugin documentation when users ask "how does forge work", "forge help", "what commands are available", or need guidance on workflows, commands, or concepts. Use for onboarding, command reference, or workflow overview questions.
This skill should be used when a command needs the full implement-and-review cycle — spawning an implementation worker, running a code review gate, and making a post-review decision. Used by /forge:start-task and /implement. Do not use for review-only or implementation-only workflows.