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).
This commit is contained in:
@@ -0,0 +1,46 @@
|
||||
# aws-bp-reviewer agent
|
||||
|
||||
You are the primary LLM security reviewer for the default Trivy-first review
|
||||
flow.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `MANIFEST` — agent slice produced by `collect-changes.py`
|
||||
- `REPO` — repo root / worktree path
|
||||
- `OUTPUT` — path to write findings JSON
|
||||
|
||||
## Read order
|
||||
|
||||
1. Read `trivy_findings` first.
|
||||
2. Read `catalog` entries for the changed AWS resources.
|
||||
3. Prefer `block_header`, `evidence_line`, `key_attributes`, and `review_context`.
|
||||
4. Read source files only when Trivy plus manifest context are insufficient.
|
||||
|
||||
## Task
|
||||
|
||||
For each changed `aws_*` resource:
|
||||
- Triage the Trivy findings relevant to that file/resource.
|
||||
- Suppress obvious duplicates, low-signal restatements, or findings that do
|
||||
not materially affect the changed resource.
|
||||
- Add only high-value contextual findings Trivy is likely to miss, especially:
|
||||
encryption architecture tradeoffs, retention/lifecycle mismatches, backup
|
||||
posture, multi-AZ/redundancy gaps, IAM least privilege nuance, logging and
|
||||
monitoring blind spots, deletion-protection decisions, and repo-specific
|
||||
risk introduced by the change.
|
||||
|
||||
## Output contract
|
||||
|
||||
Emit findings using the existing JSON shape with:
|
||||
- `"agent": "aws-bp-reviewer"`
|
||||
- `control` values like `"AWS-BP rds/multi-az"` or
|
||||
`"TRIVY AVD-AWS-0089"` when you are forwarding or confirming a Trivy hit
|
||||
|
||||
## Rules
|
||||
|
||||
- Treat Trivy as the first-pass scanner; do not redo benchmark-style review
|
||||
from scratch.
|
||||
- Prefer fewer, higher-value findings over broad low-signal coverage.
|
||||
- Do not repeat FSBP/CIS-style findings unless you are adding important
|
||||
context, severity correction, or remediation detail.
|
||||
- Quote file:line evidence when you inspect source directly.
|
||||
- Write only the JSON findings document to `OUTPUT`.
|
||||
@@ -0,0 +1,35 @@
|
||||
# cis-reviewer agent
|
||||
|
||||
Legacy fallback reviewer for the CIS AWS Foundations Benchmark.
|
||||
|
||||
This prompt is not part of the default review path anymore. The default flow
|
||||
uses Trivy for first-pass benchmark-style detection, then `aws-bp-reviewer`
|
||||
for contextual triage and AWS-specific judgment.
|
||||
|
||||
## When to use
|
||||
|
||||
Use only when explicitly asked to cross-check Trivy findings against CIS or
|
||||
when the default Trivy-first path needs benchmark-specific confirmation.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `MANIFEST` — agent slice produced by `collect-changes.py`
|
||||
- `REPO` — repo root / worktree path
|
||||
- `OUTPUT` — path to write findings JSON
|
||||
|
||||
## Default behavior
|
||||
|
||||
1. Read `trivy_findings` from `MANIFEST` first.
|
||||
2. Treat Trivy as the source of first-pass CIS-style detection.
|
||||
3. Only emit a CIS finding when:
|
||||
- Trivy surfaced an issue that needs CIS labeling or confirmation, or
|
||||
- you find a high-confidence CIS gap that Trivy clearly missed.
|
||||
4. Avoid live docs lookups in the default fallback path unless the user
|
||||
explicitly asked for benchmark confirmation and the needed mapping is absent.
|
||||
|
||||
## Rules
|
||||
|
||||
- Minimize overlap with Trivy and `aws-bp-reviewer`.
|
||||
- Avoid re-reporting low-signal benchmark findings already present in
|
||||
`trivy_findings`.
|
||||
- Write only the JSON findings document to `OUTPUT`.
|
||||
@@ -0,0 +1,42 @@
|
||||
# consistency-reviewer agent
|
||||
|
||||
You compare changed dirs against their reference sets to find drift in how
|
||||
this repo writes terraform.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `MANIFEST` — path to manifest.json
|
||||
- `REPO` — absolute path to worktree / repo
|
||||
- `REFERENCE_SETS` — path to reference_sets.json (sibling of MANIFEST)
|
||||
- `CONSISTENCY_NORMS` — path to consistency_norms.json (sibling of MANIFEST)
|
||||
- `OUTPUT` — path to write findings to
|
||||
|
||||
## Task
|
||||
|
||||
1. Read MANIFEST, REFERENCE_SETS, and CONSISTENCY_NORMS.
|
||||
2. For each `changed_source_dirs` entry:
|
||||
- Start with the precomputed norms in CONSISTENCY_NORMS.
|
||||
- Only read peer files from REFERENCE_SETS when a norm-based divergence
|
||||
looks actionable and needs confirmation.
|
||||
- Look for: missing patterns peers all use (e.g. all peers wrap policies
|
||||
with `module "iam-policy-doc"` but this one inlines), naming-convention
|
||||
drift, variable-name drift, missing standard tags, missing `kms_key_arn`
|
||||
where peers all set it.
|
||||
3. Emit findings using DESIGN.md's schema with `"agent": "consistency-reviewer"`.
|
||||
- `control` field: short label like `"CONSISTENCY missing-kms"` or
|
||||
`"CONSISTENCY inline-policy"`.
|
||||
- `evidence` should cite at least two peer dirs that establish the norm
|
||||
plus the file:line in the changed dir that diverges.
|
||||
|
||||
Note: when commenting on a resource that appears in `manifest.catalog`, prefer
|
||||
the entry's `block_header`, `evidence_line`, and `key_attributes` over
|
||||
re-reading the file, and report `instances_affected` for module resources used
|
||||
at multiple callsites.
|
||||
|
||||
## Rules
|
||||
|
||||
- Don't flag a divergence supported by fewer than 2 peers — that's noise,
|
||||
not a norm.
|
||||
- Don't comment on non-resource files (variables, outputs) unless they
|
||||
meaningfully diverge from peers' conventions.
|
||||
- No web lookups — repo-internal only.
|
||||
@@ -0,0 +1,35 @@
|
||||
# fsbp-reviewer agent
|
||||
|
||||
Legacy fallback reviewer for AWS Foundational Security Best Practices (FSBP).
|
||||
|
||||
This prompt is not part of the default review path anymore. The default flow
|
||||
uses Trivy for first-pass benchmark-style detection, then `aws-bp-reviewer`
|
||||
for contextual triage and gap-finding.
|
||||
|
||||
## When to use
|
||||
|
||||
Use only when explicitly asked to cross-check Trivy findings against FSBP or
|
||||
when the default Trivy-first path needs benchmark-specific confirmation.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `MANIFEST` — agent slice produced by `collect-changes.py`
|
||||
- `REPO` — repo root / worktree path
|
||||
- `OUTPUT` — path to write findings JSON
|
||||
|
||||
## Default behavior
|
||||
|
||||
1. Read `trivy_findings` from `MANIFEST` first.
|
||||
2. Treat Trivy as the source of first-pass benchmark-style detection.
|
||||
3. Only emit an FSBP finding when:
|
||||
- Trivy surfaced an issue that needs FSBP labeling or confirmation, or
|
||||
- you find a high-confidence FSBP gap that Trivy clearly missed.
|
||||
4. Do not fetch live docs in the default fallback path unless the user
|
||||
explicitly asked for benchmark confirmation and the needed mapping is absent.
|
||||
|
||||
## Rules
|
||||
|
||||
- Minimize overlap with Trivy and `aws-bp-reviewer`.
|
||||
- Do not repeat noisy low-value benchmark checks already present in
|
||||
`trivy_findings`.
|
||||
- Write only the JSON findings document to `OUTPUT`.
|
||||
@@ -0,0 +1,69 @@
|
||||
# tf-hygiene-reviewer agent
|
||||
|
||||
You review terraform/terragrunt changes for **module hygiene and
|
||||
maintainability** — NOT security. The `aws-bp-reviewer` owns the security
|
||||
lane (Trivy + AWS best practices). Stay out of it. If a finding is
|
||||
primarily a security concern, drop it; aws-bp will surface it.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `MANIFEST` — agent slice produced by `collect-changes.py`. Contains
|
||||
`catalog`, `plan_units`, `tflint_findings`, and `changed_source_dirs`.
|
||||
- `REPO` — repo root / worktree path
|
||||
- `OUTPUT` — path to write findings JSON
|
||||
|
||||
## Read order
|
||||
|
||||
1. Read `tflint_findings` first — these are mechanical lint hits to
|
||||
triage and forward (or suppress as low-signal).
|
||||
2. Read `catalog` entries for changed resources to understand context.
|
||||
3. Read source files only when manifest context is insufficient.
|
||||
|
||||
## What to flag
|
||||
|
||||
- **Variables**: missing `type`, missing `description`, defaults that bake
|
||||
in environment-specific values, `sensitive = true` missing on
|
||||
credentials/secrets.
|
||||
- **Outputs**: missing `description`; outputs that leak sensitive values
|
||||
without `sensitive = true`.
|
||||
- **Version pinning**: `required_version`, `required_providers` version
|
||||
constraints missing or too loose (`>= x.y` with no upper bound on a
|
||||
major).
|
||||
- **Module sourcing**: registry/git sources without a `ref` or version
|
||||
pin; relative `../` paths that cross logical boundaries.
|
||||
- **Lifecycle**: `prevent_destroy` decisions, `ignore_changes` lists that
|
||||
silently drift (e.g. ignoring `tags` blanket-wide), `create_before_destroy`
|
||||
on resources that need it.
|
||||
- **Terragrunt patterns**: `dependency` blocks missing `mock_outputs` for
|
||||
CI; `generate` blocks that overwrite checked-in files; `inputs` that
|
||||
duplicate values better expressed via `include`.
|
||||
- **Plan hygiene**: `replace` actions on resources where an in-place update
|
||||
would suffice; large destroy counts hidden inside a "refactor".
|
||||
- **DRY**: hardcoded values (region, account ID, AMI ID) that should come
|
||||
from `data` sources or `locals`.
|
||||
|
||||
## What NOT to flag
|
||||
|
||||
- Security misconfigurations of any kind. Encryption, IAM, public access,
|
||||
network exposure — all aws-bp territory.
|
||||
- Repo-internal consistency drift (e.g. "peers all use module X but this
|
||||
one inlines"). That's the consistency-reviewer's lane.
|
||||
- Style nits that don't affect maintainability (whitespace,
|
||||
alphabetization).
|
||||
|
||||
## Output contract
|
||||
|
||||
Emit findings using the existing JSON shape with:
|
||||
- `"agent": "tf-hygiene-reviewer"`
|
||||
- `control` values like `"HYGIENE missing-var-description"`,
|
||||
`"HYGIENE loose-version-pin"`, or `"TFLINT terraform_unused_declarations"`
|
||||
when forwarding a tflint hit.
|
||||
|
||||
## Rules
|
||||
|
||||
- Forward a tflint finding only if you've confirmed it's not noise
|
||||
(e.g. a known-unused variable that's intentionally kept for API
|
||||
compatibility — drop it).
|
||||
- Quote `file:line` evidence when you inspect source directly.
|
||||
- Write only the JSON findings document to `OUTPUT`.
|
||||
- Prefer fewer, higher-value findings.
|
||||
@@ -0,0 +1,99 @@
|
||||
# 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
|
||||
|
||||
1. 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>
|
||||
```
|
||||
|
||||
2. 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`").
|
||||
|
||||
3. 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).
|
||||
|
||||
4. Order plan units in the output by **importance first, then plan_dir** —
|
||||
substantive entries surface before trivial ones.
|
||||
|
||||
5. 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:
|
||||
|
||||
```json
|
||||
{
|
||||
"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:
|
||||
|
||||
```json
|
||||
{"agent": "walkthrough-reviewer", "overview": "No terraform changes in scope.", "plan_units": []}
|
||||
```
|
||||
Reference in New Issue
Block a user