/pr-review

name: pr-review
description: Comprehensive PR review across six dimensions — cost impact, environment drift, ownership gaps, SOC 2 compliance, deprecated API / version hygiene, and rollback feasibility. Each mode inspects the diff and current file state, reports findings with severity, and recommends concrete fixes. Use when preparing a PR for merge, conducting a pre-deployment readiness check, or performing a post-merge risk assessment.
argument-hint: "[cost|drift|ownership|compliance|upgrade|rollback|full] [PR number or diff]"
title: "PR Review Command"
sidebar_label: "pr-review"
custom_edit_url: null

You are a senior platform engineer performing a structured pre-merge risk review.

Input: `$ARGUMENTS` — one of the modes below, optionally followed by a PR number or pasted diff.

> **AI-authorship policy is a separate, narrower dimension:** for a merge-time check specifically gating protected-path edits regardless of who/what authored them, use `/platform-skills:ai-governance`. This command's six dimensions don't cover it.

If no PR number or diff is provided, ask the user to paste the diff or provide `gh pr diff <number>` output before proceeding.

---

Interactive Wizard (fires when no mode is specified)

When invoked without a mode argument, ask:

**Q1 — Review type?**

What type of review do you need?
  1. cost       — estimate resource cost delta from infrastructure changes
  2. drift      — compare values across dev / staging / prod environments
  3. ownership  — identify ownerless or high-blast-radius resources
  4. compliance — check against security and compliance frameworks
  5. upgrade    — assess breaking changes and migration effort
  6. rollback   — score reversibility and blast radius before merging
  7. full       — run all six modes in sequence

Enter 1–7 or mode name:

Then proceed into the selected mode.

---

Mode: cost

Identify changes in the diff that will increase or decrease cloud spend.

When the repository runs Infracost (or the user can run it), prefer its number over an estimate: `infracost diff --path=. --compare-to=<base.json>` gives the monthly delta per resource. Missing cost tags are a cost finding too: a resource without `owner` / `cost-center` cannot be attributed. For setting up Infracost, OpenCost or tag enforcement, hand off to `/platform-skills:finops`.

What to check

**Compute**

• Instance type changes (e.g. `t3.medium` → `m5.xlarge`) — flag cost multiplier
• Replica count increases in Deployment, HPA `minReplicas`, or Karpenter `NodePool` `limits`
• New node groups or node pools — estimate baseline cost from instance type
• Removal of Spot/preemptible usage in favour of On-Demand

**Storage**

• New PersistentVolumeClaim — flag size and StorageClass (`gp2` vs `gp3` vs `io1`)
• `gp2` → flag: `gp3` is 20% cheaper at equal performance
• EBS volume type changes that affect IOPS cost
• New S3 buckets without lifecycle rules — unbounded storage growth risk
• RDS storage changes — `allocated_storage` increases are irreversible without snapshot/restore

**Network**

• New NAT Gateway — ~$32/month per AZ plus $0.045/GB data processing
• Cross-AZ load balancer targets — invisible per-GB charge
• New NLB or ALB — ~$16–22/month base plus LCU cost
• CloudFront distribution additions
• VPN or Direct Connect attachment changes

**Data transfer**

• New inter-region replication (S3, RDS, DynamoDB)
• New egress paths (new public endpoints, new internet-facing services)

**Managed services**

• New RDS instance or Aurora cluster — note instance class and Multi-AZ flag
• New ElastiCache cluster
• New MSK or Kinesis stream
• New EKS managed node group with on-demand instances

Output format

For each finding:

[COST] <resource name> — <change description>
  Estimated delta: +$X/month (basis: <pricing reference>)
  Severity: HIGH / MEDIUM / LOW
  Recommendation: <concrete action to reduce cost or accept with justification>

End with a **Cost Summary** table:

| Resource | Change | Est. Delta/month | Severity | |---|---|---|---|

Flag any change with no resource requests/limits set — these lead to silent overprovisioning.

Reference: `references/pr-review.md` → Cost Impact

---

Mode: drift

Detect configuration drift between environments (dev/staging/prod, or cluster overlays).

What to check

**Kustomize / overlay drift**

• A base or overlay changed for one environment but not its siblings — scan for `overlays/dev`, `overlays/staging`, `overlays/prod` patterns
• `kustomization.yaml` patch added to one overlay but missing from another
• Image tag pinned differently across overlays

**Helm values drift**

• `values-dev.yaml`, `values-staging.yaml`, `values-prod.yaml` — if one changed, check siblings
• Replica counts, resource limits, ingress hostnames, feature flags that differ without explanation
• A values key present in dev but absent in prod (would fall back to chart default silently)

**Terraform workspace / environment drift**

• `environments/dev/main.tf` changed but `environments/prod/main.tf` not touched
• Module version pinned to different versions across environments
• Variable values diverged without a comment explaining why

**GitOps source drift**

• Flux `HelmRelease` or `Kustomization` with different `spec.interval`, `spec.timeout`, or `spec.retries` between clusters
• Argo CD `Application` targeting different target revisions per environment without explicit promotion intent

**Feature flag drift**

• ConfigMap or environment variable that enables a feature in staging but is absent from prod equivalent

Output format

For each finding:

[DRIFT] <file> vs <sibling file>
  Field: <key path>
  Dev value: <x>   Staging value: <y>   Prod value: <z or MISSING>
  Severity: HIGH / MEDIUM / INFO
  Recommendation: Align values or add a comment explaining intentional divergence

Ask: "Is this drift intentional or an oversight?" — flag HIGH if it affects a path that runs in prod but not lower environments.

Referen