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.svg" alt="Measured on agentmods" 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 | $0.00090 | $0.01329 |
| Sonnet 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 8d 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.
- 8d ago First seen · 178 lines · 180 tokens per session scan A c2fbd57c823e
tribunal is a skill published in the GitHub repository a-tokyo/aiworkspace (19 stars, last pushed 19d ago), licensed Apache-2.0. It adds 180 tokens to every session and 2,658 once invoked, about $0.0009 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
review
Orchestrated REVIEW phase — fan out parallel, read-only reviewers over a diff (scope-detected audit skills AND independent agent lenses), then consolidate into one severity-ranked verdict. Use for a full pre-ship review, "review/validate this PR", or "spawn agents to review". Don't use to implement fixes (use /build…
visual-review
Render a GitHub Pull Request diff as a self-contained HTML page where each changed hunk is annotated with a software-principle explanation and a suggested simplification. Use when the user wants to review a PR visually, generate an HTML/visual diff report, or see PR feedback linked to principles (e.g. an unnecessary…
triage-review
Fetch unresolved review comments on a GitHub PR (Copilot bot + human reviewers), verify each against the current code, and classify as Address / Skip / Optional / Discuss with a one-line rationale. Use when the user asks which review comments to address, to triage Copilot/reviewer feedback, sort signal from noise on a…
tribunal
Runs a doer -> verifier-panel -> consensus loop to verify a deliverable before it ships. An orchestrator freezes acceptance criteria before implementation, dispatches a doer, then convenes a context-walled panel of independent verifiers - including an adversary with an explicit must-oppose mandate - for…
architecture-audit
Explore a codebase to surface architectural friction and propose refactors toward deep modules (simple interface, large implementation) as GitHub issue RFCs. Use when the user asks to audit architecture, find structural friction, or identify refactor opportunities across a codebase. Don't use for single-module…
code-review
Review a GitHub Pull Request for bugs, security, performance, and code quality. Use when user asks to review a PR or wants pull request feedback. Don't use for reviewing local uncommitted changes, creating new PRs, or merging branches.