pr-pipeline

Topics in the source

• Agent PR pipeline
• The loop for one PR
• Before the first run in a repo
• Step 1: write the plan, then review the plan
• Step 2: run one wave
• Workflow arguments
• Role agents
• Cost and the prompt cache

One PR at a time is easy to check. Many PRs at once are not, unless each PR goes through the same fixed loop and no agent checks its own work. This skill is that loop. This skill is part of the agent-pr-pipeline plugin. The plugin folder is ${CLAUDEPLUGINROOT}: the scripts, templates and the workflow are there. Each step runs as one of the plugin's role agents (agent-pr-pipeline: , see "Role agents"). Summary: a plan is reviewed first, including whether it still serves the product's goals. A quick fix has no plan: a triager first decides build, plan or decline for the issue, and a build gets the same product-fit check on its entry. Then different agents build, test, review for bugs, review for architecture and (where the plan asks) try each PR like a user until it is clean, or until a person settles an architecture question. A code PR then gets one capped minor pass, kept only when its own check passes. A docs agent then brings the docs in line, and a short round checks its commits. Then the PR is opened and the bots are answered. On the final head, a script checks the PR's files against the gated paths of .github/pipeline.json, and for a PR the gate does not hold a merge-safety ag

This is an excerpt. Refer to the complete source and its current requirements.