PR Pipeline — Shared Workflow

Automated review-fix-merge cycle. The calling skill MUST define a Config section with the values listed under "Required Config" before referencing this workflow.

Required Config

Key	Description
`REPO_MAPPING`	Table: short name → Gitea repo → owner
`REVIEWER_AGENT`	Agent type for code reviews (e.g., `pr-reviewer`)
`REVIEWER_MODEL`	Model for reviewer agent
`FIXER_AGENT`	Agent type for fixing review findings (e.g., `engineer`)
`FIXER_MODEL`	Model for fixer agent
`MERGER_AGENT`	Agent type for merging (e.g., `pd-ops`)
`MERGER_MODEL`	Model for merger agent

Usage

/pr-pipeline <repo-short-name> <pr_numbers...>

Resolve <repo-short-name> via the REPO_MAPPING table in the calling skill's Config section.

Workflow

For each PR, run this cycle (max 3 iterations to prevent infinite loops):

Step 1: Review

Launch a {REVIEWER_AGENT} agent (model: {REVIEWER_MODEL}) against the PR. The reviewer posts a formal review via Gitea API.

Step 2: Evaluate

If APPROVED → go to Step 4
If REQUEST_CHANGES → go to Step 3
If this is iteration 3 and still not approved → stop, report the remaining issues to the user

Step 3: Fix

Launch a {FIXER_AGENT} agent (model: {FIXER_MODEL}) to address the reviewer's feedback. The engineer should:

Check out the PR's head branch
Read the review comments from Gitea
Actually fix every issue — make the code changes, don't defer them
Run tests (python -m pytest tests/ --tb=short -q)
Commit and push to the PR branch

Then return to Step 1 (re-review).

Engineer fix rules:

Fix it, don't punt it. Every reviewer finding should result in a code change, not a TODO, FIXME, or "will address in follow-up PR." The goal is to get to APPROVED, not to get to merge by deferring work.
Simple changes go in now. Renames, missing null guards, docstring updates, import fixes, test updates — these are not "follow-up" material. Do them.
Only escalate to the user if a fix requires a design decision (e.g., changing an API contract, choosing between two valid approaches) or if the reviewer's suggestion is wrong/misguided. In that case, stop and ask rather than guessing.
Don't introduce new features while fixing. Stay scoped to what the reviewer flagged.
If the reviewer flagged something as "non-blocking" or "suggestion", still fix it if it's simple (< 5 minutes of work). Only skip if it's genuinely out of scope for this PR.
Create Gitea issues for anything not fixed. If a reviewer recommendation is legitimately out of scope or requires a design decision, create a Gitea issue capturing the finding so it doesn't get lost. Reference the PR number in the issue body. Nothing should silently disappear.

Step 4: Merge

Launch a {MERGER_AGENT} agent (model: {MERGER_MODEL}) to merge the PR. The merger handles the approval dance and branch cleanup.

Important Rules

Max 3 review cycles per PR. If still failing after 3 rounds, stop and report.
Run PRs in parallel when they are independent (different repos or no dependency).
Run PRs sequentially when one depends on another (noted in PR description).
Never skip the review step — even "obvious" fixes get reviewed.
Report progress after each step completes — don't go silent during long pipelines.

3.4 KiB Raw Blame History