Borrowing it
Nothing to install: this file belongs to a-tokyo/aiworkspace. 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/a-tokyo/aiworkspace/main/.agents/skills/tribunal/SKILL.mdgit clone --depth 1 https://github.com/a-tokyo/aiworkspaceWrote 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/a-tokyo/aiworkspace/tribunal)<a href="https://agentmods.dev/skills/a-tokyo/aiworkspace/tribunal"><img src="https://agentmods.dev/badge/skills/a-tokyo/aiworkspace/tribunal/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/a-tokyo/aiworkspace/tribunal"><img src="https://agentmods.dev/badge/skills/a-tokyo/aiworkspace/tribunal.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00180 | $0.02658 |
| Opus 5.5 | $0.00072 | $0.01063 |
| Sonnet 5.5 | $0.00036 | $0.00532 |
| Haiku 4.5 | $0.00018 | $0.00266 |
Grade A, and why
tribunal 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 1mo 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 — 178 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Tribunal
The orchestrator builds nothing and scores nothing itself — it slices the work, dispatches a separate doer, convenes separate verifiers, and adjudicates on evidence. Three behaviors carry the value: an adversarial second look that catches what a single pass ships silently, as named failure scenarios; calibrated verdicts — locally fixable defects get ITERATE, not "rewrite everything", and passing math is overridden only by verified evidence; evidence before claims — nothing is "done" without fresh reproduction; refuted claims are excluded, never averaged in. Announce at start: "Running this through the tribunal pattern: doer -> verifier panel -> consensus."
When to use
Multi-part or high-stakes deliverables where a shipped defect costs more than a panel. Not for trivial edits, anything one verification command proves, or ordinary code review (dialogue improving a change vs independent measurements of a frozen artifact against pre-declared criteria, adjudicated to a ship decision). Never nest tribunals — no role runs the protocol on its own output.
The loop
- Freeze acceptance criteria and verification commands BEFORE implementation; derive scoring dimensions, weights, and a pass target from them, recorded so re-panels reuse the rubric. Identify the operative skills in play — those bearing on how the artifact is built or judged (e.g. production-grade); never the tribunal skill itself nor pure orchestration skills — and fold their standards into the criteria. Verify-only entry (artifact already exists): write criteria from the original request — never reverse-engineered from it — freeze, start at step 3.
- Spawn a SEPARATE doer agent (never the orchestrator itself) with the full slice spec pasted in (never "read the plan file") and the operative skills named with an instruction to load them (load production-grade, etc.) — if it cannot load a named skill it says so rather than proceeding. If the orchestrator writes or edits the deliverable, there is no independent artifact to verify and the run collapses to one context. The doer implements, runs the verification commands, and reports a diff summary, verbatim output, and exactly one status (table below).
- Check the report against the actual diff yourself; dispatch the panel in parallel, context-walled.
- Adjudicate per consensus-mechanics.md; record verdict, dissents, caveats, and round count in the ledger.
- SHIP -> next slice. ITERATE -> findings become a fix list for a fresh doer; re-panel with fresh verifiers re-scoring every dimension, prior findings as risks.
What ships with it
4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 1mo ago First seen · 178 lines · 180 tokens per session scan A c2fbd57c823e
tribunal is a skill published in the GitHub repository a-tokyo/aiworkspace (21 stars, last pushed 2mo ago), licensed Apache-2.0. It adds 180 tokens to every session and 2,658 once invoked, about $0.0007 per session on Opus 5.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
review
Run the full pre-merge panel: parallel audit and lens reviewers over a diff, consolidated into one severity-ranked verdict.
visual-review
Two visual modes — render a PR diff as an HTML page with each hunk annotated by principle, or check a UI change in a real browser (screenshots, console, network). Use for a visual/HTML diff report, "check the UI", or "screenshot before/after". Don't use for text-only feedback (/code-review), unit tests (/tdd), or full…
code-review
Review a PR or branch on two axes only, quality and spec, in parallel subagents reported side by side.
feedback
Fetch unresolved review comments on a GitHub PR (Copilot and human), verify against the code, classify Address / Skip / Optional / Discuss. Use when asked to triage reviewer feedback, which comments to actually fix, or to sort signal from noise on a PR. Don't use to reply to or resolve threads, or to write a fresh…
architecture-audit
Surface architectural friction across a codebase and propose deep-module refactors as RFCs.
pr-address
Address PR review comments and loop until CI green and all comments resolved. TRIGGER when user asks to address comments, fix PR feedback, respond to reviewers, or babysit/monitor a PR.