code-review-digest-writer

What this skill does

# Code Review Digest Writer Skill

## When to Use This Skill

- You want a **weekly (or custom window) code-review digest** for the current
  repository or project, based on PR review comments.
- You have a **start date** and **end date** and want a markdown newsletter
  summarizing what was taught in PR review feedback in that period.
- You want to highlight **themes, repeated issues, and concrete best practices**
  rather than just listing PRs.

If the user does not provide both a start and end date, ask them to specify:
`YYYY-MM-DD` → `YYYY-MM-DD` before proceeding.

## Example Prompts

- “Generate a code review digest for this repo for 2025-02-01 → 2025-02-14.”
- “Create a weekly PR review digest for 2025-03-10 → 2025-03-17, using any existing digests as historical context.”
- “From 2025-04-01 to 2025-04-30, summarize what reviewers focused on in `owner/service-repo` and highlight repeated issues.”
- “Write a newsletter-style code review digest for this project for 2025-05-15 → 2025-05-29, tagging themes as [NEW] or [REPEAT].”

## Scope & Repositories

- Target repo: whichever project you want a digest for (typically the repo you
  currently have open in Claude Code).
- Ideally the repo contains `docs/review-digests/AGENTS.md` with
  project-specific digest guidelines. If not, fall back to the generic structure
  described in this Skill and any existing digest files.
- This Skill **must only modify docs** under:
  - `docs/review-digests/YYYY-MM-DD.md`
  where the date is the **end date** of the reporting window.
- Do **not** modify application code, tests, or configs in the target repo while
  this Skill is active. All changes should be within `docs/review-digests/`.
- If `docs/review-digests/` does not exist yet, create the directory before
  writing the digest file, so future digests can be added and past ones read.

## Required Local Tools & Assumptions

When using `Bash`, assume:

- `gh` (GitHub CLI) is installed and authenticated for the target repository
  (or for a default GitHub identity that can see it).
- Current working directory is the target repo root (or pass `--repo owner/name`
  explicitly to `gh` commands, if needed).

If `gh` is not available, gracefully fall back to:

- Summarizing based on locally available PR notes or docs, and
- Clearly stating in the digest that it was generated with partial data.

## High-Level Workflow

When asked to generate or update a digest, follow this workflow:

1. **Confirm time window**
   - Ensure you have `start_date` and `end_date` (inclusive).
   - Confirm with the user if there is any ambiguity.

2. **Load local digest guidelines**
   - If it exists, open `docs/review-digests/AGENTS.md` and read it carefully.
   - When present, treat that file as the **source of truth** for:
     - What the digest is.
     - Where it should be written.
     - Required structure and link style.
     - How to detect and label repeated issues.
   - If it does not exist, follow the layout described later in this Skill and
     use any existing digest files in `docs/review-digests/` as a reference.

3. **Inspect existing digests**
   - Ensure the `docs/review-digests/` directory exists:
     - If it does not, create it; in that case there will be no past digests yet.
   - Use `Glob` or `Bash` to list `docs/review-digests/*.md`.
   - Load at least the **last 3–4 digests** (if present).
   - Extract their **themes and repeated issues** (e.g., fixture reuse,
     blind-index invariants, Query() regression patterns, etc.).
   - You will use these to detect when issues are recurring.

4. **Fetch PR and review data for the window**
   - Use `Bash` with `gh` to query PRs whose:
     - `createdAt` is between `[start_date, end_date]`, OR
     - `closedAt` is between `[start_date, end_date]`.
   - Deduplicate PR numbers.
   - For each selected PR:
     - Fetch **top-level comments** (PR discussion).
     - Fetch **review-thread comments with code context** (via GraphQL).
   - Prefer comments from:
     - Human reviewers (`__typename == "User"`).
     - AI reviewers that contain substantial review content
       (e.g., Claude, Copilot PR reviewer).
   - Exclude noisy infrastructure/bot comments with no review content
     (e.g., `github-actions`, log-only bots, CI status updates).

5. **Cluster feedback into themes**
   - Read comments and diff context enough to understand:
     - What behavior or pattern was being discussed.
     - What best practice or correction was suggested.
   - Group comments across PRs into **themes**, such as:
     - Logging, Sentry, and performance instrumentation.
     - Tests, fixtures, and code structure.
     - Security, access control, and PII handling.
     - Domain-specific design and invariants for this repository.
     - Migrations & tooling.
     - Process and meta-patterns in reviews.

6. **Detect repeated issues**
   - For each current theme, compare it conceptually to themes you extracted
     from previous digests (step 3).
   - If the same pattern appears again (e.g., “use TypedDict instead of
     `dict[str, Any]` in payloads”, “avoid Django Ninja `Query()` constants”,
     “reuse shared fixtures instead of copy-paste”), treat it as a **repeated issue**.
   - Use labels:
     - `[NEW]` for themes that appear for the first time.
     - `[REPEAT]` for themes that have appeared in previous digests.

7. **Draft the digest file**
   - Target path: `docs/review-digests/END_DATE.md`
     - Example: period `2025-11-13` → `2025-11-27` → `docs/review-digests/2025-11-27.md`.
   - Follow the **layout described in `docs/review-digests/AGENTS.md`** and the
     most recent digest, including:
     - Title with repo and period.
     - **Overview** section with 3–6 bullets summarizing main themes.
     - Thematic sections (numbered) that group related feedback.
     - A closing section (e.g., “How to Use This Digest”).
   - Within each section:
     - Explain the practice in **plain language**.
     - Include 1–3 concrete, generalized examples.
     - Call out whether this is `[NEW]` or `[REPEAT]`.
     - Emphasize the “why” (business impact, correctness, safety, DX).

8. **Linking to PRs and comments**
   - In the body of the digest, use **reference-style links** only:
     - `[#2519 – Fix Teams Start Survey race condition][pr-2519]`
     - `Key comment: [Fixture reuse recommendation][c-2519-3]`
   - At the **bottom of the file**, define every link once:
     - `pr-<number>` for PRs.
     - `c-<number>-<n>` for specific review comments.
     - `ic-<number>-<n>` for issue comments, if needed.
   - Reuse identifiers consistently when the same comment is referenced in
     multiple sections.

9. **Respect tone and intent**
   - The digest is a **newsletter**, not a blame report.
   - Highlight:
     - What the team is learning.
     - Where we’re improving.
     - Where patterns are still repeating and need attention.
   - Make guidance actionable (e.g., “When adding a new CSV mapping endpoint,
     always run through the project’s PII and security checklist docs.”).

10. **Save and review**
   - Use `Edit` to create or update the digest file for `END_DATE`.
   - Re-open the file after writing to sanity-check:
     - Structure matches the prior digests.
     - Links resolve correctly and have definitions at the bottom.
     - `[NEW]` / `[REPEAT]` tags are applied consistently.
     - No accidental code changes occurred in the repo.

## Output Expectations

When this Skill is active and asked to generate a digest, your final output
should be:

- A **single markdown file** under `docs/review-digests/YYYY-MM-DD.md`.
- A short natural-language summary back to the user describing:
  - The period covered.
  - The main themes identified.
  - How many themes were `[REPEAT]` vs `[NEW]`.

If you were unable to access GitHub or some PRs, clearly note in the digest and
in your summary which data sources were missing and how that might limit the
digest.

## Severity / Emphasis Tags

Instead of issue severities,