Borrowing it
Nothing to install: this file belongs to kangig94/coral. 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/kangig94/coral/main/.claude/skills/tier-review/SKILL.mdgit clone --depth 1 https://github.com/kangig94/coralWrote 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/skills/kangig94/coral/tier-review)<a href="https://agentmods.dev/skills/kangig94/coral/tier-review"><img src="https://agentmods.dev/badge/skills/kangig94/coral/tier-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/skills/kangig94/coral/tier-review"><img src="https://agentmods.dev/badge/skills/kangig94/coral/tier-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.00019 | $0.01125 |
| Opus 5 | $0.00010 | $0.00562 |
| Sonnet 5 | $0.00004 | $0.00225 |
| Haiku 4.5 | $0.00002 | $0.00112 |
Grade A, and why
tier-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 11d 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 — 93 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Review Gate
Run project review agents by tier taxonomy, consolidate findings, issue a verdict.
<Review_Protocol> You are the review gate executor. Discover which project agents exist, match them to the review scope, spawn by tier, and consolidate into a single verdict. All paths below are relative to the user's project root (working directory), not the plugin.
## Phase 1 — Discover Agents
1. Read the project's `.claude/rules/agents.md` for the Quick Reference table (agent, tier, purpose)
and the Consultation Matrix (task category → agent mapping), and add coral:architect to the list of agents with tier 1 by default.
2. If agents.md not found, read `.claude/agents/*.md` — look for tier in description
or Situation table. If tier is unclear, treat safety-related agents as tier 1,
domain-specific as tier 2, quality reviewers as tier 3.
3. If no agents found at all → report "no review agents configured" and exit.
## Phase 2 — Plan
1. Determine review scope from conversation context:
- Explicit argument → use it
- Recent implementation in conversation → those files
- Neither → fall back to git diff (staged + unstaged)
2. For each agent, check against the scope:
- Consultation Matrix: is this task category → agent mapping MANDATORY?
- Agent's Situation/Priority table: does the scope match?
3. Build an invocation table — for each agent: INVOKE (with scope + focus) or SKIP (with reason)
- If all agents are SKIP → report "no agents relevant to this scope" and exit.
4. Report the table before executing.
## Phase 3 — Execute
Spawn only agents marked INVOKE in the table.
For each agent, pass: "Review [scope files] focusing on [focus from plan]."
**Every spawn prompt MUST end with this shared-worktree guard** — reviewers run in parallel in the same working tree, so one stray git command reverts every sibling's work:
> ⚠️ Review is read-only. NEVER run `git checkout`, `git switch`, `git stash`, `git reset`, `git restore`, or `git clean`, and never stage or commit — you share this working tree with parallel reviewers. To inspect another revision, use `git diff <ref>`, `git show <ref>:<path>`, or `git log <ref>` — never check it out.
**Default**: spawn ALL INVOKE agents in parallel, wait for all.
**With `--gated`** (cost-saving short-circuit — use when API budget is tight):
1. Tier 1 (safety) — spawn in parallel, wait for all to complete
- If ANY returns BLOCKING findings → output REJECT verdict, STOP here
2. Tier 2 (domain) + tier 3 (quality) — spawn in parallel, wait for all to complete
## Phase 4 — Consolidate
Apply merge rules to all agent results:
1. **Verdict mapping**: agent PASS → no BLOCKING; agent NEEDS WORK → STRONG findings
2. **Dedup**: same file:line from multiple agents → single entry, list all agents
3. **Severity**: agents disagree → use higher severity
4. **Convergent signals**: same file flagged by multiple agents → elevate priority
5. **Root cause**: tier 1 finding that explains tier 3 symptom → connect and elevate
Issue final verdict:
| Condition | Verdict |
|-----------|---------|
| Any BLOCKING finding | REJECT |
| Multiple unresolved STRONG findings | NEEDS WORK |
| No BLOCKING, 1-2 STRONG items remaining | APPROVED WITH CONDITIONS |
| No BLOCKING, no unresolved STRONG | APPROVED |
| No BLOCKING, no STRONG, all agents report high quality | EXCEPTIONAL |
| Tier | Agent | Status | Verdict | Key Findings |
|------|-------|--------|---------|--------------|
| {1/2/3} | {agent} | INVOKED/SKIPPED | PASS/FAIL/- | {summary or skip reason} |
### Strengths
- {Positive observations from agents with file:line evidence}
### Consolidated Findings
| # | Severity | Agent(s) | Location | Finding | Suggestion |
|---|----------|----------|----------|---------|------------|
| 1 | BLOCKING/STRONG/MINOR | {sources} | file:line | {issue} | {fix} |
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.
- 11d ago First seen · 93 lines · 19 tokens per session scan A 51ad6fda0f58
tier-review is a skill published in the GitHub repository kangig94/coral (11 stars, last pushed yesterday), licensed MIT. It adds 19 tokens to every session and 1,125 once invoked, about $0.0001 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 skills, from other repositories
plan-eng-review
Eng manager-mode plan review. Lock in the execution plan — architecture, data flow, diagrams, edge cases, test coverage, performance. Walks through issues interactively with opinionated recommendations. Use when asked to "review the architecture", "engineering review", or "lock in the plan". Proactively suggest when…
pre-landing-review
Pre-landing PR review. Analyzes diff against the base branch for SQL safety, LLM trust boundary violations, conditional side effects, and other structural issues. Use when explicitly asked for the specialized pre-landing workflow. Product /review requests are handled by OpenBitFun's unified Review mechanism instead.…
autoplan
Auto-review pipeline — reads the full CEO, design, eng, and DX review skills from disk and runs them sequentially with auto-decisions using 6 decision principles. Surfaces taste decisions (close approaches, borderline scope, codex disagreements) at a final approval gate. One command, fully reviewed plan out. Use when…
pr-review-canvas
Create a OpenBitFun Canvas for reviewing a pull request, branch diff, or change set with Cursor-style diff cards, review maps, risk callouts, and focused reviewer flow. Use when the user asks for a PR review canvas, diff walkthrough, change-set overview, or visual review summary.
gh-pr-review
Automated Cherry Studio review for local branches, PRs, commits, files, architecture docs, and repository skills. Use for code or documentation reviews that need project-specific naming, main/renderer/shared placement and dependency rules, IpcApi and DataApi boundaries, lifecycle/service ownership, renderer hooks…
flow-next-impl-review
Carmack-level implementation review of changes via the configured backend. Use when asked to review code or a diff in a flow-next repo.