chore: reduce PR review bot noise

Signed-off-by: hqhq1025 <1506751656@qq.com>

Author: hqhq1025

.github/prompts/codex-pr-review.md

@@ -23,16 +23,23 @@ Open CoDesign is an open-source AI design tool — Electron desktop app that tur
 - `packages/templates/` — built-in demo prompts
 - `packages/shared/` — types, utils, zod schemas
 
-**Hard constraints and review checks:**
+**Project constraints:**
 - ≤ 30 prod dependencies
 - MIT-compatible permissive licenses only (reject GPL/AGPL/SSPL/proprietary/unclear copied assets)
 - All LLM calls via `@mariozechner/pi-ai` (no direct provider SDK imports in app code)
-- No silent fallbacks — every error must surface in UI or throw with context
-- Every UI value via `packages/ui` tokens (no hardcoded `#fff` / `16px` / fonts)
+- No silent fallbacks for user-visible failure, data loss, auth/security decisions,
+  or persisted state. Best-effort cleanup, optional discovery, and non-critical
+  listing paths may degrade quietly when the UI still presents a truthful state.
+- App chrome should use `packages/ui` tokens for shared colors, typography,
+  spacing, radii, and recurring component dimensions. Do not flag incidental
+  one-off Tailwind size utilities (for example icon sizes or compact row
+  heights) unless they duplicate an established token, hardcode colors/fonts,
+  cause visible inconsistency, or create a pattern that should be promoted to
+  a shared token.
 
-Public context: `CLAUDE.md`, `AGENTS.md` if present, `.github/PULL_REQUEST_TEMPLATE.md`, package manifests, lockfiles, changed source files, and other files committed to the public repository.
+Public context: `AGENTS.md` if present, `CLAUDE.md`, `.github/PULL_REQUEST_TEMPLATE.md`, package manifests, lockfiles, changed source files, and other files committed to the public repository. If `AGENTS.md` and `CLAUDE.md` conflict, prefer `AGENTS.md`.
 
-Internal-only context: `docs/**`, `.claude/**`, and `.Codex/**` may exist in maintainer workspaces but are not guaranteed to exist in public clones. Do not cite those files, ask contributors to read them, or base a public finding solely on them. If an internal file conflicts with public repo files, use the public file as the review source and, at most, ask a maintainer-facing question.
+Internal-only context: `docs/**`, `.claude/**`, and `.Codex/**` may exist in maintainer workspaces but are not guaranteed to exist in public clones. Do not cite those files, ask contributors to read them, or base a public finding solely on them. If a PR adds or modifies `.claude/**`, `.Codex/**`, `.env*`, or other local-agent/private config, that diff is public and should usually be flagged as unrelated/private configuration. If an internal file conflicts with public repo files, use the public file as the review source and, at most, ask a maintainer-facing question.
 
 ## PR Context (required)
 
@@ -84,10 +91,10 @@ fi
 
 1. **Load context (progressive)**: PR metadata, diff, `CLAUDE.md`, `AGENTS.md` if present, `.github/PULL_REQUEST_TEMPLATE.md`, relevant package manifests/lockfiles, then only the source files referenced by the diff.
 2. **Determine review mode**: `initial` if no prior bot review exists for an earlier commit, otherwise `follow-up after new commits`.
-3. **Review the latest PR diff in full**: correctness, security (OWASP top 10), regressions, data loss, performance, maintainability, **and adherence to hard constraints**.
-4. **Follow-up context**: when `IS_FOLLOW_UP_REVIEW=true`, use the previous bot review and compare diff for context — do not limit the review to those changes.
+3. **Review the latest PR diff in full**: correctness, security (OWASP top 10), regressions, data loss, performance, maintainability, **and adherence to project constraints**.
+4. **Follow-up context**: when `IS_FOLLOW_UP_REVIEW=true`, use the previous bot review and compare diff for context. Do not limit the review to those changes, but do not repeat an already-known optional/nit finding unless the new diff makes it worse or the previous review explicitly made it a merge blocker.
 5. **Check tests**: note missing or inadequate Vitest/Playwright coverage.
-6. **Constraint checks**: silent fallbacks, hardcoded UI values, direct SDK imports, license of new deps, install-size impact.
+6. **Constraint checks**: material silent fallbacks, material hardcoded UI values, direct SDK imports, license of new deps, install-size impact.
 7. **Freshness checks**: for dependency, runtime, or API-version claims, verify against the repository files first. If the repository files are insufficient and network is available, use public authoritative sources such as npm package metadata, GitHub releases, or official docs. Never report a version-related issue from model memory alone.
 8. **Linked issue validation**: when the PR title/body says it closes, fixes, resolves, implements, or completes an issue, fetch that issue body and recent public comments. Compare the issue's acceptance criteria, claimed scope, and follow-up comments against the actual diff and tests.
 9. **Respond** with an evidence-based review comment (no code changes).
