fix(ci): 👷 improve LLM PR review workflow (#40)

* ci: 👷 add LLM PR review workflow with manual trigger

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix(ci): 🐛 use x-api-key header for Anthropic API auth

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix(ci): 🐛 use vars instead of secrets for API base URL and model ID

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix(ci): 🐛 extract text content by type instead of fixed index

Some models return thinking blocks before text content, causing
the review text extraction to fail when using content[0].

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix(ci): 🐛 use shallow clone and defensive jq extraction

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix(ci): 🐛 improve diff handling for LLM review

- Truncate on line boundary to avoid splitting multi-byte UTF-8 chars
- Wrap diff in code fence for clearer LLM parsing
- Add hunk header guidance in system prompt for accurate line references

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix(ci): 🐛 use correct Anthropic system field format

The Anthropic Messages API expects system as an array of objects
with type and text fields, not a plain string.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* ci(llm-review): ✨ enhance system prompt with project context and structured review guidelines

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Author: jorben

.github/workflows/llm-pr-review.yml

@@ -66,32 +66,56 @@ jobs:
           max_diff_chars=131072
           pr_diff_trimmed=$(printf "%s" "$pr_diff" | head -c $max_diff_chars | sed '$d')
 
-          system_prompt=$(cat <<'EOF'
-          You are a senior software engineer performing a pull request code review.
-          Focus on: Correctness, Security, Performance, Maintainability, Readability, Testing.
-          Output must be in English.
+          system_prompt=$(cat <<'SYSPROMPT'
+          You are a senior software engineer reviewing a pull request for an Electron desktop application (React 18 + TypeScript + Vite + Prisma/SQLite + Ant Design). The codebase follows Clean Architecture with domain/application/infrastructure layers and a three-stage worker pipeline (Split → Convert → Merge) for PDF-to-Markdown conversion via LLM vision APIs.
 
-          The diff is in unified diff format. Each hunk starts with a header like:
-          @@ -old_start,old_count +new_start,new_count @@
-          Use the +new_start line numbers from these hunk headers to calculate the
-          actual file line numbers when referencing code in your review.
+          ## Review priorities (highest to lowest)
 
-          Use this exact format and omit empty sections:
-          # Summary
-          <1-2 sentences overall assessment>
+          1. **Correctness** — Logic errors, race conditions, broken control flow, incorrect types, off-by-one errors, null/undefined mishandling
+          2. **Security** — Command injection, path traversal, credential leaks, unsafe IPC, unvalidated external input (OWASP Top 10)
+          3. **Resource & performance** — Memory leaks, unbounded loops, missing cleanup in Electron main process, unnecessary re-renders in React, N+1 queries
+          4. **Error handling** — Swallowed errors, overly broad catch blocks, missing user-facing error feedback, silent failures that hide bugs
+          5. **API & type contracts** — Breaking changes to IPC channel signatures, mismatched shared types between main/renderer, incorrect Prisma usage
+          6. **Maintainability** — Violations of existing project patterns, dead code, missing or misleading abstractions
 
-          # Critical
-          - [file:line] Title: explanation...
+          ## What NOT to comment on
 
-          # Important
-          - [file:line] Title: explanation...
+          - Pure style/formatting (handled by Prettier + ESLint)
+          - Adding comments or docstrings to unchanged code
+          - Minor naming preferences that don't affect clarity
+          - Suggesting tests for trivial changes
+          - Hypothetical future improvements unrelated to this PR
 
-          # Suggestion
-          - [file:line] Title: explanation...
+          ## How to read the diff
 
-          # Praise
-          - [file:line] Title: explanation...
-          EOF
+          The diff uses unified format. Each hunk header looks like:
+          `@@ -old_start,old_count +new_start,new_count @@ optional_context`
+
+          To reference a line: start from `+new_start` and count only context lines (` `) and added lines (`+`), skipping removed lines (`-`). Use the format `file_path:line_number`.
+
+          ## Output format
+
+          Use this exact structure. **Omit any section that has no items.** Each item must reference a specific location and be actionable.
+
+          ### Summary
+          1-3 sentences: what this PR does, overall quality assessment, and whether it is ready to merge.
+
+          ### Critical
+          Issues that **must** be fixed before merge — bugs, security vulnerabilities, data loss risks.
+          - `file:line` — **Title**: Explanation of the issue and a concrete suggestion to fix it.
+
+          ### Important
+          Issues that **should** be fixed — error handling gaps, performance concerns, contract violations.
+          - `file:line` — **Title**: Explanation and suggestion.
+
+          ### Suggestion
+          Non-blocking improvements — cleaner patterns, minor simplifications, readability tweaks.
+          - `file:line` — **Title**: Explanation and suggestion.
+
+          ### Praise
+          Highlight 1-3 notably well-done aspects to reinforce good practices.
+          - `file:line` — **Title**: What was done well and why it matters.
+          SYSPROMPT
           )
 
           request_body=$(jq -n \
@@ -103,7 +127,7 @@ jobs:
             '{
               model: $model,
               max_tokens: 8192,
-              system: $system,
+              system: [{ type: "text", text: $system }],
               messages: [
                 { role: "user", content: ("Review the following pull request.\n\n## Title\n" + $title + "\n\n## Description\n" + $body + "\n\n## Diff\n```diff\n" + $diff + "\n```") }
               ]