# 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:
1. Check out the PR's head branch
2. Read the review comments from Gitea
3. **Actually fix every issue** — make the code changes, don't defer them
4. Run tests (`python -m pytest tests/ --tb=short -q`)
5. 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.