Skip to content
cccskills
FreePublished on GitHub

tribunal

This skill should be used when the user says "/tribunal", "tribunal", "review this", "3-way review", "risk-value-feasibility check", or wants multi-perspective adversarial review. Also triggered by: "트리뷰널", "리뷰 해줘", "3관점 리뷰", "위험성 검토". Runs 3 agents (Risk/Value/Feasibility) in parallel and synthesizes a verdict.

The English summary is being prepared. Showing the original description.

Works withGitHub
See how to install

Files included (1)

  • SKILL.md6.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

/tribunal — 3-Perspective Adversarial Review

You are a tribunal orchestrator. You launch 3 review agents with distinct perspectives, then synthesize their findings into a unified verdict.

Architecture

            ┌─ codex-risk-analyst (Codex)  ── "What can go wrong?"
Input ──────┼─ value-assessor (Claude)     ── "What value does this deliver?"
            └─ feasibility-checker (Claude) ── "Can this actually be built?"
                         ↓
               You synthesize all 3
               → APPROVE / REVISE / REJECT

Step 1: Parse Input

Determine the review target from arguments:

InputHow to get content
file.md or pathRead(file_path)
--pr <number>Bash("gh pr diff <number>") and Bash("gh pr view <number>")
--diffBash("git diff HEAD") or Bash("git diff main...HEAD")
No argsAsk user what to review via AskUserQuestion

Collect the full content — all 3 agents need the same input.

If reviewing a PLAN.md, also read the corresponding DRAFT.md (if exists) for context.


Step 2: Launch Tribunal (3 Agents in Parallel)

Launch all 3 agents simultaneously in a single message:

# Risk Analysis (Codex-powered — adversarial)
Task(subagent_type="codex-risk-analyst",
     prompt="""
Review Target: [type - plan/PR/diff/proposal]

## Content
[Full content to review]

## Context (if available)
[Project structure, related patterns, constraints]

Perform adversarial risk analysis. Find everything that could go wrong.
""")

# Value Assessment (Claude — constructive)
Task(subagent_type="value-assessor",
     prompt="""
Review Target: [type - plan/PR/diff/proposal]

## Content
[Full content to review]

## Original Goal
[What was the intent/requirement behind this work]

Assess the value this delivers. Be genuinely constructive but honest.
""")

# Feasibility Check (Claude — pragmatic)
Task(subagent_type="feasibility-checker",
     prompt="""
Review Target: [type - plan/PR/diff/proposal]

## Content
[Full content to review]

## Codebase Context
[Relevant patterns, dependencies, test infrastructure]

Evaluate practical feasibility. Can this actually be built/merged?
""")

CRITICAL: All 3 in ONE message (parallel). Do NOT run sequentially.


Step 3: Synthesize Verdict

After all 3 agents return, synthesize their findings.

3.1 Extract Ratings

From each report, extract the summary rating:

  • Risk: BLOCK / CAUTION / CLEAR (from risk analyst)
  • Value: STRONG / ADEQUATE / WEAK (from value assessor)
  • Feasibility: GO / CONDITIONAL / NO-GO (from feasibility checker)

3.2 Verdict Matrix

RiskValueFeasibilityVerdict
CLEARSTRONGGOAPPROVE
CLEARADEQUATEGOAPPROVE
CAUTIONSTRONGGOAPPROVE (with notes)
CAUTIONADEQUATEGOREVISE
CAUTION*CONDITIONALREVISE
BLOCK**REVISE (or REJECT if critical count > 2)
*WEAK*REVISE
**NO-GOREJECT
BLOCKWEAK*REJECT

Use judgment for combinations not in the matrix.

3.3 Identify Contention Points

Find areas where agents disagree:

  • Risk says dangerous, but Value says high-impact → worth the risk?
  • Feasibility says hard, but Value says critical → invest the effort?
  • Risk says fine, but Feasibility says blocked → hidden dependency?

3.4 Compile Required Actions

From all 3 reports, extract actionable items:

  • Must fix (from BLOCK risks or NO-GO feasibility)
  • Should address (from CAUTION risks or CONDITIONAL feasibility)
  • Nice to have (from missed opportunities in value assessment)

Step 4: Present Tribunal Report

## Tribunal Verdict

### Panel Scores

| Dimension | Agent | Rating | Key Finding |
|-----------|-------|--------|-------------|
| Risk | codex-risk-analyst | [BLOCK/CAUTION/CLEAR] | [1-line summary] |
| Value | value-assessor | [STRONG/ADEQUATE/WEAK] | [1-line summary] |
| Feasibility | feasibility-checker | [GO/CONDITIONAL/NO-GO] | [1-line summary] |

### Verdict: [APPROVE / REVISE / REJECT]

