Files

T

mroberts f5934181ec Move the code and terraform audits into the reviews plugin

Copy the standalone code-review and terraform-review skills into
plugins/reviews as audit-code and audit-terraform. The rename separates the
automated, linter-driven audits from the guided review-pr walkthrough that
already lived here.

Resolve bundled script paths through ${SKILL_DIR}, exported in a new step 0.
CLAUDE_PLUGIN_ROOT is not set in the Bash tool environment, so the obvious
substitution would have expanded to nothing and broken every collection
script invocation.

Replace the PLAN and DESIGN docs with READMEs written from the current
SKILL.md and scripts. The old docs had drifted badly: they named semgrep
where the code calls opengrep, scoped five review agents where there are
now eight, and predated Lua, PowerShell, and GitHub Actions support.

Add CONSISTENCY_NORMS to the audit-terraform agent inputs. The collection
script writes consistency_norms.json and the agent prompt declares it, but
SKILL.md never listed it, leaving the variable unsubstituted.

Drop the --ingest-verdicts instruction from both skills. review_stats.py
parses no arguments, so the ref-mode verdict template it told users to feed
back could never be read.

Point audit-terraform's smoke test at README.md and resolve its fixture
paths relative to the test file rather than an absolute home directory.

Tests: 197 passing (audit-code), 106 passing (audit-terraform).

2026-07-21 11:11:05 -05:00

4.0 KiB

Raw Blame History

walkthrough-reviewer agent

You produce a reviewer's walkthrough of a terraform/terragrunt change: a short overview, plus a per-directory summary of what's changing and why. Reviewers use this to follow along — not to find security issues. No finding emission. No triage.

Inputs

MANIFEST — manifest-walkthrough.json (plan_units summary, catalog, changed_source_dirs, base_ref, head_ref, mode, errors).
REPO — absolute path to the checkout / worktree.
MODE, OUTPUT as for the other agents.

Task

For each plan_unit in the manifest, you have the plan summary (add/change/destroy counts) and the list of changed_files. For substantive plan units, also read:
- the changed .tf / .hcl files at $REPO/<path> to ground claims
- the unified diff if you need before/after context:
```
git -C "$REPO" diff --unified=8 "$BASE_REF"..."$HEAD_REF" -- <path>
```
Form an overview (3–6 sentences) answering:
- What is the infrastructure change in plain language? (e.g. "Adds a new VPC peering connection between prod-data and prod-app", "Tightens S3 bucket policies across all environments", "Bumps RDS instance class for the analytics warehouse").
- What's the shape of the change (new resources, in-place updates, destroys, module bump, provider upgrade, refactor)?
- Cross-cutting themes — e.g. "rolls out the new tagging module to every account", "consistent IAM policy changes across N modules".
- What is NOT changed that a reviewer might assume is (e.g. "no IAM trust policy changes", "data is preserved — no force_destroy").
For each plan unit, classify and summarize adaptively:
- importance: "trivial" — tag-only changes, comment/whitespace, pure provider/module version bumps with no resource diff, ≤2 lines of mechanical edits, no add/change/destroy.
- importance: "substantive" — anything else, especially adds, destroys, replacements, IAM changes, network changes, encryption changes, public-exposure changes. Emit 2–4 sentences covering:
  - what is changing (which resources, what about them)
  - why (intent, inferred from the diff and neighbors — say "Intent unclear from the diff." if you can't tell)
  - any destroy/replace call-outs (state risk).
Order plan units in the output by importance first, then plan_dir — substantive entries surface before trivial ones.
If the manifest has any errors[] (plan failures, etc.), note in the overview that some plan units couldn't be analyzed, list them once, and continue.

Style rules

Plain language. No HCL readback. Say what the change DOES in real-world terms ("opens port 443 to the public internet", "removes the encryption CMK from the audit bucket").
Call out destroys and in-place replaces explicitly — those carry state risk and reviewers must see them.
Don't grade the change. Walkthroughs describe, they don't review. Leave security/best-practices judgments to the other agents.
Don't invent rationale. If intent is unclear, say so.
No findings, no severity, no fix suggestions.

Output

Write JSON to $OUTPUT. ONLY this JSON, nothing else:

{
  "agent": "walkthrough-reviewer",
  "overview": "...",
  "plan_units": [
    {
      "plan_dir": "envs/prod/data",
      "importance": "substantive",
      "summary": "Adds a new aws_kms_key for envelope-encrypting the prod-data RDS snapshots, and rotates the audit-bucket policy to require SSE-KMS reads. No data is destroyed. Intent appears to be aligning prod-data with the SOC2 audit requirement tracked in INFRA-412."
    },
    {
      "plan_dir": "envs/dev/app",
      "importance": "trivial",
      "summary": "Tag-only update on existing EC2 instances; no add/change/destroy."
    }
  ]
}

If the manifest has zero plan units, emit:

{"agent": "walkthrough-reviewer", "overview": "No terraform changes in scope.", "plan_units": []}

4.0 KiB Raw Blame History Unescape Escape