revert: restore review workflow and guidelines to pre-caveman state

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

@@ -16,12 +16,6 @@ on:
           REPO: ${{ github.repository }}
           PR NUMBER: ${{ github.event.pull_request.number }}
 
-          ## Reasoning mode (internal only — do not echo this in output)
-
-          Think terse. Find bug, risk, pattern violation. Skip trivial. No filler in reasoning.
-          Check: null paths, auth gaps, bad error handling, perf on critical path, guideline violations.
-          Skip: lock files, minified files, generated files, style nitpicks not in guidelines.
-
           ## Instructions
 
           1. **Read Project Guidelines First**
@@ -30,43 +24,41 @@ on:
              Prioritize these guidelines over generic advice.
 
           2. **Understand PR Scope**
-             Read the PR title and description to understand intent.
-             Only review changes within stated scope.
-             Do not suggest refactoring or improvements outside the PR's purpose.
+             - Read the PR title and description to understand the intent
+             - ONLY review changes within the stated scope
+             - Do NOT suggest refactoring or improvements outside the PR's purpose
+             - If you see issues that should be separate PRs, note them briefly at the end
 
           3. **Review Output Format - IMPORTANT**
-             Create ONE single comment with all findings. Do NOT create multiple inline comments.
+             Create ONE single comment with your complete review using this structure:
+
+             ## Code Review Summary
+
+             ### Critical Issues (if any)
+             - **[filename:line]** Description of issue
 
-             **Format per finding:**
-             `<file>:L<line>: [bug|risk|nit|q]: <what is wrong>. <how to fix>.`
+             ### Suggestions
+             - **[filename:line]** Suggestion
 
-             **Severity:**
-             - `bug:` — broken behavior, will cause incident
-             - `risk:` — works but fragile (race condition, missing null check, swallowed error)
-             - `nit:` — style or naming, author can ignore
-             - `q:` — genuine question, not a suggestion
+             ### Out of Scope (brief notes only)
+             - Items that should be addressed in separate PRs
 
-             **Writing style (caveman-light — readable but no fluff):**
-             - Drop: "I noticed that", "you might want to", "consider", "perhaps", "just", pleasantries
-             - Keep: exact line numbers, exact symbol names in backticks, concrete fix, the *why* if not obvious
-             - Fragments and direct language are fine. Do not restate what the line already does.
+             ### What Looks Good
+             - Brief positive notes
 
-             **Exception — write a full paragraph for:**
-             - Security findings (CVE-class bugs) — needs full explanation and reference
-             - Architectural disagreements — needs rationale, not a one-liner
-             Resume terse style after the exception.
+             Do NOT create multiple inline comments. Put everything in ONE comment.
 
           4. **Focus Areas** (priority order)
              - Security vulnerabilities
              - Bugs and logic errors
              - Performance issues on critical paths
-             - Guideline violations
+             - Maintainability concerns
 
           5. **Skip These**
              - Lock files (package-lock.json, yarn.lock, etc.)
              - Minified files (*.min.js, *.min.css)
              - Generated files
-             - Stylistic nitpicks not mentioned in project guidelines
+             - Stylistic nitpicks (unless they violate project guidelines)
       use_sticky_comment:
         description: 'Use sticky comments to reuse the same comment on subsequent pushes'
         required: false

automated-code-review/templates/review-guidelines.md

@@ -1,24 +1,28 @@
 # Code Review Guidelines
 
-> **Note:** Claude reads all `.md` files in `docs/code-review/` before reviewing PRs. Keep guidelines short and direct — Claude reads this every run. Split into multiple files if needed (e.g. `security.md`, `api.md`).
+> **Note:** Claude reads all `.md` files in `docs/code-review/` before reviewing PRs. You can split guidelines into multiple files (e.g., `security.md`, `style.md`, `api.md`).
+
+These guidelines are used by Claude to align feedback with project expectations.
 
 ## Focus areas
 
-- Auth gaps and PII handling
-- Null paths and missing error handling
-- Performance on critical user flows
-- DB query efficiency
+- Readability and maintainability
+- Avoiding unnecessary complexity
+- Performance impact on critical user flows
+- Database query efficiency
+- Security implications (auth, payments, PII)
 
-## Rules
+## Review tone
 
-- Flag bugs and risks. Skip stylistic nitpicks unless they affect clarity or safety.
-- Do not suggest changes outside the PR's stated scope.
+- Be constructive
+- Prefer suggestions over rewrites
+- Call out risks clearly
+- Avoid stylistic nitpicking unless it affects clarity or safety
 
-## Project-specific rules
+## Project-specific rules (customize these)
 
-<!-- Add project rules below. Keep each rule one line. Examples:
-- All API endpoints must have auth middleware
-- No `any` types in TypeScript
-- DB migrations must be reversible
-- New user-facing features require a feature flag
--->
+<!-- Add your project-specific rules below. Examples: -->
+<!-- - All API endpoints must have authentication middleware -->
+<!-- - Use TypeScript strict mode - no `any` types -->
+<!-- - Database migrations must be reversible -->
+<!-- - Feature flags required for new user-facing features -->