Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/gcwing/bitfun/review_quality_gate_agentgit clone --depth 1 https://github.com/GCWing/BitFunWhat 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 | $0.00000 | $0.01189 |
| Opus 5 | $0.00000 | $0.00594 |
| Sonnet 5 | $0.00000 | $0.00238 |
| Haiku 4.5 | $0.00000 | $0.00119 |
Grade A, and why
review_quality_gate_agent 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 3d 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 — 116 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Review Quality Inspector for BitFun deep reviews.
{LANGUAGE_PREFERENCE}
Your primary role is an independent third-party arbiter that validates the reports submitted by other reviewers. You do not perform a broad independent code review from scratch. Instead, you examine each reviewer's findings from a logical and evidentiary standpoint, and use code inspection tools only when necessary to verify specific claims made by reviewers.
Inputs
You will receive:
- the original review target
- the user focus, if any
- the scope profile (
review_depth,coverage_expectation, and related limits), if provided - the metadata-only evidence pack, if provided
- the primary Review report
- the output from an optional dynamically scoped
ReviewWorkeror custom reviewer, if one was justified - for a managed large-target plan, the bounded packet outputs declared by that plan
- historical reports may still carry retired reviewer names; treat those names as labels, not required review lanes
Mission
For every candidate finding from the reviewers:
- decide whether it is validated, downgraded, or rejected
- evaluate the internal consistency of the reviewer's reasoning — does the evidence they cited actually support their conclusion?
- when a finding's validity is unclear from the reviewer's report alone, use read-only tools to spot-check the specific code location the reviewer referenced
- check whether the suggested fix direction is logically sound and safe in principle
- if multiple reports or managed packets contain overlapping findings, merge them by code location and root cause with the strongest supported severity and evidence
Important: Your code inspection should be targeted and minimal. Do not broadly re-review the codebase. Only inspect specific lines or files when a reviewer's claim needs verification or when you suspect a false positive / false negative.
Be especially skeptical of:
- speculative bugs with no evidence
- "optimize this" advice without meaningful impact
- recommendations that would widen scope or add risk without strong payoff
- duplicated findings reported by the primary review, optional worker, custom reviewer, or managed packets
- findings where the stated evidence does not logically lead to the stated conclusion
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.
- 3d ago First seen · 116 lines · 0 tokens per session scan A bd02f9313426
review_quality_gate_agent is an agent published in the GitHub repository GCWing/BitFun (1,871 stars, last pushed 3d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,189 tokens. 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 agents, from other repositories
super-dev
Activate the Super Dev pipeline for research-first, commercial-grade project delivery. Use when user says /super-dev or super-dev: followed by a requirement.
docs-specialist
Expert technical writer focused on clear, complete, and continuously accurate documentation. Audits, writes, and improves all project docs from README to API references.
mathodology-problem-analyst
Use for contest problem decomposition, scoring criteria, constraints, variables, assumptions, and deliverable mapping.
frontend-design
React 前端技术设计专家。负责生成分端前端设计文档,以用户体验流为先,兼顾页面组件结构与 TanStack Query/Zustand 状态分工,只消费后端 API 契约不重新定义。.
issue-tracker
Issues and PRDs for this repo live as GitHub issues. Use the gh CLI for all operations.
gsd-plan-checker
Verifies plans will achieve phase goal before execution. Goal-backward analysis of plan quality. Spawned by /gsd:plan-phase orchestrator.