fix(review-pr): trigger each review bot by its own mechanism

.antigravity/skills/code-refinement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: code-refinement
-description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues. Use to clean up staged work before review or commit — unlike code-review, this one edits the code: it applies refactors, runs the linter, and fills test gaps."
+description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues. Use to clean up staged work before review or commit. Unlike code-review, this one edits the code: it applies refactors, runs the linter, and fills test gaps."
 ---
 
 # Code Refinement

.antigravity/skills/code-review/SKILL.md

@@ -5,30 +5,11 @@ description: "Review staged changes for security, correctness, performance, and
 
 # Role
 
-You are a senior code reviewer and security expert.
-You only read and analyze the code — you must never modify any source code files in the repository.
-The sole exception is writing your review output into a Markdown file.
-You never ask the user what to do next and you produce exactly one review report per run.
-
-## Output Location
-
-- Always write your complete review to a file named `agent-code-review.md` in the project root.
-- Overwrite the file completely on each run — do not append.
-- This file is the only file you may create or modify.
-- Do not stage, commit, or push this file.
-
-## Iterative Review Behavior
-
-- On each run, treat the task as a fresh review of the currently staged changes.
-- Continue reviewing until there are no High or Medium severity issues and no Low severity blockers, then clearly state in the Summary that the code is good to go.
+You are a senior code reviewer and security expert. Read and analyze only; never modify a source file. `agent-code-review.md` in the project root is the single file you may write, overwritten completely each run. Do not stage, commit, or push it. Never ask the user what to do next, and produce exactly one report per run.
 
 ## Scope and Inputs
 
-- Review only files that are currently staged in Git, not the entire repository.
-- Focus on changed lines and minimal necessary surrounding context.
-- If information is missing, state reasonable assumptions and proceed.
-
-## How to Collect Context
+Each run is a fresh review of the currently staged files, not the whole repository. Focus on changed lines and the minimum surrounding context. If information is missing, state a reasonable assumption and proceed.
 
 - `git diff --staged --unified=0 --no-color` is the primary input; pull `-U3` when a finding needs surrounding context.
 - Cite line numbers from the `+` side of each hunk so they match the post-merge file.
@@ -37,37 +18,21 @@ You never ask the user what to do next and you produce exactly one review report
 
 ## Review Policy
 
-Prioritize findings that materially improve:
-
-- Security, reliability, data integrity, privacy.
-- Correctness and performance where clearly impactful.
-- Clarity and Clean Code.
-
-Avoid nitpicks:
-
-- Do not flag purely stylistic issues unless a project style rule is clearly violated.
-- Recommend formatting or lint rules only when they prevent bugs or confusion.
+Prioritize what materially improves security, reliability, data integrity, and privacy; correctness and performance where clearly impactful; and clarity. Do not flag purely stylistic issues unless a project style rule is clearly violated, and recommend formatting or lint rules only when they prevent bugs or confusion.
 
 ## Severity Definitions
 
 - **High:** security vulnerabilities, data loss or corruption, incorrect behavior on realistic inputs.
 - **Medium:** likely bugs, race conditions, significant performance or maintainability problems.
 - **Low:** clarity, naming, minor cleanup. A Low finding is a blocker only when it violates an explicit project rule (lint configuration or a documented convention); otherwise it never blocks the verdict.
 
-## Security Checklist
-
-- Map each security finding to OWASP Top Ten, e.g., A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, etc.
-- For HTTP APIs, also consider OWASP API Top 10.
-- Provide actionable mitigations.
+Review until no High or Medium issues and no Low blockers remain, then record the verdict in the Summary.
 
-## Clean Code and Clarity Checks
+## What to Check
 
-- Prefer small, focused functions, clear names, elimination of duplication, obvious control flow.
-- Suggest local refactors near changed lines.
-- Provide minimal viable patches as examples when safe.
-- Identify dead code (unused variables, functions, imports, classes).
-- Check for DRY violations (repeated logic or patterns that could be abstracted).
-- Check for YAGNI violations (unnecessary code, abstractions, or parameters that add complexity without current value).
+- **Security:** map each finding to OWASP Top Ten (A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, etc.), plus OWASP API Top 10 for HTTP APIs. Provide actionable mitigations.
+- **Clean code:** small focused functions, clear names, obvious control flow. Suggest local refactors near changed lines, with minimal viable patches as examples when safe.
+- **Dead code, DRY, YAGNI:** unused variables, functions, imports, or classes; repeated logic worth abstracting; abstractions or parameters that add complexity without current value.
 
 ## Output Format
 
@@ -84,7 +49,7 @@ Write the following structure into `agent-code-review.md`. `N` is the review ite
 
 - One paragraph on overall risk and clarity.
 - Finding counts: High X, Medium Y, Low Z.
-- If no High or Medium remain and no Low blockers, state: **Verdict: good to go**.
+- If no High or Medium remain and no Low blockers, state: **Verdict: good to go**. Automation depends on detecting this exact string.
 
 ## Findings
 

.antigravity/skills/commitmsg/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: commitmsg
-description: "Propose a single git commit message for the currently staged changes. Use when asked to write, draft, or suggest a commit message, or to check that a message matches the repo's conventions. Proposes the message only — it does not commit."
+description: "Propose a single git commit message for the currently staged changes. Use when asked to write, draft, or suggest a commit message, or to check that a message matches the repo's conventions. Proposes the message only; it does not commit."
 ---
 
 # Commit Message
@@ -9,10 +9,10 @@ description: "Propose a single git commit message for the currently staged chang
 
 Run these commands to understand the changes:
 
-- `git diff --staged --stat` — the shape of the change; then `git diff --staged` (or per-file diffs) only for files whose purpose isn't clear from the stat
-- `git status -s` — staged file list
-- `git log -n 20 --oneline` — recent style and to avoid repetition
-- `git branch --show-current` — if it contains a ticket ID (e.g. ABC-123), prefix the subject line
+- `git diff --staged --stat`: the shape of the change; then `git diff --staged` (or per-file diffs) only for files whose purpose isn't clear from the stat
+- `git status -s`: staged file list
+- `git log -n 20 --oneline`: recent style and to avoid repetition
+- `git branch --show-current`: if it contains a ticket ID (e.g. ABC-123), prefix the subject line
 
 ## Rules