chore: add pre-push review gates to CLAUDE.md#25
Closed
michaelmcnees wants to merge 4 commits into
Closed
Conversation
Require Technical Writer, Product Owner, Legal Compliance, and Reality Checker reviews before pushing any PR to GitHub. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughIntroduces a comprehensive Claude agent framework for code reviews by establishing four specialized reviewer roles (legal compliance, technical writer, reality checker, product manager), adding pre-push review gates in project documentation, and configuring permitted shell commands via settings and gitignore updates. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
- Add 4 review agent definitions (.claude/agents/): technical-writer, product-owner, legal-compliance, reality-checker - Add shared project settings (.claude/settings.json) with common permissions - Update .gitignore to commit .claude/settings.json and .claude/agents/ while keeping settings.local.json and worktrees ignored Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@CLAUDE.md`:
- Around line 81-90: The "Pre-Push Review Gates" section lacks an enforcement
and integration plan; update that section (the "Pre-Push Review Gates" heading)
to specify who performs each gate, how they are enforced, and where evidence is
recorded by: adding an "Implementation" subsection that mandates either (a) a
PR-template checklist the PR author fills (listing Technical Writer, Product
Owner, Legal Compliance, Reality Checker) and requires at least one named
reviewer for each gate, or (b) a GitHub Actions workflow that runs automated
AI-assisted checks and fails the merge if any gate fails; also specify that
completion evidence must be recorded in the PR description (checklist + reviewer
names or action run IDs) so enforcement is auditable.
- Around line 83-90: Replace the absolute "Do not skip them even for small
changes" mandate with a risk-based review policy: add a short preface after the
numbered reviewer list that defines three risk tiers (High, Medium, Low) and
maps each tier to required reviewers (e.g., High = all four reviewers; Medium =
Technical Writer + Reality Checker with Product Owner/Legal as needed; Low =
quick self-review with documented notes). Update the numbered list item or add a
new paragraph referencing the existing reviewer roles and include a one-line
guideline for how to assess risk and when to escalate to full review.
- Line 88: Update the "Reality Checker" bullet to soften the adversarial tone:
locate the heading "Reality Checker" and replace the sentence "Default to 'needs
work' — require overwhelming evidence before approving." with a balanced
phrasing that preserves rigor but permits straightforward approvals when
adequate evidence exists (for example: "Default to a thorough review: require
sufficient evidence (passing tests, covered edge cases, clear reasoning) before
approving, but allow approval when the change clearly meets those criteria").
Ensure the rest of the bullet still calls out missing tests or unhandled edge
cases as blockers.
- Line 83: The sentence "Before pushing any PR to GitHub, run the work through
these review agents (in parallel):" is ambiguous; update it to explicitly state
when and what should be reviewed and clarify "review agents". Replace the
sentence with one clear option (choose the correct intent) such as "Before
creating a PR on GitHub, run the work through these review agents (in
parallel):" or "Before merging any PR on GitHub, run the work through these
review agents (in parallel):" or "Before pushing commits to a PR branch on
GitHub, run the work through these review agents (in parallel):", and add a
short parenthetical or appended clause defining "review agents" (e.g.,
"(automated AI checks and human reviewers)" or "(automated tools/AI agents and
human reviewers)") so readers know whether these are automated checks, humans,
or both.
Comment on lines
+81
to
+90
| ## Pre-Push Review Gates | ||
|
|
||
| Before pushing any PR to GitHub, run the work through these review agents (in parallel): | ||
|
|
||
| 1. **Technical Writer** — Review all changed docs, comments, CLI output, and error messages for clarity, accuracy, and consistency with existing documentation tone. | ||
| 2. **Product Owner** — Verify the changes align with the project goals, V1 phasing priorities, and architecture principles listed above. Flag scope creep or work that doesn't serve the current phase. | ||
| 3. **Legal Compliance Checker** — Check for license compliance (dependencies, attribution), security concerns (credential handling, injection risks), and anything that conflicts with the BSL/SSPL-style license. | ||
| 4. **Reality Checker** — Challenge claims of completeness, correctness, and production readiness. Default to "needs work" — require overwhelming evidence before approving. If tests aren't shown passing, it's not done. If edge cases aren't covered, it's not ready. | ||
|
|
||
| These reviews catch misalignment early. Do not skip them even for small changes — small PRs are where assumptions slip through unchecked. |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Specify the enforcement mechanism and integration with GitHub workflow.
The section defines review requirements but doesn't specify how they should be enforced or integrated into the development workflow. This creates ambiguity about:
- Who performs these reviews? (PR author as a checklist? Other team members? Automated tools?)
- How are they enforced? (Honor system? GitHub Actions? Required reviewers? PR template checklist?)
- Where is evidence recorded? (PR description? Review comments? External tracking?)
Without an implementation mechanism, these gates may be inconsistently applied or gradually ignored.
💡 Suggested additions to clarify implementation
Consider adding a subsection that specifies the implementation approach:
### Implementation
These reviews should be conducted by the PR author using AI-assisted tooling before creating the PR. Document completion in the PR description using this checklist:
- [ ] Technical Writer review: All docs, CLI output, and error messages reviewed for clarity
- [ ] Product Owner review: Changes align with V1 phasing and architecture principles
- [ ] Legal Compliance review: License compliance and security concerns checked
- [ ] Reality Checker review: Edge cases covered, tests passing, evidence providedOr, if using automated tooling:
### Implementation
These reviews are enforced via GitHub Actions that run AI-powered analysis on each PR. The workflow must pass all four checks before merging is allowed.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CLAUDE.md` around lines 81 - 90, The "Pre-Push Review Gates" section lacks an
enforcement and integration plan; update that section (the "Pre-Push Review
Gates" heading) to specify who performs each gate, how they are enforced, and
where evidence is recorded by: adding an "Implementation" subsection that
mandates either (a) a PR-template checklist the PR author fills (listing
Technical Writer, Product Owner, Legal Compliance, Reality Checker) and requires
at least one named reviewer for each gate, or (b) a GitHub Actions workflow that
runs automated AI-assisted checks and fails the merge if any gate fails; also
specify that completion evidence must be recorded in the PR description
(checklist + reviewer names or action run IDs) so enforcement is auditable.
Comment on lines
+83
to
+90
| Before pushing any PR to GitHub, run the work through these review agents (in parallel): | ||
|
|
||
| 1. **Technical Writer** — Review all changed docs, comments, CLI output, and error messages for clarity, accuracy, and consistency with existing documentation tone. | ||
| 2. **Product Owner** — Verify the changes align with the project goals, V1 phasing priorities, and architecture principles listed above. Flag scope creep or work that doesn't serve the current phase. | ||
| 3. **Legal Compliance Checker** — Check for license compliance (dependencies, attribution), security concerns (credential handling, injection risks), and anything that conflicts with the BSL/SSPL-style license. | ||
| 4. **Reality Checker** — Challenge claims of completeness, correctness, and production readiness. Default to "needs work" — require overwhelming evidence before approving. If tests aren't shown passing, it's not done. If edge cases aren't covered, it's not ready. | ||
|
|
||
| These reviews catch misalignment early. Do not skip them even for small changes — small PRs are where assumptions slip through unchecked. |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider scalability and practicality for small changes.
Requiring four separate reviews for every change—including small documentation fixes, typos, or minor refactors—may be impractical for small teams or solo maintainers. The explicit prohibition against skipping reviews "even for small changes" could create unnecessary overhead.
Consider introducing a pragmatic risk-based approach where the depth of review scales with the impact and risk of the change.
🎯 Suggested risk-based approach
Before pushing any PR to GitHub, assess the risk level and apply appropriate review depth:
**High-risk changes** (new features, security-sensitive code, API changes, database migrations):
- All four review perspectives required with documented evidence
**Medium-risk changes** (bug fixes, refactors, non-trivial documentation):
- Technical Writer + Reality Checker required
- Product Owner + Legal Compliance as needed
**Low-risk changes** (typo fixes, comment updates, minor doc clarifications):
- Quick self-review covering all four perspectives
- Document any concerns in PR description
These reviews catch misalignment early. When in doubt, err on the side of more thorough review.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CLAUDE.md` around lines 83 - 90, Replace the absolute "Do not skip them even
for small changes" mandate with a risk-based review policy: add a short preface
after the numbered reviewer list that defines three risk tiers (High, Medium,
Low) and maps each tier to required reviewers (e.g., High = all four reviewers;
Medium = Technical Writer + Reality Checker with Product Owner/Legal as needed;
Low = quick self-review with documented notes). Update the numbered list item or
add a new paragraph referencing the existing reviewer roles and include a
one-line guideline for how to assess risk and when to escalate to full review.
|
|
||
| ## Pre-Push Review Gates | ||
|
|
||
| Before pushing any PR to GitHub, run the work through these review agents (in parallel): |
Contributor
There was a problem hiding this comment.
Clarify "before pushing any PR to GitHub."
The phrase "before pushing any PR to GitHub" is ambiguous. Pull requests are created on GitHub, so they cannot be reviewed before being pushed there. Consider rephrasing to one of:
- "Before creating a PR on GitHub..." (if reviews should happen pre-PR)
- "Before merging any PR..." (if reviews are part of the PR process)
- "Before pushing commits to a PR branch..." (if reviews happen before pushing code)
Additionally, the term "review agents" is ambiguous—it's unclear whether these are human roles, AI-powered automated checks, checklists for the PR author, or something else.
✏️ Proposed clarification
-Before pushing any PR to GitHub, run the work through these review agents (in parallel):
+Before merging any PR, ensure the changes have been reviewed from these perspectives (can be done in parallel):Or if the intent is AI/automated agents:
-Before pushing any PR to GitHub, run the work through these review agents (in parallel):
+Before creating a PR, run the changes through these AI review agents in parallel:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CLAUDE.md` at line 83, The sentence "Before pushing any PR to GitHub, run the
work through these review agents (in parallel):" is ambiguous; update it to
explicitly state when and what should be reviewed and clarify "review agents".
Replace the sentence with one clear option (choose the correct intent) such as
"Before creating a PR on GitHub, run the work through these review agents (in
parallel):" or "Before merging any PR on GitHub, run the work through these
review agents (in parallel):" or "Before pushing commits to a PR branch on
GitHub, run the work through these review agents (in parallel):", and add a
short parenthetical or appended clause defining "review agents" (e.g.,
"(automated AI checks and human reviewers)" or "(automated tools/AI agents and
human reviewers)") so readers know whether these are automated checks, humans,
or both.
| 1. **Technical Writer** — Review all changed docs, comments, CLI output, and error messages for clarity, accuracy, and consistency with existing documentation tone. | ||
| 2. **Product Owner** — Verify the changes align with the project goals, V1 phasing priorities, and architecture principles listed above. Flag scope creep or work that doesn't serve the current phase. | ||
| 3. **Legal Compliance Checker** — Check for license compliance (dependencies, attribution), security concerns (credential handling, injection risks), and anything that conflicts with the BSL/SSPL-style license. | ||
| 4. **Reality Checker** — Challenge claims of completeness, correctness, and production readiness. Default to "needs work" — require overwhelming evidence before approving. If tests aren't shown passing, it's not done. If edge cases aren't covered, it's not ready. |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider softening the Reality Checker's adversarial tone.
The Reality Checker description states: "Default to 'needs work' — require overwhelming evidence before approving." This adversarial stance could unnecessarily slow development velocity and create friction, especially for straightforward changes with clear evidence (passing tests, covered edge cases).
A more balanced approach would maintain rigor while avoiding an assumption of inadequacy.
📝 Proposed tone adjustment
-4. **Reality Checker** — Challenge claims of completeness, correctness, and production readiness. Default to "needs work" — require overwhelming evidence before approving. If tests aren't shown passing, it's not done. If edge cases aren't covered, it's not ready.
+4. **Reality Checker** — Verify claims of completeness, correctness, and production readiness with concrete evidence. Require passing tests, covered edge cases, and demonstrated correctness. Challenge assumptions and flag gaps in testing or error handling.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CLAUDE.md` at line 88, Update the "Reality Checker" bullet to soften the
adversarial tone: locate the heading "Reality Checker" and replace the sentence
"Default to 'needs work' — require overwhelming evidence before approving." with
a balanced phrasing that preserves rigor but permits straightforward approvals
when adequate evidence exists (for example: "Default to a thorough review:
require sufficient evidence (passing tests, covered edge cases, clear reasoning)
before approving, but allow approval when the change clearly meets those
criteria"). Ensure the rest of the bullet still calls out missing tests or
unhandled edge cases as blockers.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.claude/agents/legal-compliance.md:
- Line 7: Add a top-level H1 heading to the Markdown file so MD041 is satisfied:
insert a descriptive H1 (for example "Legal and Compliance Review — Mantle")
above the existing body content that begins with "You are a legal and compliance
reviewer for the Mantle project." Ensure the new H1 is the first non-comment
line in the file and follows Markdown heading syntax (a single leading '#').
In @.claude/agents/reality-checker.md:
- Line 24: Update the test-run instruction so it does not truncate output:
remove the piping to `| tail -50` from the command `go test ./... -short -v 2>&1
| tail -50` (i.e., use `go test ./... -short -v 2>&1`) so full test output and
logs are preserved for evidence-first reviews; ensure the README line that
currently includes the truncated command is replaced with the un-truncated
command string.
In @.claude/agents/technical-writer.md:
- Line 7: Add a top-level H1 heading above the line that reads "You are a
technical writer reviewing changes to the Mantle project." to satisfy
markdownlint MD041; insert a concise H1 (for example "# Technical Writer" or "#
Mantle Project — Technical Writer") as the first heading so line 7 starts under
an H1 heading.
In @.claude/settings.json:
- Around line 9-11: The shell permission entries "Bash(git:*)", "Bash(gh:*)",
and "Bash(docker:*)" are too broad; replace them with least-privilege command
patterns or specific allowed subcommands instead of wildcards. Update the
.claude/settings.json entries for Bash(git:*), Bash(gh:*), and Bash(docker:*) to
enumerate only the required git/gh/docker subcommands (e.g.,
"Bash(git:status|diff|clone)", "Bash(gh:pr|gh:issue:list)" or similar) or remove
the entries entirely if not needed, ensuring only non-destructive read-only
operations are permitted. Keep the identifiers Bash(git:*), Bash(gh:*), and
Bash(docker:*) as the locations to change. Ensure patterns do not include push,
force-reset, admin, or secret-related commands.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 433ac0a8-2ae7-4e26-9076-6a1a7a6bfa83
📒 Files selected for processing (6)
.claude/agents/legal-compliance.md.claude/agents/product-owner.md.claude/agents/reality-checker.md.claude/agents/technical-writer.md.claude/settings.json.gitignore
| ## How to Review | ||
|
|
||
| 1. Run `git diff main...HEAD` to see all changes | ||
| 2. Run `go test ./... -short -v 2>&1 | tail -50` to see actual test results |
Contributor
There was a problem hiding this comment.
Do not truncate required test evidence output.
Line 24’s tail -50 can hide relevant failures/log context and undermines the “evidence-first” review standard.
Suggested adjustment
-2. Run `go test ./... -short -v 2>&1 | tail -50` to see actual test results
+2. Run `go test ./... -short -v 2>&1 | tee /tmp/mantle-go-test.log` and review the full output📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| 2. Run `go test ./... -short -v 2>&1 | tail -50` to see actual test results | |
| 2. Run `go test ./... -short -v 2>&1 | tee /tmp/mantle-go-test.log` and review the full output |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/agents/reality-checker.md at line 24, Update the test-run
instruction so it does not truncate output: remove the piping to `| tail -50`
from the command `go test ./... -short -v 2>&1 | tail -50` (i.e., use `go test
./... -short -v 2>&1`) so full test output and logs are preserved for
evidence-first reviews; ensure the README line that currently includes the
truncated command is replaced with the un-truncated command string.
Comment on lines
+9
to
+11
| "Bash(git:*)", | ||
| "Bash(gh:*)", | ||
| "Bash(docker:*)", |
Contributor
There was a problem hiding this comment.
Reduce overly broad shell permissions to least-privilege.
Bash(git:*), Bash(gh:*), and Bash(docker:*) allow high-risk operations (e.g., push, force-reset, secret/admin actions) that are not required for review gates.
Proposed tightening
- "Bash(git:*)",
- "Bash(gh:*)",
- "Bash(docker:*)",
+ "Bash(git diff:*)",
+ "Bash(git log:*)",
+ "Bash(git status:*)",
+ "Bash(gh pr view:*)",
+ "Bash(gh pr checks:*)",
+ "Bash(docker ps:*)",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| "Bash(git:*)", | |
| "Bash(gh:*)", | |
| "Bash(docker:*)", | |
| "Bash(git diff:*)", | |
| "Bash(git log:*)", | |
| "Bash(git status:*)", | |
| "Bash(gh pr view:*)", | |
| "Bash(gh pr checks:*)", | |
| "Bash(docker ps:*)", |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/settings.json around lines 9 - 11, The shell permission entries
"Bash(git:*)", "Bash(gh:*)", and "Bash(docker:*)" are too broad; replace them
with least-privilege command patterns or specific allowed subcommands instead of
wildcards. Update the .claude/settings.json entries for Bash(git:*), Bash(gh:*),
and Bash(docker:*) to enumerate only the required git/gh/docker subcommands
(e.g., "Bash(git:status|diff|clone)", "Bash(gh:pr|gh:issue:list)" or similar) or
remove the entries entirely if not needed, ensuring only non-destructive
read-only operations are permitted. Keep the identifiers Bash(git:*),
Bash(gh:*), and Bash(docker:*) as the locations to change. Ensure patterns do
not include push, force-reset, admin, or secret-related commands.
- Add 4 review agents based on installed agent templates with Mantle-specific project context appended to each: technical-writer, product-manager, legal-compliance, reality-checker - Add shared project settings (.claude/settings.json) - Update .gitignore to commit .claude/settings.json and .claude/agents/ - Rename Product Owner to Product Manager in CLAUDE.md Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.claude/agents/product-manager.md:
- Line 167: The file .claude/agents/product-manager.md is missing a final
newline (markdownlint MD047); open that file and add a single trailing newline
character at the end of the file so the file ends with a blank line/line break,
then save and re-run linting to confirm MD047 is resolved.
In @.claude/agents/reality-checker.md:
- Around line 243-244: Update the commands in reality-checker.md so they match
the project's Makefile: replace the "go test ./... -short -v" instruction with
"go test ./..." (no -short or -v) and replace "go vet ./..." with the project's
lint command "golangci-lint run" (or the exact lint target used in the
Makefile); ensure the two strings "go test ./... -short -v" and "go vet ./..."
are updated to the Makefile equivalents so the agent's pre-merge checks reflect
CI.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 375403a8-76ad-44b4-93a9-f6e878f6157b
📒 Files selected for processing (5)
.claude/agents/legal-compliance.md.claude/agents/product-manager.md.claude/agents/reality-checker.md.claude/agents/technical-writer.mdCLAUDE.md
| - **User value** — Does this serve DevOps engineers and platform teams who need workflow automation? | ||
| - **Consistency** — Does the approach match patterns used elsewhere in the codebase? | ||
|
|
||
| Read CLAUDE.md for full project context before reviewing. No newline at end of file |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add trailing newline to satisfy markdownlint.
Static analysis flags MD047 (missing final newline). This is a standard markdown convention.
📝 Proposed fix
Read CLAUDE.md for full project context before reviewing.
+📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| Read CLAUDE.md for full project context before reviewing. | |
| Read CLAUDE.md for full project context before reviewing. | |
🧰 Tools
🪛 markdownlint-cli2 (0.21.0)
[warning] 167-167: Files should end with a single newline character
(MD047, single-trailing-newline)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/agents/product-manager.md at line 167, The file
.claude/agents/product-manager.md is missing a final newline (markdownlint
MD047); open that file and add a single trailing newline character at the end of
the file so the file ends with a blank line/line break, then save and re-run
linting to confirm MD047 is resolved.
Comment on lines
+42
to
+56
| ```bash | ||
| # 1. Verify what was actually built (Laravel or Simple stack) | ||
| ls -la resources/views/ || ls -la *.html | ||
|
|
||
| # 2. Cross-check claimed features | ||
| grep -r "luxury\|premium\|glass\|morphism" . --include="*.html" --include="*.css" --include="*.blade.php" || echo "NO PREMIUM FEATURES FOUND" | ||
|
|
||
| # 3. Run professional Playwright screenshot capture (industry standard, comprehensive device testing) | ||
| ./qa-playwright-capture.sh http://localhost:8000 public/qa-screenshots | ||
|
|
||
| # 4. Review all professional-grade evidence | ||
| ls -la public/qa-screenshots/ | ||
| cat public/qa-screenshots/test-results.json | ||
| echo "COMPREHENSIVE DATA: Device compatibility, dark mode, interactions, full-page captures" | ||
| ``` |
Contributor
There was a problem hiding this comment.
Critical: Mandatory commands are wrong for this project.
The "Reality Check Commands" reference Laravel/PHP structures (resources/views/), frontend design terms (luxury|premium|glass|morphism), and Playwright E2E testing that don't exist in Mantle. Code snippet analysis confirms:
- No Playwright:
site/package.jsonhas no Playwright dependency, so./qa-playwright-capture.shcannot exist - Wrong stack: Mantle is a Go CLI + Postgres project, not a Laravel/PHP web application
- Wrong concerns: "luxury/premium" design checks are irrelevant to a headless automation platform
This section appears copied from a web design QA template without adaptation for Mantle's Go backend architecture.
Lines 58-120 also extensively reference these non-existent Playwright screenshots, compounding the issue.
🔧 Recommended fix
Replace the entire STEP 1 section (lines 42-56) with Mantle-appropriate checks:
-### STEP 1: Reality Check Commands (NEVER SKIP)
-```bash
-# 1. Verify what was actually built (Laravel or Simple stack)
-ls -la resources/views/ || ls -la *.html
-
-# 2. Cross-check claimed features
-grep -r "luxury\|premium\|glass\|morphism" . --include="*.html" --include="*.css" --include="*.blade.php" || echo "NO PREMIUM FEATURES FOUND"
-
-# 3. Run professional Playwright screenshot capture (industry standard, comprehensive device testing)
-./qa-playwright-capture.sh http://localhost:8000 public/qa-screenshots
-
-# 4. Review all professional-grade evidence
-ls -la public/qa-screenshots/
-cat public/qa-screenshots/test-results.json
-echo "COMPREHENSIVE DATA: Device compatibility, dark mode, interactions, full-page captures"
-```
+### STEP 1: Reality Check Commands (NEVER SKIP)
+```bash
+# 1. Run the full test suite
+go test ./... -v
+
+# 2. Run static analysis
+golangci-lint run
+
+# 3. Verify the binary builds
+go build -o mantle ./cmd/mantle
+
+# 4. If site changes, verify docs build
+cd site && npm run build
+```Also revise lines 58-120 to remove Playwright screenshot references and focus on Go test output and build verification.
Comment on lines
+243
to
+244
| - **Run the tests** — `go test ./... -short -v`. If tests don't pass, it's NEEDS WORK. No exceptions. | ||
| - **Check vet/lint** — `go vet ./...`. Clean output required. |
Contributor
There was a problem hiding this comment.
Commands don't match actual Makefile targets.
The suggested test commands don't align with the project's actual CI targets:
- Line 243: Specifies
go test ./... -short -vbut the Makefile (line 11-12) runsgo test ./...without-shortor-vflags - Line 244: Specifies
go vet ./...but the Makefile (line 14-15) runsgolangci-lint runfor linting, which is more comprehensive
This creates a gap where the agent could approve a PR based on these commands while the actual CI pipeline fails on stricter checks.
🔧 Align with Makefile targets
-- **Run the tests** — `go test ./... -short -v`. If tests don't pass, it's NEEDS WORK. No exceptions.
-- **Check vet/lint** — `go vet ./...`. Clean output required.
+- **Run the tests** — `make test` (runs `go test ./...`). If tests don't pass, it's NEEDS WORK. No exceptions.
+- **Check lint** — `make lint` (runs `golangci-lint run`). Clean output required.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| - **Run the tests** — `go test ./... -short -v`. If tests don't pass, it's NEEDS WORK. No exceptions. | |
| - **Check vet/lint** — `go vet ./...`. Clean output required. | |
| - **Run the tests** — `make test` (runs `go test ./...`). If tests don't pass, it's NEEDS WORK. No exceptions. | |
| - **Check lint** — `make lint` (runs `golangci-lint run`). Clean output required. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/agents/reality-checker.md around lines 243 - 244, Update the
commands in reality-checker.md so they match the project's Makefile: replace the
"go test ./... -short -v" instruction with "go test ./..." (no -short or -v) and
replace "go vet ./..." with the project's lint command "golangci-lint run" (or
the exact lint target used in the Makefile); ensure the two strings "go test
./... -short -v" and "go vet ./..." are updated to the Makefile equivalents so
the agent's pre-merge checks reflect CI.
Use the complete Product Manager agent definition with discovery, framing, delivery, and measurement phases. Mantle project context appended at the end. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
I'm going to write some custom skills instead to do these steps as part of a release readiness workflow. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a "Pre-Push Review Gates" section to CLAUDE.md requiring four agent reviews before any PR is pushed to GitHub:
Why
Catches misalignment early across docs quality, product direction, legal compliance, and implementation rigor. Applies to all PRs regardless of size.
🤖 Generated with Claude Code
Summary by CodeRabbit
Documentation
Chores