Create an annotated code-review HTML page for this repository's current changes.

Arguments passed to `/annotated-review`: `{{ARGUMENTS}}`
Working directory: `{{CWD}}`
Renderer script: `{{RENDER_SCRIPT}}`
Output HTML path: `{{OUTPUT_PATH}}`
Base ref/range, if any: `{{BASE_REF}}`

## Important implementation note

Use the global annotated-review renderer. Do **not** hand-write the HTML shell, CSS, or browser components in the response. The renderer owns reusable layout/CSS/components and produces a single self-contained HTML file with inline CSS and inline JS.

Create only the final review HTML file. If you need a temporary JSON data file for the renderer, put it in `/tmp` and delete it after rendering.

## Defaults and argument handling

- If no non-HTML argument was provided, review the current working tree: staged changes, unstaged changes, and relevant untracked text files.
- If `{{BASE_REF}}` is non-empty, review that git ref/range instead of the working tree.
- The output path has already been resolved to an absolute path: `{{OUTPUT_PATH}}`.
- In your final answer, always print the absolute HTML path, not a relative path.

## Gather the changes

1. Run `git status --short` first.
2. Collect stats:
   - working tree mode: `git diff --stat`, `git diff --cached --stat`, and relevant untracked files from `git ls-files --others --exclude-standard`;
   - base ref/range mode: `git diff {{BASE_REF}} --stat`.
3. Inspect the full relevant diff:
   - working tree mode: combine `git diff --cached` and `git diff`;
   - base ref/range mode: `git diff {{BASE_REF}}`;
   - untracked files: inspect only relevant text/source files, avoiding secrets, generated output, dependencies, build artifacts, screenshots, and large binaries.
4. Read changed files when the diff alone is not enough to understand intent.

## Review goals

Focus on making the changes easy to digest:

- Explain what changed in plain language.
- Separate high-risk files from low-risk files.
- Add inline review comments only where useful.
- Prefer actionable findings over generic advice.
- Do not invent problems. If a file looks safe, mark it as safe and summarize why.
- Include positive notes when a change is clear, well-contained, or improves maintainability.

Use these comment labels exactly when needed:

- `Blocking` — likely bug, data loss, security issue, broken deploy, or failed requirement.
- `Important` — should fix soon but not necessarily blocking.
- `Question` — needs user/product clarification.
- `Nit` — small cleanup/readability/lint concern.
- `Good` — a short callout for especially helpful design or cleanup.

Use these file risk levels exactly:

- `needs attention` for files with Blocking/Important concerns.
- `worth a look` for non-blocking comments or higher-complexity changes.
- `safe` for low-risk files with no issues found.

## Renderer data contract

After review, write a JSON data file that matches this shape. Do **not** include raw diffs; the renderer collects and escapes tracked-file diffs from git. For untracked files, the renderer only collects content for paths you explicitly list in `files`, and it still rejects symlinks, likely secrets, large files, generated output, dependencies, and binaries.

```json
{
  "title": "Annotated review",
  "subtitle": "Optional one-line context",
  "whatChanged": ["Plain-language bullet"],
  "files": [
    {
      "path": "src/example.ts",
      "risk": "worth a look",
      "summary": "Concrete file-level summary.",
      "comments": [
        {
          "label": "Good",
          "anchor": "hunk @@ -10,7 +10,9 @@ or line 42",
          "text": "Specific review note."
        }
      ]
    }
  ],
  "nextSteps": ["Checklist item"],
  "notes": ["Optional note about omitted repetitive/generated hunks"]
}
```

Every changed or relevant untracked file should appear in `files`. The renderer will add safe placeholders for tracked changed files you omit, but explicit summaries are better. Untracked files omitted from `files` are not rendered.

## Render command

Use a temp JSON file and run:

```bash
node {{RENDER_SCRIPT_QUOTED}} --cwd {{CWD_QUOTED}} --data /tmp/annotated-review-data.json --output {{OUTPUT_PATH_QUOTED}} {{BASE_FLAG}}
```

Then delete the temp JSON. The renderer prints the absolute output path and writes the self-contained HTML file.

## Final response

After writing the file, reply with:

1. The absolute review HTML path.
2. A short summary of what you did.
3. How to use it next time: `/annotated-review` and, if needed, `/annotated-review <base-ref> <output.html>`.