[1-2 sentence rationale]

### Contention Points
[Where agents disagreed and the resolution reasoning]

### Required Actions
**Must Fix (before proceeding):**
1. [action from risk/feasibility]

**Should Address:**
1. [action]

**Consider:**
1. [action from value missed opportunities]

### Strengths to Preserve
[Key positives identified by value-assessor that should NOT be lost in revisions]

---

<details>
<summary>Full Risk Analysis</summary>

[Complete risk analyst report]

</details>

<details>
<summary>Full Value Assessment</summary>

[Complete value assessor report]

</details>

<details>
<summary>Full Feasibility Report</summary>

[Complete feasibility checker report]

</details>

Step 5: Handle Verdict

After presenting the report:

VerdictAction
APPROVEInform user: "Tribunal approves. Proceed with confidence."
REVISEPresent required actions. Ask user how to proceed.
REJECTPresent blockers clearly. Recommend returning to planning.

For REVISE:

AskUserQuestion(
  question: "Tribunal recommends revisions. How do you want to proceed?",
  options: [
    { label: "Apply fixes", description: "Address the required actions and re-review" },
    { label: "Override — proceed anyway", description: "Acknowledge risks and continue (Disagree & Commit)" },
    { label: "Back to planning", description: "Return to /specify to rethink approach" }
  ]
)

Usage Examples

# Review a plan
/tribunal .hoyeon/specs/auth-feature/PLAN.md

# Review a PR
/tribunal --pr 421

# Review current uncommitted changes
/tribunal --diff

# Review with no args (will ask what to review)
/tribunal

Checklist Before Stopping

  • All 3 agents launched in parallel (single message)
  • Verdict synthesized with scores table
  • Contention points identified (where agents disagreed)
  • Required actions listed (if REVISE or REJECT)
  • Full reports included in collapsible details
  • User action presented based on verdict

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Analyze an open-source project from What/Why perspective (not how-it's-implemented). Use when the user says "/analyze-oss", "분석해줘 이 오픈소스", "이 레포 뭐하는거야", "analyze this repo", "what does X do", "이거 왜 쓰는거야", "이 라이브러리 분석", provides a GitHub URL and wants understanding, or asks to deeply understand an OSS project's purpose, value, target users, and usage flow. Clones the repo to ~/opensource-analysis/<repo-name>/ (git pull if already exists), dispatches parallel subagents per analysis lens, then synthesizes a What/Why-focused report in chat. Supports optional user-specific follow-up questions.

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

"/blueprint", "blueprint", "task graph", "contract derivation", "execution plan", "plan tasks from requirements", "contract-first planning" Turn requirements.md into an executable blueprint (plan.json + contracts.md). Five phases: Contracts → Tasks → Journeys → Verify Plan → Commit. Sits between /specify and /execute. Scope-adaptive (greenfield → bugfix). Uses hoyeon-cli (plan.json only; requirements.md is read as-is via Read tool).

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

Recon-first browser automation. Orchestrator explores the site first via chromux, saves a guide file with insights, then delegates execution to browser-explorer agent. Use when: "/browser-work", "브라우저 작업", "사이트에서 해줘", "웹에서 해줘", "LinkedIn에서", "크롬으로", "browser task", "automate this site".

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

bugfix

Free

Root cause based one-shot bug fix. debugger diagnosis → requirements.md generation → /execute. /bugfix "error description" Full investigation pipeline: debugger + gap-analyzer + standard verify. QA suggestion after successful fix.

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

check

Free

This skill should be used when the user wants to verify their changes before pushing, or update the project's rule checklists. Phase 1: validate changed files against .hoyeon/rules/ checklists and report PASS/WARN. Phase 2 (conditional): propose rule additions when unmatched patterns are detected. Essential before git push. Trigger phrases: "check", "checklist", "verify changes", "what did I miss", "pre-push check", "cascading changes", "any more changes needed", "update checklist", "update rules", "rules update", "체크", "체크리스트", "변경 확인", "빠뜨린 거 없나", "push 전 확인", "뭐 더 건드려야 해?", "연쇄 변경 확인", "규칙 갱신".

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

"/clarify", "clarify this", "keep asking until clear", "remove ambiguity", "clarify requirements", "clarify design", "clarify the plan", "질문 계속해", "모호한 게 없게", "명확해질 때까지", "계속 물어봐", "Q&A로 정리", "질문답변 기록", "요구사항 명확화", "설계 명확화". Relentless ambiguity-resolution interview that records Q&A under .hoyeon/clarify/<topic>/ and hands off to specify/blueprint/docs when clear.

The English summary is being prepared. Showing the original description.

team-attention/hoyeon173Updated May 21, 2026

See all skills by team-attention

Report a problem with this skill