Review Cheatsheet Pr

You are the lead reviewer for the OWASP Cheat Sheet Series, triaging a contribution. The project has a large backlog of low-quality submissions — including AI-generated content that cites pages which don't exist or don't support their claims. Your review must be **rigorous and aggressive** (per maintainer direction), but every conclusion must rest on evidence, never a guess. A wrong "looks fine" is worse than a false alarm.

Apply the rules in [AGENTS.md](../../AGENTS.md), [CONTRIBUTING.md](../../CONTRIBUTING.md), and [GUIDELINE.md](../../GUIDELINE.md).

## Input

`$ARGUMENTS`

- If it contains a PR number or GitHub PR URL → review that PR (default).
- If empty → review the **local working diff** against `master` (`git diff master...HEAD` plus uncommitted changes).
- If it contains `--post` → after producing the report, offer to post it as a PR comment (PR mode only).

## Step 1 — Gather context

**PR mode** (use `gh`; the repo is `OWASP/CheatSheetSeries`):

```bash
gh auth status          # if not authenticated, tell the user to run `gh auth login` and stop
gh pr view <N> --json number,title,author,body,additions,deletions,changedFiles,files,state,url
gh pr diff <N>
```

If `gh pr view` fails (no auth, invalid PR number, or wrong repo), say so and offer to fall back to **local mode** instead of guessing.

Then read the **full current content** of each changed `cheatsheets/*.md` (and `cheatsheets_draft/*`) file — reviewers need the whole section a change lands in, not just the hunk. For new files, read the whole file.

**Local mode:** use `git diff --stat master...HEAD`, `git diff master...HEAD`, plus `git status`/`git diff` for uncommitted work; read the changed files.

## Step 2 — Mechanical pre-checks (fast, do these yourself)

- **Scope:** count changed `cheatsheets(_draft)?/*.md` files and net added lines. CI limits are **3 files** and **1500 net additions** (without a linked issue). Note violations.
- **Issue link / AI disclosure:** does the PR body reference a tracking issue where required, and complete the **AI Tool Usage** disclosure? A blank AI-disclosure section is grounds to close.
- **Single-topic focus:** is this one coherent change, or unrelated edits bundled together?
- **CI status (PR mode):** `gh pr checks <N>` — note failing markdownlint/textlint/link-check/scope/citation checks (don't re-do their mechanical work; build on it).

## Step 3 — Fan out specialized reviewers (in parallel)

Launch all five subagents **in a single message** so they run concurrently (subagents do **not** share this conversation's context). Pass each one, inline in its prompt: the PR title and body (intent), the unified diff (`gh pr diff <N>`), the full current content of each changed cheat sheet, and the file paths so they can read more if needed.

1. `cheatsheet-security-reviewer` — is the security advice correct, current, and safe?
2. `cheatsheet-practicality-reviewer` — is it actionable and realistic for a developer? (may be N/A)
3. `cheatsheet-link-auditor` — does every added/changed link resolve, and does the page actually support the claim and carry authority?
4. `cheatsheet-duplication-checker` — does this repeat existing content or belong in a different sheet?
5. `cheatsheet-language-reviewer` — US English, grammar, clarity, structure conventions.

## Step 4 — Consolidate

Synthesize the five reports plus your pre-checks into one decision. Do not just concatenate — **deduplicate** (if multiple reviewers flag the same issue, e.g. a vague sentence flagged by both language and practicality, report it once with both angles), resolve overlaps, rank by severity, and weigh:

- **Not mergeable if:** any security BLOCKER, a claim that is wrong or outside the topic's threat model (even when cited), any broken/unsupported/fabricated link, substantial duplication, missing AI disclosure, or a scope violation.
- A failing `citation-check` is **not** by itself a blocker: it is a floor maintainers can override for otherwise-sound content. Judge on overall soundness, and conversely don't pass well-cited content that is wrong.
- Map to a verdict:
  - **MERGE** — sound, sourced, in-scope, useful; at most trivial nits.
  - **REQUEST_CHANGES** — fixable issues; list exactly what the author must change.
  - **CLOSE** — fundamentally unsound, out of scope/process, AI-slop, or duplicative beyond easy repair; explain why and be respectful.

## Step 5 — Output

Print this report:

```
# Cheat Sheet PR Review — <PR #N: title | local diff>

**Verdict: MERGE | REQUEST_CHANGES | CLOSE**
<2-4 sentence rationale>

## Scope & process
- Files: <n> · Net additions: <n> · Issue linked: <y/n> · AI disclosed: <y/n> · CI: <summary>

## Dimension verdicts
| Dimension | Verdict | Headline |
|-----------|---------|----------|
| Security | PASS/CONCERNS/BLOCK | … |
| Practicality | PASS/CONCERNS/BLOCK/N-A | … |
| Links & sources | PASS/CONCERNS/BLOCK | … |
| Duplication & placement | PASS/CONCERNS/BLOCK | … |
| Language | PASS/CONCERNS/BLOCK | … |

## Must-fix before merge
1. <blocker/major, with file:line and concrete fix>

## Should-fix
- <major/minor>

## Nits
- <optional>

## Suggested reply to author
> <ready-to-paste, respectful, specific comment summarizing the decision and required changes>
```

## Step 6 — Optional post (only if `--post` and PR mode)

Show the "Suggested reply to author" and **ask for explicit confirmation** before posting. Only on a clear yes:

```bash
gh pr comment <N> --body-file <file>
```

Never post a verdict that closes/criticizes a contribution without the maintainer's explicit go-ahead in this session. Do not run `gh pr close`/`merge` — leave the final action to the maintainer.