Borrowing it
Nothing to install: this file belongs to majiayu000/vibeguard. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/majiayu000/vibeguard/main/.claude/commands/vibeguard/cross-review.mdgit clone --depth 1 https://github.com/majiayu000/vibeguardWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/majiayu000/vibeguard/cross-review)<a href="https://agentmods.dev/commands/majiayu000/vibeguard/cross-review"><img src="https://agentmods.dev/badge/commands/majiayu000/vibeguard/cross-review/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/majiayu000/vibeguard/cross-review"><img src="https://agentmods.dev/badge/commands/majiayu000/vibeguard/cross-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00030 | $0.02197 |
| Opus 5 | $0.00015 | $0.01099 |
| Sonnet 5 | $0.00006 | $0.00439 |
| Haiku 4.5 | $0.00003 | $0.00220 |
Grade A, and why
VibeGuard: Cross Review scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 194 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Core Concept
- There are blind spots in single model review, and independent verification of the second model can detect omissions
- Claude is responsible for generating structured reviews, and Codex does adversarial questioning through a structured lens
- Review depth adapts to the size of the change: small changes focus on correctness, while large changes cover architecture and over-design
- Iterate to convergence for at most two total review rounds
- Automatically downgrade to single model review when Codex is unavailable (
/vibeguard:review)
Reviewer Lenses
Three complementary perspectives, each focusing on a different failure mode:
| Lens | Focus | Core Issues |
|---|---|---|
| Skeptic | Correctness | Destructive input? Unhandled error? Race condition? Untested hypothesis? Does "works on my machine" replace strict verification? |
| Architect (Architect) | Structural Integrity | Does the design actually achieve its goals? Coupling vulnerability? Boundary violation? Implicit assumptions about scale/concurrency/sequence? |
| Minimalist (minimalist) | Necessity | What can be deleted? Are you solving a hypothetical problem? Is it the easiest way to achieve your goal? Is there premature abstraction? |
Lens Allocation Rules (automatically selected based on change size):
| Change row count | Assigned shots | Reason |
|---|---|---|
| < 50 lines | Skeptic | The biggest risk of small changes is correctness bugs |
| 50-200 lines | Skeptic + Architect | Moderate changes need to check the structural impact |
| 200+ lines | Skeptic + Architect + Minimalist | Big changes are easy to over-design |
Steps
-
Check Codex Availability
- Run
which codexto check if Codex CLI is installed - If it is not available, output the prompt and downgrade the complete process of executing
/vibeguard:review, and end - If available, continue the dual model process
- Run
-
Get guard baseline
- Run
bash guards/<language>/check_*.sh <target_dir>to get the current guard status - Record existing issues as a baseline (no duplication of reports)
- Run
-
Determine the scope and lens of the review
- If a file path is specified: review the file
- If a directory is specified: review recently modified files (
git diff --name-only) - If no parameters: review the files in the current git staging area
- Remember the target directory as
$TARGET_DIR - Count the number of changed lines:
git diff --statorwc -l - Determine the active lens based on row number (see table above)
-
Claude generates review report (Round 1)
- Review by priority P0-P3 (consistent with
/vibeguard:review):- P0 security: refer to
rules/claude-rules/common/security.md, OWASP Top 10, key leakage, input verification - P1 logic: boundary conditions, error handling, concurrency safety, data consistency (U-11~U-14)
- P2 quality: duplicate code, naming conventions, exception handling, file size
- P3 performance: hot paths, N+1 queries, memory allocation
- P0 security: refer to
- Write review report to
/tmp/vibeguard-cross-review-<timestamp>.md - Report format:
## Claude Review Report (Round N) ### Guard the baseline <Summary of guard script results> ### Scope of review - Change number of rows: <N> - Activate lens: <Skeptic / Skeptic+Architect / Skeptic+Architect+Minimalist> ### Discover | Priority | File:line number | Question | Suggestion | |--------|-----------|------|------| | P0 | ... | ... | ... | ### Passed items - <Confirm that there are no problems>
- Review by priority P0-P3 (consistent with
-
Codex Lens Review
- Construct a dedicated prompt for each activated lens and run the Codex (read-only sandbox):
codex exec --skip-git-repo-check -a read-only -C "$TARGET_DIR" \ "You are a code reviewer conducting adversarial reviews using the [LENS_NAME] lens. ## Your Lens: [LENS_NAME] [LENS_DESCRIPTION — see lens definition table] ## Review report (generated by another model) $(cat /tmp/vibeguard-cross-review-<timestamp>.md) ## Your task 1. Validate each finding in the report through your lens (marked CONFIRMED / FALSE-POSITIVE) 2. Check for missing issues from your camera’s perspective (list MISSED items, note camera source) 3. Evaluate whether the repair proposal is reasonable ## Output format ### [LENS_NAME] review results #### verify - [Discovery 1]: CONFIRMED / FALSE-POSITIVE — Reason #### Omission - MISSED [LENS_NAME]: Description #### Judgment VERDICT: APPROVED / REVISE — reason" 2>/dev/null - Codex calls for multiple lenses merged into one execution (avoiding multiple startup overhead), listing all active lenses in prompt
- Capture Codex output
- Construct a dedicated prompt for each activated lens and run the Codex (read-only sandbox):
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 194 lines · 30 tokens per session scan A 80d1fa783a03
VibeGuard: Cross Review is a command published in the GitHub repository majiayu000/vibeguard (42 stars, last pushed today), licensed MIT. It adds 30 tokens to every session and 2,197 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
merge
Finish a PR properly: every check green, every review addressed — human and bot — then merge and clean up.
pr
Prepare and open a pull request the senior way: gate, template, scrubbed, everything visible.
spec
Spec-first design: a gap-closing interview that produces a complete spec, with a quality controller that blocks until every section is answered and every question resolved.
debug
Systematic debugging: root cause before any fix, one hypothesis at a time, and a three-strikes rule that questions the architecture instead of stacking patches.
plan
Turn an approved spec into an implementation plan an engineer with zero context could execute — with a quality controller that blocks placeholders and hollow tasks.
tdd
Test-driven development with tests that actually catch breaks: red before green, name the break each test catches, and the mutation check before done.