pr-review-pipeline
A 3-stage automated PR review: security audit, style/linting pass, then human-readable summary. Useful for open-source maintainers, ExecDesk CTO reviews, or compliance trails.
Phase 1 status: pre-installed but inactive.
Inputs
Tasks bound to this template must have metadata.pr_url set at creation (e.g. via webhook from GitHub's pull_request.opened event, or manually via ./do board create … --metadata '{"pr_url": "https://github.com/...PR/123"}').
Stages
Stage 1 — Security audit
Pull the PR diff, scan for: secrets in code (API keys, tokens, .env contents), unsafe SQL, command injection, auth bypass, XSS surface, dependency CVEs. Output: a structured finding list with severity. Sets metadata.security_blocking=true if any high-severity finding requires resolution before merge.
Stage 2 — Style check
Run the repo's linter + formatter + test suite. Capture counts and diffs. No human judgment yet; just structured signals.
Stage 3 — Human-readable summary
The reviewer reads the previous two stages' output and writes a structured PR comment with: TL;DR, security findings, style findings, test coverage delta, and a final recommendation (approve / request_changes / comment). Posts the comment back to the PR. Approval gate before done so a human signs off on the recommendation before it goes live.
Total budget cap
~$5 per PR. Tunable per-repo via task budgets.
When to use vs not
✓ Use it when you maintain a repo with frequent contributions, want consistent review quality, and trust the security-reviewer's track record.
✗ Skip it when:
- Solo dev on personal projects (overhead > value)
- The PR is from a long-trusted maintainer (manual review is fine + faster)
- The repo has special context the pipeline doesn't know (use
ship-a-feature for those)
Auto-trigger (Phase 2+)
Wire to Vodou-channels webhook for pull_request.opened events. The webhook handler creates the task with metadata.pr_url set + workflow_template_id="pr-review-pipeline". The board takes over from there.
1---2name: pr-review-pipeline3description: workflow template — automated pull request review with security audit + style check + summary; pre-installed, activates in Phase 24---56# pr-review-pipeline78A 3-stage automated PR review: security audit, style/linting pass, then human-readable summary. Useful for open-source maintainers, ExecDesk CTO reviews, or compliance trails.910**Phase 1 status:** pre-installed but inactive.1112## Inputs1314Tasks bound to this template must have `metadata.pr_url` set at creation (e.g. via webhook from GitHub's `pull_request.opened` event, or manually via `./do board create … --metadata '{"pr_url": "https://github.com/...PR/123"}'`).1516## Stages1718### Stage 1 — Security audit1920<!-- AGENT_ACTIONS_1: {21 "step_key": "security_audit",22 "assignee_default": "security-reviewer",23 "skills": ["board-worker", "security-pr-audit", "github-code-review"],24 "workspace": "scratch",25 "required_artifacts": {26 "metadata.security_findings_count": "^[0-9]+$",27 "metadata.security_blocking": "^(true|false)$"28 },29 "on_success": "style_check",30 "on_failure": "security_audit",31 "max_runtime_seconds": 1800,32 "max_retries": 1,33 "budget_usd_cap": 2.5034} -->3536Pull the PR diff, scan for: secrets in code (API keys, tokens, .env contents), unsafe SQL, command injection, auth bypass, XSS surface, dependency CVEs. Output: a structured finding list with severity. Sets `metadata.security_blocking=true` if any high-severity finding requires resolution before merge.3738### Stage 2 — Style check3940<!-- AGENT_ACTIONS_2: {41 "step_key": "style_check",42 "assignee_default": "engineer",43 "skills": ["board-worker", "lint-runner"],44 "workspace": "worktree",45 "required_artifacts": {46 "metadata.lint_errors": "^[0-9]+$",47 "metadata.format_diff_lines": "^[0-9]+$",48 "metadata.tests_run": "^[0-9]+$"49 },50 "on_success": "summary",51 "on_failure": "style_check",52 "max_runtime_seconds": 1200,53 "max_retries": 1,54 "budget_usd_cap": 1.0055} -->5657Run the repo's linter + formatter + test suite. Capture counts and diffs. No human judgment yet; just structured signals.5859### Stage 3 — Human-readable summary6061<!-- AGENT_ACTIONS_3: {62 "step_key": "summary",63 "assignee_default": "reviewer",64 "skills": ["board-worker", "pr-summary-writer"],65 "workspace": "scratch",66 "required_artifacts": {67 "metadata.summary_posted_to_pr": "^true$",68 "metadata.recommendation": "^(approve|request_changes|comment)$"69 },70 "on_success": null,71 "on_failure": "summary",72 "max_runtime_seconds": 900,73 "budget_usd_cap": 1.50,74 "requires_approval_on": ["running→done"]75} -->7677The reviewer reads the previous two stages' output and writes a structured PR comment with: TL;DR, security findings, style findings, test coverage delta, and a final recommendation (approve / request_changes / comment). Posts the comment back to the PR. Approval gate before `done` so a human signs off on the recommendation before it goes live.7879## Total budget cap8081~$5 per PR. Tunable per-repo via task budgets.8283## When to use vs not8485✓ **Use it when** you maintain a repo with frequent contributions, want consistent review quality, and trust the security-reviewer's track record.8687✗ **Skip it when**:88- Solo dev on personal projects (overhead > value)89- The PR is from a long-trusted maintainer (manual review is fine + faster)90- The repo has special context the pipeline doesn't know (use `ship-a-feature` for those)9192## Auto-trigger (Phase 2+)9394Wire to `Vodou-channels` webhook for `pull_request.opened` events. The webhook handler creates the task with `metadata.pr_url` set + `workflow_template_id="pr-review-pipeline"`. The board takes over from there.
VodouAI