@@ -119,14 +126,27 @@ Example finding:
   ```
 ````
 
-## Severity Calibration
+## Severity And Noise Control
 
-Treat severity as a merge decision aid, not a list of every possible improvement:
+Use severity to reflect merge risk, not personal taste:
 
-- **Blocker**: security issue, data loss, build/release breakage, direct violation of a live required check, or an issue-closing claim that is clearly false and would mislead maintainers into closing user-visible work.
-- **Major**: realistic user-facing regression, broken core workflow, wrong runtime behavior on a supported path, or missing implementation for an explicit completion claim.
-- **Minor**: localized bug, important but non-blocking test gap, misleading diagnostic, or follow-up needed for a secondary path.
-- **Nit**: wording, small maintainability, or style issues with no behavioral risk.
+- **Blocker**: exploitable security issue, likely data loss, broken required CI/build/release path, incompatible license, or a regression that makes the PR unsafe to merge.
+- **Major**: likely user-visible behavior regression, broken core workflow, incorrect persistence/runtime contract, or a broad architectural constraint violation.
+- **Minor**: real issue that should be fixed before or soon after merge, but the PR can still be evaluated as directionally sound. Missing changesets for user-visible changes usually belong here.
+- **Nit**: style, naming, small cleanup, or consistency polish. Nits must never be described as merge blockers.
+
+Do not file a finding when the only concern is:
+
+- an incidental one-off Tailwind size utility that is consistent with nearby code,
+- an optional test that would be nice but is not proportional to the risk,
+- a cosmetic ordering/formatting preference that Biome accepts,
+- an existing codebase pattern that the PR merely follows.
+
+For follow-up reviews, avoid review churn:
+
+- If an earlier optional/nit finding remains but all material issues are fixed, move it to **Residual observations** in the summary or omit it.
+- If a previous finding is resolved, mention it briefly in the summary only when it helps the maintainer understand readiness.
+- If the PR is ready to merge except for non-blocking polish, say that clearly.
 
 When a concern only appears under a self-contradictory configuration, a deliberately unsupported path, or a scope that belongs to a follow-up issue, do not label it Major. Put it in Summary as residual risk or suggest a follow-up issue instead. Do not report commit-trailer compliance findings unless a public workflow, branch protection rule, or live required check in this repository currently enforces them.
 
@@ -136,7 +156,7 @@ When a concern only appears under a self-contradictory configuration, a delibera
 - **Biome autofixes**: when the only problem is Biome formatting or a safe autofix, do not frame it as a behavioral finding; tell the contributor to run `pnpm lint:fix`, commit the result, and let CI rerun.
 - **Mode line**: summary must start with `Review mode: initial` or `Review mode: follow-up after new commits`.
 - **Evidence**: cite specific public repository files and line numbers using `path:line`.
-- **No private citations**: never cite `docs/**`, `.claude/**`, `.Codex/**`, local absolute paths, workflow runner temp paths, or any file absent from the public checkout.
+- **No private citations**: never cite maintainer-local `docs/**`, untracked `.claude/**`, untracked `.Codex/**`, local absolute paths, workflow runner temp paths, or any file absent from the public checkout. If the PR itself adds/modifies private config files, cite the public diff path and explain why it should be removed.
 - **No speculation**: if uncertain, say so; if not found, say "Not found in the public repo".
 - **No stale version claims**: when judging "latest", "unsupported", "deprecated", or "current stable", include the checked source in the reasoning. If you cannot verify it during the run, do not file a finding.
 - **Linked issue claims**: if a PR claims to close/implement an issue, verify the issue acceptance criteria against the diff and tests before accepting the claim.
@@ -147,18 +167,15 @@ When a concern only appears under a self-contradictory configuration, a delibera
 - **Fresh-head only**: before posting, re-fetch live PR head SHA; if it differs from `CURRENT_HEAD_SHA`, stop without posting a stale review.
 - **Attribution**: report only issues introduced or directly triggered by the diff.
 - **High signal**: if confidence < 80%, do not report; ask a question if needed.
-- **No praise**: report issues and risks only.
-- **Concrete fixes**: every issue must include a specific code suggestion snippet.
+- **No filler praise**: keep positive comments brief and useful. It is okay to say "No issues found" or note that prior findings were resolved.
+- **Concrete fixes**: every issue must include a specific next action. Include a code snippet only when a code snippet is the clearest fix; for changesets, docs, test coverage, or scope issues, a concrete command or prose action is fine.
 
 ## Response Format
 
 **Findings**
 
 - [Severity] Title — why it matters, evidence `path:line`
-  Suggested fix:
-  ```language
-  // minimal change snippet
-  ```
+  Suggested fix / next action: one concise prose action, command, or code snippet.
 
 **Questions** (if needed)
 - ...