Automated Review Workflow

Example CPG workflow

This page demonstrates how to compose existing CPG tools into a review pipeline. A dedicated review skill suite is not yet implemented — the workflow below is performed manually using individual MCP tool calls.

Apogee provides a structured automated review pipeline that combines CPG-based code analysis with lifecycle governance. This page shows how the components connect end-to-end.

Overview

The review pipeline takes a code change (commit, PR, or feature branch) and produces structured findings with severity, evidence, and a merge recommendation. It uses CPG tools for structural analysis, lifecycle skills for review structure, and governance gates for quality decisions.

Components involved

Component

Type

Role in review

cpg_impact_analysis

MCP tool

Blast radius: which functions are affected, how many callers

cpg_security_scan

MCP tool

Taint analysis, dead code, risk scoring

cpg_branch_divergence_report

MCP tool

Structural differences between source and target branches

cpg_function_complexity

MCP tool

Complexity hotspots in changed code

Code review persona

Persona skill

Review framing: attack dimensions, finding format, routing

Change impact review

CPG workflow

Diff two commits, assess blast radius per changed function

Subsystem security audit

CPG workflow

Trace data flow from entry points to sensitive sinks

Post-feature review

Post-feature workflow

Stabilization, test automation, integration coverage, adversarial check

Post-review comment

Task skill

Format findings into postable comment (GitHub, GitLab, Jira, stdout)

Governance gates

Gate system

Blocker/warning/acceptable severity enforcement at review boundaries

End-to-end flow

Step 1 — Structural analysis

The reviewer starts with CPG impact analysis on the changed files:

cpg_impact_analysis(changed_functions, branch="feature-x", target="main")

This produces a per-function blast radius report: callers affected, callees depended on, and a risk ranking. Functions touching many callers or crossing subsystem boundaries get flagged as high-impact.

Step 2 — Security scan

For high-impact changes, run a compound security scan:

cpg_security_scan(branch="feature-x", subsystem="drivers/gpu")

This combines taint analysis (untrusted input → sensitive sink), dead code detection, and risk scoring into a single report. Findings include the taint path with source and sink locations.

Step 3 — Branch divergence

Compare the feature branch against the target:

cpg_branch_divergence_report(branch_a="feature-x", branch_b="main")

This shows which functions were added, removed, or modified, with body-hash comparison and safety-flag divergence. Functions that exist in both branches but have different safety profiles (e.g., bounds checking added or removed) are flagged.

Step 4 — Structured review

The change impact review workflow (cpg_analysis/change_impact_review) combines Steps 1-3 into a ranked change-impact report. Each changed function gets an impact score based on blast radius, complexity delta, and safety-flag changes. The report includes a merge recommendation:

  • Merge — changes are low-impact and well-contained

  • Merge with conditions — specific functions need test coverage

  • Block — high-impact changes with safety divergence or missing tests

Step 5 — Post-feature review

After implementation, the post-feature review workflow runs four dimensions in parallel:

  1. Stabilization — are tests passing? Any flaky tests introduced?

  2. Test automation discovery — what new behavior lacks test coverage?

  3. Integration coverage — do integration tests cover the changed surfaces?

  4. Adversarial design check — could the change be exploited or misused?

Step 6 — Format and post findings

The post_review_comment task skill formats findings into a standardized Markdown comment with severity-ordered findings, evidence paths, and merge recommendation. Supports GitHub (gh pr comment), GitLab (glab mr comment), Jira, and stdout targets. Privacy-aware: redacts apogee_artifacts/ content from posted comments.

When to use

  • PR review — run Steps 1-4 on a feature branch before merge

  • Post-implementation review — run Step 5 after feature completion

  • CI integration — run Steps 1-3 headless in a pipeline, post findings as PR comments via Step 6

  • Security audit — run Step 2 scoped to a subsystem for targeted taint analysis

See also