Single comprehensive-review workflow on @claude review trigger

.github/workflows/claude-code-review.yml

@@ -1,34 +1,91 @@
 name: Claude Code Review
 
 on:
-  pull_request_target:
-    types: [labeled]
+  issue_comment:
+    types: [created]
 
 jobs:
   claude-review:
     if: |
-      github.event.label.name == 'claude-review' &&
-      github.event.sender.login == 'dakra'
+      github.event.issue.pull_request &&
+      contains(github.event.comment.body, '@claude') &&
+      contains(github.event.comment.body, 'review') &&
+      (github.event.comment.author_association == 'OWNER' ||
+       github.event.comment.author_association == 'MEMBER' ||
+       github.event.comment.author_association == 'COLLABORATOR')
     runs-on: ubuntu-latest
     permissions:
       contents: read
       pull-requests: write
-      issues: write
       id-token: write
-
     steps:
       - name: Checkout repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@v6
         with:
-          ref: ${{ github.event.pull_request.head.sha }}
           fetch-depth: 1
-          persist-credentials: false
 
       - name: Run Claude Code Review
-        id: claude-review
         uses: anthropics/claude-code-action@v1
         with:
           claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
-          plugin_marketplaces: 'https://github.com/anthropics/claude-code.git'
-          plugins: 'code-review@claude-code-plugins'
-          prompt: '/code-review:code-review ${{ github.repository }}/pull/${{ github.event.pull_request.number }}'
+          track_progress: true
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.issue.number }}
+
+            Perform a comprehensive code review of this PR.
+
+            ## Project context
+
+            ghostel is a two-layer Emacs terminal package:
+            - `lisp/` — Emacs Lisp sources (the `ghostel` package).
+            - `src/` — Zig native module wrapping libghostty (the
+              terminal engine). Read `src/CLAUDE.md` before commenting
+              on any `.zig` file; it documents the error-handling and
+              accessor patterns the codebase requires.
+            - `extensions/<pkg>/` — independent MELPA packages that
+              depend on ghostel (currently `evil-ghostel`).
+            - `etc/terminfo/`, `etc/shell/` — bundled terminfo and
+              shell integration assets.
+
+            Elisp calls Zig functions (e.g. `ghostel--write-input`,
+            `ghostel--redraw`). Zig calls back into Elisp via a stashed
+            env pointer that is only valid during an Elisp→Zig call.
+
+            Tests are ERT-based in `test/ghostel-test.el`, split into:
+            - elisp-only (`make test`) — fast, no native module needed.
+            - native (`make test-native`) — requires the Zig build.
+            Native tests use `ghostel--debug-feed` to feed VT data
+            without a live PTY. Pre-commit convention is `make -j4 all`
+            (build + all tests + lint).
+
+            ## Rules for findings
+
+            - Verify before claiming. If you assert that a tag, version,
+              API, permission, or behavior is wrong/missing/required,
+              verify it with WebFetch, `gh api`, or by reading the
+              actual source/file. State what you checked.
+            - Calibrate. If you are under ~80% confident something is
+              wrong, raise it as QUESTION, not BUG. Tag every finding
+              as one of: BUG (verified wrong), QUESTION (unsure), or
+              NIT (style/preference).
+            - Do not recommend hardening that does not apply. If you
+              suggest a setting, name the threat it mitigates and why
+              it applies here.
+            - Do not dismiss CI failures as "pre-existing" or
+              "unrelated" without verifying against the base branch.
+            - Do not pad. Skip focus areas with nothing meaningful to
+              say. If you find more than ~5 distinct issues, report
+              only the strongest. A short correct review beats a long
+              speculative one.
+
+            ## Focus areas
+
+            Code quality, security, performance, testing, documentation.
+
+            Provide inline comments on specific lines. Use top-level
+            comments for general observations.
+
+          claude_args: |
+            --model claude-opus-4-7
+            --allowedTools "Read,Grep,Glob,WebFetch,mcp__github_inline_comment__create_inline_comment,Bash(gh pr:*),Bash(gh api:*),Bash(gh release:*)"