From 83078d63a2ca07eb7c11e82e83f1f66b31dda5c0 Mon Sep 17 00:00:00 2001 From: Anurag Kumawat Date: Fri, 17 Apr 2026 12:52:34 +0530 Subject: [PATCH] revert: restore review workflow and guidelines to pre-caveman state Reverts changes from PR #18 and PR #19 that applied caveman-style formatting to the code review workflow prompt and guidelines template. Co-Authored-By: Claude Sonnet 4.6 --- .github/workflows/claude-code-review.yml | 46 ++++++++----------- .../templates/review-guidelines.md | 34 ++++++++------ 2 files changed, 38 insertions(+), 42 deletions(-) diff --git a/.github/workflows/claude-code-review.yml b/.github/workflows/claude-code-review.yml index 578baf6..16cfd57 100644 --- a/.github/workflows/claude-code-review.yml +++ b/.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:** - `:L: [bug|risk|nit|q]: . .` + ### 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 diff --git a/automated-code-review/templates/review-guidelines.md b/automated-code-review/templates/review-guidelines.md index f81ff9f..1ab6c3e 100644 --- a/automated-code-review/templates/review-guidelines.md +++ b/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) - + + + + +