diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 953664493..c3d94da3c 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -206,7 +206,7 @@ "name": "code-review", "source": "./plugins/code-review", "description": "Automated code quality review with language-aware analysis for pre-commit verification", - "version": "0.0.7" + "version": "0.0.10" }, { "name": "golang", diff --git a/PLUGINS.md b/PLUGINS.md index fe4379aa5..4c09e3f33 100644 --- a/PLUGINS.md +++ b/PLUGINS.md @@ -100,6 +100,7 @@ See [plugins/ci/README.md](plugins/ci/README.md) for detailed documentation. Automated code quality review with language-aware analysis for pre-commit verification **Commands:** +- **`/code-review:panel-review` `[--serial] [--comment] [--coderabbit] [pr-url-or-number]`** - Comprehensive multi-perspective code review with architecture, security, consistency, QA, and adversarial analysis - **`/code-review:pr` ` [--language ] [--profile ] [--skip-build] [--skip-tests]`** - Automated PR code quality review with language-aware analysis and project-specific profiles - **`/code-review:pre-commit-review` `[--language ] [--profile ] [--skip-build] [--skip-tests]`** - Automated pre-commit code quality review with language-aware analysis and project-specific profiles diff --git a/docs/data.json b/docs/data.json index fcde4773e..1e6ecde0b 100644 --- a/docs/data.json +++ b/docs/data.json @@ -1655,6 +1655,12 @@ }, { "commands": [ + { + "argument_hint": "[--serial] [--comment] [--coderabbit] [pr-url-or-number]", + "description": "Comprehensive multi-perspective code review with architecture, security, consistency, QA, and adversarial analysis", + "name": "panel-review", + "synopsis": "/code-review:panel-review [--serial] [--comment] [--coderabbit] [pr-url-or-number]" + }, { "argument_hint": " [--language ] [--profile ] [--skip-build] [--skip-tests]", "description": "Automated PR code quality review with language-aware analysis and project-specific profiles", @@ -1687,9 +1693,14 @@ "description": "Project-specific review profile for the openshift/hypershift repository \u2014 delegates to the repo's own agents and skills", "id": "profile-hypershift", "name": "HyperShift Project Profile" + }, + { + "description": "Multi-specialist panel review. Dispatches 7 parallel sub-agent reviewers (Architecture, Security & Supply Chain, UX/API, Codebase Consistency, QA Engineer, Devil's Advocate, Technical Writer) then a Panel Arbiter synthesizes one verdict.", + "id": "review-panel", + "name": "review-panel" } ], - "version": "0.0.7" + "version": "0.0.10" }, { "commands": [ diff --git a/plugins/code-review/.claude-plugin/plugin.json b/plugins/code-review/.claude-plugin/plugin.json index 465b490cc..4e4d28893 100644 --- a/plugins/code-review/.claude-plugin/plugin.json +++ b/plugins/code-review/.claude-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "code-review", "description": "Automated code quality review with language-aware analysis for pre-commit verification", - "version": "0.0.7", + "version": "0.0.10", "author": { "name": "github.com/openshift-eng" } diff --git a/plugins/code-review/README.md b/plugins/code-review/README.md index 65b2dbbfb..07f4d5814 100644 --- a/plugins/code-review/README.md +++ b/plugins/code-review/README.md @@ -4,6 +4,33 @@ Automated code quality review with language-aware analysis for pre-commit verifi ## Commands +### `/code-review:panel-review` + +Comprehensive multi-perspective code review with architecture, security, consistency, QA, adversarial, and documentation analysis. Seven specialist reviewers execute in parallel as sub-agents, each examining the changes through a different lens. After all reviewers complete, a Panel Arbiter synthesizes findings, resolves disagreements, and produces a single verdict. + +Inspired by Microsoft's [APM Review Panel](https://github.com/microsoft/apm/tree/bb94e789a888d4143e347bff9f37cdbb3ef75a63/.apm/skills/apm-review-panel). + +**Usage:** +```bash +/code-review:panel-review [pr-url-or-number] [coderabbit] +``` + +**Arguments:** +- PR identifier (optional): Full GitHub PR URL or PR number. If omitted, diffs current branch against its upstream merge base. +- External reviewers (optional): Names of external review tools to include. Currently supported: `coderabbit`. + +**Specialist Panel:** + +| Reviewer | Focus | +|----------|-------| +| Architecture | Structural patterns, SOLID, cross-file impact, module boundaries | +| Security & Supply Chain | Vulnerabilities, dependency trust, supply chain integrity | +| UX & API | Naming, error messages, API ergonomics, backwards compatibility | +| Codebase Consistency | Duplicate helpers, convention drift, style match | +| QA Engineer | Test coverage gaps, missing edge-case tests, concrete test suggestions | +| Devil's Advocate | Assumes every line is wrong; tries to break the code | +| Technical Writer | Documentation accuracy, staleness, consistency with code changes | + ### `/code-review:pre-commit-review` Performs a comprehensive code quality review of staged and unstaged changes before committing. Analyzes unit test coverage, idiomatic code patterns, DRY compliance, SOLID principles, and build verification. diff --git a/plugins/code-review/commands/panel-review.md b/plugins/code-review/commands/panel-review.md new file mode 100644 index 000000000..81a7a0878 --- /dev/null +++ b/plugins/code-review/commands/panel-review.md @@ -0,0 +1,96 @@ +--- +description: "Comprehensive multi-perspective code review with architecture, security, consistency, QA, and adversarial analysis" +argument-hint: "[--serial] [--comment] [--coderabbit] [pr-url-or-number]" +--- + +## Name +code-review:panel-review + +## Synopsis +``` +/code-review:panel-review [--serial] [--comment] [--coderabbit] [pr-url-or-number] +``` + +## Description +The `panel-review` command runs a multi-specialist review panel. Seven specialist reviewers each examine the changes through a different lens. Optionally, external review tools (like CodeRabbit) run alongside them. After all reviewers complete, an arbiter synthesizes findings, resolves disagreements, and produces a single verdict. + +By default, each specialist runs as a parallel sub-agent. Pass `--serial` to run all specialists inline in the main agent instead — this is significantly cheaper since the codebase context is derived once and shared across all specialists, but reviews run sequentially rather than concurrently. + +This panel is best suited for complex or risky changes. For routine changes, consider `/code-review:pre-commit-review` instead. + +This command does not perform build verification. Use `/code-review:pr` if build verification is needed. + +No arguments are required. By default, the command diffs the current branch against its upstream merge base. Language and profile skills are auto-detected. + +## Implementation + +### Step 1 — Parse Arguments + +Split `$ARGUMENTS` on whitespace. Classify each token: + +- A **PR URL** (contains `github.com` and `/pull/`) or **PR number** (bare integer) — pass to the skill as the PR identifier. +- `--serial` — enable serial execution mode (all specialists run inline instead of as sub-agents). +- `--comment` — post the verdict as a comment on the PR after the review completes. Requires a PR identifier. +- `--coderabbit` — include CodeRabbit as an external reviewer. +- **Anything else** — warn and ignore. + +If more than one PR identifier is found, error and exit. + +### Step 2 — Execute the Review Panel + +Read `skills/review-panel/SKILL.md` relative to the plugin root directory. Follow its instructions for all remaining work — diff resolution, language detection, sub-agent dispatch, arbitration, and verdict. + +Pass to the skill: +- The PR identifier (if any) +- The list of requested external reviewers (if any) +- Whether serial mode was requested +- Whether comment mode was requested + +If `--comment` is passed without a PR identifier, error and exit — a PR is required to post a comment. + +## Return Value +- **Format**: Structured verdict using the template from `skills/review-panel/verdict-template.md`. +- **Success**: Verdict with APPROVE or NEEDS_DISCUSSION disposition. +- **Failure**: Verdict with REQUEST_CHANGES and blocking findings listed. + +## Examples + +1. **Review current branch (default)**: + ``` + /code-review:panel-review + ``` + +2. **Review with CodeRabbit**: + ``` + /code-review:panel-review --coderabbit + ``` + +3. **Review current branch in serial mode (cheaper)**: + ``` + /code-review:panel-review --serial + ``` + +4. **Review a PR and post the verdict as a comment**: + ``` + /code-review:panel-review --comment 456 + ``` + +5. **Review a specific PR with CodeRabbit**: + ``` + /code-review:panel-review https://github.com/openshift/hypershift/pull/789 --coderabbit + ``` + +6. **Review by PR number in current repo**: + ``` + /code-review:panel-review 456 + ``` + +## See Also +- `/code-review:pr` — single-reviewer analysis with build verification, language-specific idiom checks, and SOLID/DRY compliance +- `/code-review:pre-commit-review` — lightweight pre-commit review of staged changes + +## Arguments: +- PR identifier (optional): Full GitHub PR URL or PR number. If omitted, diffs current branch against its upstream merge base. +- `--serial` (optional): Run all specialists inline in the main agent instead of as parallel sub-agents. Cheaper but sequential. +- `--comment` (optional): Post the verdict as a comment on the PR. Requires a PR identifier. +- `--coderabbit` (optional): Include CodeRabbit as an external reviewer. Runs in parallel with (or alongside, in serial mode) internal specialists. diff --git a/plugins/code-review/skills/review-panel/SKILL.md b/plugins/code-review/skills/review-panel/SKILL.md new file mode 100644 index 000000000..48ab9ad5b --- /dev/null +++ b/plugins/code-review/skills/review-panel/SKILL.md @@ -0,0 +1,407 @@ +--- +name: "review-panel" +description: "Multi-specialist panel review. Dispatches 7 parallel sub-agent reviewers (Architecture, Security & Supply Chain, UX/API, Codebase Consistency, QA Engineer, Devil's Advocate, Technical Writer) then a Panel Arbiter synthesizes one verdict." +--- + +# Review Panel — Multi-Specialist Review Orchestration + +The panel dispatches **7 specialist reviewers + 1 arbiter = 8 persona +sections in one verdict**. The Panel Arbiter runs after all specialists +complete, synthesizes findings, resolves disagreements, and produces +the final disposition. + +**Two execution modes:** + +- **Parallel (default)**: Each specialist runs as a dedicated sub-agent + concurrently. Thorough but expensive — each sub-agent independently + derives its own view of the codebase. +- **Serial (`--serial`)**: All specialists run inline in the main agent, + one after another. Significantly cheaper because the codebase context + is derived once and shared across all specialists. Trade-off: reviews + run sequentially, and each specialist can see prior specialists' + file reads (though not their findings). + +## Agent Roster + +| Agent | Lens | Dispatch | +|-------|------|----------| +| Architecture Reviewer | Structural patterns, cross-file impact, SOLID, module boundaries | Always, parallel | +| Security & Supply Chain Reviewer | Vulnerabilities, credential handling, dependency trust, supply chain integrity | Always, parallel | +| UX & API Reviewer | Public API ergonomics, error messages, naming, backwards compatibility | Always, parallel | +| Codebase Consistency Reviewer | Duplicate helpers, convention drift, style match with existing code | Always, parallel | +| QA Engineer | Test coverage gaps, missing edge-case tests, test quality, untested error paths | Always, parallel | +| Devil's Advocate | Assumes every line is wrong until proven otherwise; tries to break the code | Always, parallel | +| Technical Writer | Documentation accuracy, completeness, consistency with code changes | Always, parallel | +| Panel Arbiter | Strategic synthesis, disagreement resolution, final disposition | Always, after all specialists | + +## Routing Topology + +``` + architecture security ux-api consistency qa devils-advocate tech-writer + \__________|_________|__________|__________|_________|__________/ + | + v + panel-arbiter + (final call / arbiter) +``` + +- **Specialists raise findings independently** — no implicit consensus. + Each runs as a separate sub-agent and cannot see the others' output. +- **Panel Arbiter synthesizes** after all specialist sub-agents complete. + The arbiter receives every specialist's findings and resolves conflicts, + weighs trade-offs, and makes the final call. + +## Specialist Scope + +### Architecture Reviewer + +Reviews structural quality of the change: + +- **Single Responsibility**: Does each new function/type/module have one clear job? +- **Cross-file impact**: Do changes ripple correctly through callers and dependents? +- **Abstraction level**: Are new abstractions justified or premature? +- **Module boundaries**: Are package/module imports clean? Any circular dependencies? +- **Error handling**: Are errors propagated correctly? No swallowed errors? +- **Pattern consistency**: Do new patterns match existing architectural conventions? + +Anti-patterns to flag: god functions, shotgun surgery, feature envy, +inappropriate intimacy, premature abstraction. + +### Security & Supply Chain Reviewer + +Maps the change against vulnerability classes AND supply chain risk. +This reviewer operates with a **fails-closed** bias — when uncertain +whether a pattern is safe, flag it. False positives are preferable to +missed vulnerabilities. + +**Important**: the fails-closed bias applies to **factual uncertainty +about whether code is safe**, not to value judgments about architectural +style. If you are unsure whether an input is validated, flag it. If you +merely prefer a different design, that belongs in the Architecture +Reviewer's scope. + +**Vulnerability surfaces:** +- **Injection**: SQL, command, template, log, header injection +- **Authentication/authorization**: Token handling, permission checks, credential storage +- **Input validation**: Untrusted input at system boundaries +- **Secret management**: Hardcoded secrets, secrets in logs, config exposure +- **Cryptography**: Weak algorithms, improper random number generation + +**Supply chain risk (critical focus):** +- **New dependencies**: Is the dependency necessary or can stdlib/existing deps cover it? + Is it actively maintained? Does it have a known security track record? How many + transitive dependencies does it pull in? +- **Dependency changes**: Version bumps, removed pins, loosened constraints. Do the + changes match what's expected? Any yanked versions? +- **Lockfile integrity**: Does `go.sum`, `package-lock.json`, `yarn.lock`, `Cargo.lock`, + etc. contain only expected changes? Unexpected hash changes are a red flag. +- **Build pipeline changes**: CI config, Makefile, Dockerfile, build scripts — do they + introduce untrusted sources, download URLs, or execution of remote code? +- **Transitive trust**: Does the change increase the trust boundary? New external API + calls, new download URLs, new certificate trust, new registry sources? +- **Vendored code**: If vendoring is used, do vendored changes match declared dependency + changes? Unexplained vendored diffs are suspicious. + +### UX & API Reviewer + +Reviews the developer/user-facing surface: + +- **Naming**: Are new functions, flags, types, and variables self-explanatory? +- **Error messages**: Does every error tell the user what went wrong and what to do next? +- **API ergonomics**: Are interfaces minimal and hard to misuse? +- **Backwards compatibility**: Does the change break existing callers? +- **Documentation**: Are new public APIs documented? Are existing docs updated? +- **Flag/option design**: Do new CLI flags or config options follow existing conventions? + +### Codebase Consistency Reviewer + +Ensures the PR does not introduce drift from existing codebase patterns. +This reviewer must **actively read existing code** in the repository — +grep and find to locate potential duplicates and existing conventions +rather than reviewing the diff in isolation. + +- **Duplicate helpers**: Does the PR introduce a function, utility, or pattern that + already exists elsewhere in the codebase? Search for similar implementations before + accepting new ones. Grep for function names, key algorithmic patterns, and string + constants that look reusable. +- **Convention adherence**: Does new code follow the same naming conventions, file + organization, import ordering, and structural patterns as existing code in the + same package/module? +- **Style match**: Does the code style (error handling idiom, logging pattern, + test structure, comment style) match the surrounding codebase? +- **Shared utilities**: When the PR introduces logic that could be shared, does it + use the project's established utility packages/modules rather than inlining? +- **Configuration patterns**: Do new config values, environment variables, or + constants follow the existing naming and placement conventions? +- **Test patterns**: Do new tests follow the same structure, assertion style, and + helper usage as existing tests in the same package? + +### QA Engineer + +Reviews test coverage and quality for the change: + +- **Coverage gaps**: For each new or modified function with non-trivial logic, + verify that tests exist. Flag public/exported functions that lack tests entirely. +- **Untested error paths**: Identify error branches, edge cases, and failure modes + in the new code that have no corresponding test. +- **Test quality**: Are tests asserting meaningful behavior or just achieving line + coverage? Look for tests that pass trivially, assert nothing, or test + implementation details rather than behavior. +- **Edge cases**: Identify concrete edge-case inputs the author should test: + empty inputs, nil/null, boundary values, concurrent access, large inputs, + malformed data. +- **Regression coverage**: If the change fixes a bug, is there a test that would + have caught the original bug and will prevent regression? +- **Concrete suggestions**: Do not just say "add tests." Suggest specific test + scenarios with example inputs and expected outputs when possible. + +### Devil's Advocate + +The adversarial reviewer. Assumes **every line of code is wrong until +proven otherwise**. This reviewer's job is to try to break the code. + +- **Logical correctness**: For each conditional, loop, and branch, construct + an input or state that would cause it to fail. If you cannot construct one, + say so explicitly — silence is not acquittal. +- **Hidden assumptions**: What does this code assume that is not enforced? + Nil-safety, ordering guarantees, single-threaded access, input format, + environment availability, file existence. +- **Off-by-one errors**: Examine loop bounds, slice operations, index arithmetic, + range boundaries. +- **Race conditions**: If shared state is accessed, is it protected? If goroutines + or threads are involved, can operations interleave unsafely? +- **Resource leaks**: Are file handles, connections, channels, locks, and + goroutines properly cleaned up on all paths including error paths? +- **Failure modes**: What happens when the network is down? The file doesn't exist? + The input is empty? The input is 10GB? The API returns 500? The context is + cancelled? The disk is full? +- **Implicit coupling**: Does the code depend on ordering, timing, or side effects + that are not guaranteed by the interface contract? +- **Prove it wrong or admit you can't**: For each finding, describe the specific + scenario that breaks it. If you cannot find issues, state explicitly what you + tested and why the code holds up. + +### Technical Writer + +Reviews documentation accuracy and completeness relative to the change. +This reviewer should first assess whether the repository has meaningful +documentation (READMEs, doc directories, API docs, user guides, man +pages, etc.). **If the repo has little to no documentation, note this +and exit with no findings** — do not flag the absence of docs that +never existed. + +When documentation does exist: + +- **Stale docs**: Do the changes modify behavior, flags, APIs, or + configuration that is described in existing documentation? If so, + is the documentation updated to match? +- **New features**: Does the change add user-facing functionality + (new commands, flags, endpoints, config options) that should be + documented but isn't? +- **Inconsistencies**: Does existing documentation contradict the + new code? Are examples still accurate? +- **README drift**: If the project README describes setup, usage, + or architecture, does it still reflect reality after this change? +- **Inline doc quality**: For languages with doc conventions (godoc, + javadoc, docstrings), are new public APIs documented? Are existing + docs updated if signatures or behavior changed? + +## External Reviewers + +The panel optionally includes external review tools that run alongside +the internal specialists. External reviewers execute as CLI commands +in parallel with the sub-agents, and their output is included in the +Panel Arbiter's synthesis input. + +### Supported External Reviewers + +| Name | CLI Tool | Invocation | Activation | +|------|----------|------------|------------| +| CodeRabbit | `coderabbit` | `coderabbit review --agent --base ` | User passes `--coderabbit`; tool must be on PATH | + +### How External Reviewers Integrate + +- External reviewers are **not** sub-agents. They are CLI commands + invoked via Bash, running in parallel with the sub-agent dispatch. +- Their stdout is captured as-is and included in the verdict under + its own heading in the specialist findings section. +- The Panel Arbiter treats external reviewer output as a **peer + specialist**. Its findings carry the same weight as internal + specialists — corroboration strengthens confidence, conflicts + require the same explicit resolution as any inter-specialist + disagreement. +- If an external reviewer command fails (non-zero exit, tool not found), + record the error in the verdict under that reviewer's heading and + continue — never block the panel on an external tool failure. +- **Timeout**: external reviewer commands should be run with a + reasonable timeout (5 minutes). If the command exceeds this, kill it + and record a timeout error in the verdict. + +## Execution Procedure + +### Step 1 — Determine Base Ref & Gather Prior Reviews + +Figure out what the changes are being compared against: + +- **PR identifier provided**: use `gh pr view` to get the base branch. +- **No PR identifier**: find the merge base. Use the first of + `upstream/main`, `origin/main`, `upstream/master`, `origin/master` + that exists. + +If no base ref can be determined, error and exit. + +Also auto-detect language skills (`skills/lang-*/SKILL.md`) and +profile skills (`skills/profile-*/SKILL.md`) relative to the plugin +root — load any that match the repository. + +#### Prior Review Detection (PR only) + +When reviewing a PR, check for previous panel review comments: + +```bash +gh pr view --json comments --jq '.comments[] | select(.body | contains("Generated by [ai-helpers/code-review]")) | {createdAt, body}' +``` + +If prior panel reviews exist, extract their findings and pass them +to all specialists and the arbiter as context. Specialists should: + +- Note which prior findings have been addressed by subsequent commits +- Flag prior findings that remain unresolved +- Avoid re-raising issues that were already noted and resolved +- Call out any regressions — issues that were fixed but reappeared + +### Step 2 — Dispatch Specialists & External Reviewers + +#### Parallel Mode (default) + +Launch **all seven specialist sub-agents in a single message** so they +run concurrently. Each sub-agent gets: + +- Its specialist scope (from the section above) +- The base ref +- Any loaded language/profile skill content + +Sub-agents have full repo access. They read files, run git commands, +and grep the codebase themselves. Use `subagent_type: "general-purpose"`. +Do NOT set the `model` parameter. + +Each sub-agent returns findings as a list: +- Severity: BLOCKING | SUGGESTION | NOTE +- File:line reference (when applicable) +- Finding description +- Recommended action + +If no issues found, say so with what was checked. + +If external reviewers were requested, launch them in the **same +message** as the sub-agents. For CodeRabbit: + +```bash +timeout 300 coderabbit review --agent --base 2>&1 +``` + +#### Serial Mode (`--serial`) + +Run all seven specialists **inline in the main agent**, one after +another. Do **not** launch sub-agents. + +Before starting the specialist reviews, read the diff once: + +```bash +git diff ...HEAD +``` + +Then for each specialist in roster order (Architecture, Security & +Supply Chain, UX & API, Codebase Consistency, QA Engineer, Devil's +Advocate, Technical Writer): + +1. State the specialist name as a heading. +2. Review the diff and codebase through that specialist's lens using + the scope defined above. Read files, grep, and run git commands as + needed — context from earlier specialists' file reads carries over + automatically. +3. Produce findings in the same format as parallel mode: + - Severity: BLOCKING | SUGGESTION | NOTE + - File:line reference (when applicable) + - Finding description + - Recommended action +4. If no issues found, say so with what was checked. +5. Move on to the next specialist. + +If external reviewers were requested, launch them via Bash before +starting the serial specialist loop (so they run in the background +while specialists execute). For CodeRabbit: + +```bash +timeout 300 coderabbit review --agent --base 2>&1 +``` + +### Step 3 — Completeness Gate + +After all sub-agents and external reviewers return, verify all 7 +specialists produced findings (or an explicit "no issues" with +what was checked). If any specialist returned an error or empty +result, re-dispatch it **once**. If the retry also fails, record +the failure and proceed. + +External reviewer failures are non-blocking — note the error and +continue. + +### Step 4 — Panel Arbiter Synthesis + +Perform synthesis directly in the main agent (not a sub-agent): + +1. Read all specialist and external reviewer findings +2. Resolve any conflicts between specialists +3. Assign disposition: **APPROVE**, **REQUEST_CHANGES**, or + **NEEDS_DISCUSSION** +4. Compile required actions (blocking) vs optional follow-ups + +**Disposition criteria:** + +- **APPROVE**: no unresolved BLOCKING findings +- **REQUEST_CHANGES**: BLOCKING findings that require code changes +- **NEEDS_DISCUSSION**: findings that need author input to resolve + +**Arbiter biases:** + +- Security over ergonomics +- Codebase consistency over local elegance +- Existing patterns over novel ones +- Devil's Advocate concerns are blocking unless specifically refuted + by another specialist with a concrete technical explanation + +Clean changes with no issues are a valid outcome — do not +manufacture findings. + +### Step 5 — Emit Verdict + +Load `verdict-template.md` (same directory as this skill) and fill +it with findings and synthesis. One verdict, not per-specialist +outputs. Omit the "External Reviewers" section when none were +requested. + +### Step 6 — Post Comment (if `--comment`) + +If `--comment` was requested, post the verdict as a PR comment: + +```bash +gh pr comment --body "" +``` + +Use a HEREDOC to pass the verdict body to avoid shell quoting issues. +If the comment fails, report the error but still display the verdict +to the user — the review itself is not lost. + +## Quality Gates + +A change passes when: + +- [ ] Architecture Reviewer: structure and patterns are sound +- [ ] Security & Supply Chain Reviewer: no unmitigated vulnerability or supply chain risk +- [ ] UX & API Reviewer: public surfaces are clear and compatible +- [ ] Codebase Consistency Reviewer: no duplicate helpers, conventions match +- [ ] QA Engineer: adequate test coverage, edge cases addressed +- [ ] Devil's Advocate: no unrefuted failure scenarios +- [ ] Technical Writer: documentation consistent with changes +- [ ] Panel Arbiter: trade-offs ratified, disposition set diff --git a/plugins/code-review/skills/review-panel/verdict-template.md b/plugins/code-review/skills/review-panel/verdict-template.md new file mode 100644 index 000000000..0dd0f5c9f --- /dev/null +++ b/plugins/code-review/skills/review-panel/verdict-template.md @@ -0,0 +1,49 @@ +## Review Panel Verdict + +**Disposition**: + +--- + +### Specialist Findings + +**Architecture Reviewer**: + +**Security & Supply Chain Reviewer**: + +**UX & API Reviewer**: + +**Codebase Consistency Reviewer**: + +**QA Engineer**: + +**Devil's Advocate**: + +**Technical Writer**: + +--- + +### External Reviewers + +**CodeRabbit**: + +--- + +### Panel Synthesis + + + +--- + +### Required Actions Before Merge + +1. + +--- + +### Optional Follow-ups + +- + +--- + +Generated by [ai-helpers/code-review](https://github.com/openshift-eng/ai-helpers/tree/main/plugins/code-review)