本文へ移動
cccskills
無料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.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md6.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

/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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

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.

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

blueprint

無料

"/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).

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

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".

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

bugfix

無料

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.

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

check

無料

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 전 확인", "뭐 더 건드려야 해?", "연쇄 변경 확인", "규칙 갱신".

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

clarify

無料

"/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.

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

team-attention のスキルをすべて見る

このスキルの問題を報告する