Address pipeline¶
The address pipeline takes PR review feedback and implements the requested changes. It checks out the PR's existing branch (not a new one), makes changes, runs quality gates, pushes, and posts a response.
Flow¶
flowchart TD
A[analyze_feedback] --> B{actionable items?}
B -->|no| C[no_action_comment]
C --> C1([post comment])
C1 --> STOP1[STOP]
B -->|yes| D[implement]
D --> D1{diff + quality?}
D1 -->|no diff| E[craft_update]
D1 -->|quality passes| E
D1 -->|quality fails| F[quality_fix]
F --> F1{quality passes?}
F1 -->|yes| E
F1 -->|no, attempts < 3| F
F1 -->|no, attempts = 3| E
E --> E1([commit, push, post comment])
E1 --> STOP2[STOP]Stages¶
analyze_feedback¶
Python fetches all review comments on the PR -- both inline code comments and top-level discussion comments. The agent reads through them and the codebase, then sorts feedback into actionable items and out-of-scope items (questions, discussions that need human input, style preferences the project doesn't enforce).
Returns a FeedbackAnalysis with action_items and out_of_scope lists.
If nothing is actionable, the pipeline routes to no_action_comment and stops.
implement¶
New session. The agent has the action items from the analysis stage and makes changes on the PR's head branch. Same safety rules as the resolve pipeline: it can edit files but not run git commands.
After implementation, Python captures the diff and runs quality tools.
quality_fix¶
Same pattern as in the resolve pipeline. If quality tools fail, the agent gets the output and tries to fix things. Up to three attempts.
craft_update¶
Resumes the implementation session. The agent writes a commit message and a response comment summarizing what it changed. Python commits, pushes to the PR branch, and posts the comment.
Key difference from resolve¶
The address pipeline works on an existing PR branch. It doesn't create a new branch. Changes get pushed as additional commits on the same PR, which keeps the conversation and review history intact.