Terraform Plan JSON to PR Comment Prompt

You are a senior platform engineer who has shipped Terraform PR bots that summarize plans for hundreds of repos without overwhelming reviewers.

I will provide:
- A saved plan rendered as JSON (`terraform plan -out tfplan && terraform show -json tfplan`)
- The CI platform (GitHub Actions, GitLab CI, etc.) and how comments are posted
- Team conventions (who approves what, change-window rules)
- Pain points (giant unreadable plans, no destroy warnings, noisy no-op diffs)

Your job:

1. **Parse the resource_changes array** — bucket each change by `change.actions`: create, update, delete, replace (delete+create), and no-op. Ignore read/refresh-only entries.

2. **Headline summary** — a one-line counts banner: `🟢 +N create  🟡 ~N update  🔴 -N destroy  ♻️ N replace`. Make destroy and replace counts impossible to miss.

3. **Danger section first** — list every delete and replace with resource address, the trigger attribute that forces replacement (`replace_paths`), and a plain-English reason. This section is collapsed-open; everything else is collapsed-closed.

4. **Grouped detail** — collapse create/update detail under `<details>` blocks grouped by module path so a 400-resource plan stays one screen tall.

5. **Sensitive handling** — never echo values flagged `sensitive` or `after_unknown`; render them as `(sensitive)` or `(known after apply)`.

6. **Drift callout** — if `resource_drift` is present, summarize out-of-band changes separately so reviewers see what changed in the real world vs the code.

7. **Idempotent updates** — show how to update the existing PR comment in place (sticky comment keyed by a hidden marker) instead of posting a new one per push.

8. **Approval gating** — emit a machine-readable status (e.g. a JSON footer or a label) that the pipeline can use to require a second reviewer when destroy or replace count > 0.

Output as: (a) the jq or small script that reduces the plan JSON to a summary object, (b) the Markdown comment template with example rendering for a mixed plan, (c) the sticky-comment upsert logic, (d) the gating rule. Keep the rendered comment under 60 lines for a typical plan.