assess

評価

ホストに依存しないワークフローです。スキル名（assess）で呼び出します。Claude Code のスラッシュルーティング、YAML フックローダー、.claude/chain については、references/claude-code.md を参照してください。

「これは良いか？」に答えるための包括的な評価スキルです。体系的な評価、スコアリング、実行可能な推奨事項を提供します。

🎯 クイックスタート

assess backend/app/services/auth.py
assess our caching strategy
assess --model=opus the current database schema
assess frontend/src/components/Dashboard

労力レベル（CC 2.1.111+ で xhigh が追加）

労力	動作
low / medium	寸法の一部を評価し、より短時間で完了
high（デフォルト）	6 つすべての寸法を長所・短所とともに評価
xhigh	6 つすべての寸法を評価し、不確実性や注意点に焦点を当てた追加の評価者パスを 1 回実行。各寸法について confidence を出力

xhigh に対応していないモデルでは、エラーもログ行も出さずに high へ自動的にフォールバックします。doctor のカテゴリ 14 では、アクティブなモデルがそのレベルに対応していないことを確実に証明できる場合に限り、これが報告されます。

---

引数の解決

ステップ 0：まず代名詞の対象を解決する

$ARGUMENTS はパスでないことがよくあります。Read("../../shared/rules/target-resolution.md") を読み込み、 そのインライン部分に従ってください。対象が代名詞や指示語（them、this、the above）だけの場合、または 対象が空の場合は、会話内の最も近い具体的な対象を読み取り、1 行で告知して評価します。 会話が空の場合に限り、質問してください。

TARGET = "$ARGUMENTS"  # Full argument string, e.g., "backend/app/services/auth.py"
# $ARGUMENTS[0] is the first token (CC 2.1.59 indexed access)

# Model override detection (CC 2.1.72)
MODEL_OVERRIDE = None
for token in "$ARGUMENTS".split():
    if token.startswith("--model="):
        MODEL_OVERRIDE = token.split("=", 1)[1]  # "opus", "sonnet", "haiku", "fable"
        TARGET = TARGET.replace(token, "").strip()

MODEL_OVERRIDE が設定されている場合は、すべての Agent() 呼び出しに model=MODEL_OVERRIDE として渡してください。CC 2.1.74 に従い、シンボル名（opus、sonnet、haiku、Agent ツールに表示されるハーネスでは fable。なお、fable は 2026-07-12 以降、プレミアム API の料金が発生します）または完全な ID（claude-opus-5-5）を指定できます。

/model で Opus に切り替える場合（CC 2.1.144+）： /model で変更されるのは現在のセッションのモデルのみになったため、評価の実行に Opus を選んでも、その後のセッションには引き継がれません。新しいセッションのデフォルトを設定する場合に限り、ピッカーで d を押してください。

労力レベルの検出（CC 2.1.120+）

主なシグナルは $CLAUDE_EFFORT です。CC 2.1.120 では、/effort またはモデルピッカーからこの環境変数が設定されます。$ARGUMENTS 内の --effort= トークンは、明示的な上書きのフォールバックです（古い CC にも対応します）。

# Read env first (CC 2.1.120+), then check explicit override
EFFORT = os.environ.get("CLAUDE_EFFORT")  # "low" | "medium" | "high" | "xhigh" | None
for token in "$ARGUMENTS".split():
    if token.startswith("--effort="):
        EFFORT = token.split("=", 1)[1]   # explicit override wins
        TARGET = TARGET.replace(token, "").strip()
EFFORT = EFFORT or "high"  # default when CC < 2.1.120 and no flag

EFFORT を使用して、寸法の数、エージェントの数、および任意の xhigh 不確実性パスを制御してください。上記の「労力レベル」表を参照してください。CC < 2.1.120 では環境変数が設定されないため、明示的な --effort= 上書きのみが使用できます。doctor のカテゴリ 14 では、対応していないことが確実な xhigh のリクエストが報告されます。

---

ステップ -1：MCP プローブ + 再開チェック

読み込み：Read("../chain-patterns/references/mcp-detection.md")

# 1. Probe MCP servers (once at skill start)
# memory is alwaysLoad in .mcp.json (CC 2.1.121+, #1541) — probe below kept as fallback for older CC:
ToolSearch(query="select:mcp__memory__search_nodes")

# 2. Store capabilities
Write(".claude/chain/capabilities.json", {
  "memory": probe_memory.found,
  "skill": "assess",
  "timestamp": now()
})

# 3. Check for resume
state = Read(".claude/chain/state.json")  # may not exist
if state.skill == "assess" and state.status == "in_progress":
    last_handoff = Read(f".claude/chain/{state.last_handoff}")

フェーズ間の引き継ぎ

フェーズ	引き継ぎファイル	内容
0	00-intent.json	寸法、対象、モード
1	01-baseline.json	初期コードベーススキャンの結果
2	02-evaluation.json	寸法ごとのスコアと根拠
3	03-report.json	最終レポート、評価、推奨事項

---

ステップ 0：AskUserQuestion でユーザーの意図を確認する

タスクを作成する前に、評価する寸法を明確にしてください。

AskUserQuestion(
  questions=[{
    "question": "What dimensions to assess?",
    "header": "Dimensions",
    "options": [
      {"label": "Full assessment (Recommended)", "description": "All dimensions: quality, maintainability, security, performance"},
      {"label": "Code quality only", "description": "Readability, complexity, best practices"},
      {"label": "Security focus", "description": "Vulnerabilities, attack surface, compliance"},
      {"label": "Quick score", "description": "Just give me a 0-10 score with brief notes"}
    ],
    "multiSelect": false
  }]
)

回答に基づいてワークフローを調整します（focus としてフェーズ 2 に渡します）。

• 全体評価（full）：全 7 フェーズを実行し、並列エージェントを使用します。寸法の一部評価は労力レベルに応じて調整します
• コード品質のみ（quality）：セキュリティとパフォーマンスのフェーズを省略します
• セキュリティ重視（security）：セキュリティ監査エージェントを優先します
• クイックスコア（quick）：同じ Workflow 呼び出しで focus: quick を指定します。実行者は評価者を 1 人だけ実行し、簡潔な出力を返します

---

ステップ 0b：オーケストレーションモードを選択する

詳細は Read("references/orchestration-mode.md") を読み込んでください。環境変数の確認ロジック、Agent Teams と Agent Tool の比較、モードの選択ルールが記載されています。

---

🚨 タスク管理（CC 2.1.16）

# 1. Create main task IMMEDIATELY
TaskCreate(
  subject="Assess: {target}",
  description="Comprehensive evaluation with quality scores and recommendations",
  activeForm="Assessing {target}"
)

# 2. Create subtasks for each assessment phase
TaskCreate(subject="Understand target and gather context", activeForm="Understanding target")   # id=2
TaskCreate(subject="Discover scope and build file list", activeForm="Discovering scope")        # id=3
TaskCreate(subject="Rate quality across 6 dimensions", activeForm="Rating quality")             # id=4
TaskCreate(subject="Analyze pros and cons", activeForm="Analyzing pros/cons")                   # id=5
TaskCreate(subject="Compare alternatives", activeForm="Comparing alternatives")                 # id=6
TaskCreate(subject="Generate improvement suggestions", activeForm="Generating suggestions")     # id=7
TaskCreate(subject="Compile assessment report", activeForm="Compiling report")                  # id=8

# 3. Set dependencies for sequential phases
TaskUpdate(taskId="3", addBlockedBy=["2"])  # Scope needs target understanding
TaskUpdate(taskId="4", addBlockedBy=["3"])  # Rating needs scoped file list
TaskUpdate(taskId="5", addBlockedBy=["4"])  # Pros/cons needs quality scores
TaskUpdate(taskId="6", addBlockedBy=["4"])  # Alternatives need quality scores
TaskUpdate(taskId="7", addBlockedBy=["5", "6"])  # Suggestions need analysis
TaskUpdate(taskId="8", addBlockedBy=["7"])  # Report needs suggestions

# 4. Update status as you progress
TaskUpdate(taskId="2", status="in_progress")  # When starting
TaskUpdate(taskId="2", status="completed")    # When done — repeat for each subtask

---

🔄 ワークフローの概要

フェーズ	アクティビティ	出力
1. 対象の把握	コード／設計を読み、範囲を特定する	コンテキストの要約
1.5. スコープの特定	範囲を限定したファイルリストを作成する	スコープ内のファイルリスト
2. 品質評価	6つの次元で採点する（0～10）	根拠を添えたスコア
3. 長所／短所の分析	強みと弱みを特定する	バランスの取れた評価
4. 代替案の比較	代替案を採点する	比較マトリクス
5. 改善案の提案	実行可能な提案を行う	優先順位付きリスト
6. 工数の見積もり	時間と複雑さを見積もる	工数の内訳
7. 評価レポート	調査結果をまとめる	最終レポート

---

フェーズ 1：対象の把握

評価対象を特定し、コンテキストを収集します。ここでの TARGET はステップ 0 ですでに解決された値であり、ユーザーが入力した内容と必ずしも同じではありません。

# PARALLEL - Gather context
Read(file_path=TARGET)                                   # only when TARGET is a path
Grep(pattern=TARGET, output_mode="files_with_matches")   # topic or symbol
mcp__memory__search_nodes(query=TARGET)                  # past decisions

Read が失敗しても、処理を中止する理由にはなりません。会話から解決された対象は、通常ファイル名ではなく対象そのもの（「3 つの pretool ガード」「今日のフック修正」など）なので、Read で見つからなくても、Grep と会話からコンテキストを把握できます。Read の失敗は「これはパスではなくトピックである」と捉え、実際のファイルリストはフェーズ 1.5 で特定されるため、そのままフェーズ 1.5 に進んでください。

---

フェーズ 1.5：スコープの特定

ファイルの特定、制限の適用（最大 30 ファイル）、サンプリング優先順位のロジックの詳細については、Read("references/scope-discovery.md") を読み込んでください。すべてのエージェントプロンプトに、スコープ内のファイルリストを必ず含めてください。

段階的な出力（CC 2.1.76）

各評価フェーズが完了するたびに、結果を段階的に出力します。

フェーズ完了後	ユーザーに表示する内容
1. 対象の把握	スコープの要約、ファイルリスト、コンテキスト
1.5. スコープの特定	範囲を限定したファイルリスト（最大 30 ファイル）
2. 品質評価	評価エージェントから返される各次元のスコア
3. 長所／短所	バランスの取れた評価の要約

フェーズ 2 のワークフローは 1 回だけ返るため、その結果に含まれるすべての次元のスコアを表示し、priorityConcerns（4/10 未満の次元）を、ユーザーの注意が必要な懸念事項として最初に提示してください。エージェントごとのストリーミングは、Agent ツールへのフォールバック時にのみ適用されます。

---

フェーズ 2：品質評価（6 つの次元）

各次元を 0～10 で評価し、加重複合スコアを算出します。次元、重み、グレードの解釈、次元ごとの評価基準については、Read("../quality-gates/references/unified-scoring-framework.md") を読み込んでください。評価固有の上書き設定については、Read("references/quality-model.md") を読み込んでください。

評価担当者を独自に作らないでください。フェーズ 2 と 2.5 を担当する executor を実行してください。

result = Workflow(
  scriptPath="${CLAUDE_SKILL_DIR}/workflows/assess-fanout.js",
  args={"target": TARGET, "effort": EFFORT, "focus": FOCUS,   # FOCUS from STEP 0
        "mode": "comparison" if COMPARING else "default",     # quality-model.md
        "domain": "frontend" or "backend",                     # picks the performance engineer
        "scopeFiles": SCOPE_FILES,                             # Phase 1.5 list
        "projectContext": MEMORY_CONTEXT,                      # Phase 1 memory search
        "rubric": Read("rubric.json"), "modelOverride": MODEL_OVERRIDE,
        "feature": FEATURE})
Write(".claude/chain/02-evaluation.json", result)

スクリプトが担うのは処理の仕組みであり、文章ではありません。 スクリプトは focus と effort（セキュリティを優先）から評価担当者を選び、file:line の根拠を必須とするスコアスキーマを各担当者に提示し、判断を伴うすべてのスコアをブラインド反証担当者に送信して（フェーズ 2.5）、加重複合スコア、グレード、ルーブリックの判定、ブロッカーを算出します。file:line の根拠がないスコアは未採点として扱われ、同じ次元が繰り返された場合は最初の項目だけが残ります。また、選択された次元に min_blocker があるのに誰も採点しなかった場合、その次元はブロッカーになります。スクリプトは composite、grade、verdict、blockers（生成時点の根拠）、postRefutation、chainVerdict、chainVerdictIfConfirmed、revisions、confirmationNeeded、manualReview、advisory、priorityConcerns、quickWins、unscored、rejectedDimensions、unassessed、dimensions、ledger、reasons を返します。質問も書き込みも行いません。それらはこのシェル側で行います。

フォールバック（Workflow ツールがない場合、ORCHESTKIT_FORCE_TASK_TOOL=1 の場合、または下記のクロスモデルレーンの場合）：Agent ツールと Agent Teams の起動については Read("references/agent-spawn-definitions.md") を読み込み、その後、フェーズ 2.5 を手動で実行してください。

ファンアウトのルール： 選択された focus でフェーズ 2 を実行する場合、単一のパスだけで済ませることはフォールバックになりません。フェーズ 2 は Workflow 呼び出し、または Agent ツールへのフォールバックを通じて実行します。どちらも評価担当者を起動しない場合は、実行を BLOCKED として終了し、その理由を伝えてください。

複合スコア： 採点済みの次元の加重平均（quality-model.md を参照）。

Phase 2.5: 敵対的反証（労力ゲートあり）

各評価軸を採点する評価者は、その評価軸の唯一の判定者でもあり、自己優遇バイアスが生じます。独立したブラインド反証者が、判定に関わる各スコアについて独自の評価帯を設定します。労力ゲート： low／medium では省略し、high では単独で助言を行う反証者を最大 4 人まで実行します（自動変更なし）。xhigh では反証者 3 人による多数決を実行し、評価帯の近い端まで改訂します。Workflow の経路ではスクリプトがすでに実行しているため、シェルで完了させます。

1. 返された ledger を .claude/chain/02b-refutation.json に書き込みます（engine section 10）。
2. revisions 内で引用されているすべての file:line を再度開きます（engine section 3）。引用が根拠として成立しない場合、その評価軸を元の評価者のスコアに戻し、返された weights で総合スコアを再計算します。
3. confirmationNeeded が空でない場合は、chainVerdictIfConfirmed を使う前に AskUserQuestion を実行します。空の場合は chainVerdict を使います。反証だけでスコアが上がることも、不合格が合格に変わることもありません（engine section 7）。
4. manualReview の評価軸は「独立した反証なし」として一覧にし、high ではすべての助言による覆しを提示します。

プロトコルと評価者のバインディングについては、Read("references/adversarial-refutation.md") を参照してください（共有エンジン ../../shared/rules/adversarial-refutation.md を読み込みます）。評価者の指摘事項は、スコアや判定に反映する前に、まず証拠再確認ゲートを通過する必要があります。Read("../../shared/rules/evidence-replay.md") を参照してください。

クロスモデル反証者（任意、出所を明示、コスト制限あり）

ORK_ALT_MODEL_CMD が設定されていて、労力が high／xhigh の場合、重みの大きい評価軸または境界付近の評価軸ごとに、定足数の枠 1 つを Claude 以外のモデル（Codex/GPT）に割り当てて、多様な失敗パターンを検出できます。デフォルトでは無効です。同じモデルの枠 1 つと置き換わり、出所を示す refuter_model が記録されます。グレードを暗黙に引き上げることはできず（engine §7）、認証情報や外部送信先の管理も行いません（ORK_ALT_MODEL_CMD 経由でシェルを実行し、外部送信ガード #2533 に準拠します）。コマンドがない場合は、同じモデルにフォールバックします。レビュー PR の運用ドキュメントを共有します。Read("../review-pr/references/cross-model-refuter.md") を参照してください。

Workflow ではこの経路を実行しません（スクリプトからシェルを実行できないため）。ユーザーがこれを希望する場合は、Phase 2 の前に Agent ツールのフォールバックを選び、そこで Phases 2 と 2.5 を実行してください。

反証者は必ず、team_name を指定せず、評価軸と対象範囲内のファイルだけを渡して、隔離された状態で起動します。評価者のスコア、身元、文章は渡しません。評価者が付けた根拠ベースのスコアと、ラベルを付けた反証後のスコアを両方残してください。

---

Phases 3-7: 分析、比較、レポート

メリット／デメリット、代替案、改善点、工数、最終レポートの出力テンプレートについては、Read("references/phase-templates.md") を読み込んでください。

こちらも参照：Read("references/alternative-analysis.md") | Read("references/improvement-prioritization.md")

---

フェーズ 7b：ダッシュボード仕様の出力（json-render）

$ARGUMENTS から --render= を解析します。デフォルトは both です。

モード	動作
markdown	現在の動作。Markdown の評価レポートのみを出力します。仕様は出力しません。
json-render	.claude/chain/assess-dashboard.json のみを出力します。Markdown レポートはスキップします。
both	仕様と Markdown の両方を出力します。デフォルトです。人間はレポートを読み、後続のスキルは仕様を解析します。

仕様を出力する場合：

1. フォーマットとカタログを読み込みます：Read("references/dashboard-spec.md")。例：references/dashboard-example.json。
2. カタログの型のみを使用して仕様を構築します：Card、StatGrid、DataTable、StatusBadge、BarMeter、Markdown。評価仕様では、トップレベルのフィールド composite（数値）と grade（文字列）が必須です。
3. スコアが付けられた各ディメンションにつき BarMeter を 1 つ使用します。verdict 要素は StatusBadge とし、成績に応じてステータスを success／warning／error に割り当てます（A／B → success、C → warning、D／F → error）。
4. コンパクトな JSON で .claude/chain/assess-dashboard.json に書き込みます。
5. 成功を宣言する前に検証します：

node "${CLAUDE_SKILL_DIR}/scripts/render-spec.mjs" .claude/chain/assess-dashboard.json --check

検証に失敗した場合は Markdown のみの出力に切り替え、エラーを明示します。不完全な仕様は決して書き込みません。

6. --render=both の場合、仕様から Markdown ビューをレンダリングします：

node "${CLAUDE_SKILL_DIR}/scripts/render-spec.mjs" .claude/chain/assess-dashboard.json

これにより、JSON 仕様と Markdown レポートの同期が保たれます。

xhigh の場合： effort=xhigh が有効な場合、不確実性の確認から得られた confidence と caveats を含む Markdown 要素を、各ディメンションに対応する兄弟要素として追加します。dimensions の Card の子要素として、BarMeter とともに参照してください。正確なパターンについては references/dashboard-spec.md を参照してください。

後続処理での利用： implement は .claude/chain/assess-dashboard.json を読み込み、Markdown テーブルを解析せずに、スコアが最も低いディメンションと優先度の高い改善点（effort ≤ 2 AND impact ≥ 4）を取得します。実測値：評価仕様は約 830 トークン、同じ内容の Markdown は約 3500 トークンです。

---

フェーズ 7c：メモリへの書き戻し（シグナル発生時、任意）

評価に総合スコアが付いた場合、スコアと要約を型付きエンティティとしてメモリ MCP ナレッジグラフに任意で保存できます。将来の memory クエリで、評価の履歴を参照できます（このコードベースはテスト容易性でどの判断に 9/10 のスコアを付けたか？ セキュリティが 7.0 を下回ったのはいつか？）。

python3 ${CLAUDE_SKILL_DIR}/scripts/memory_writeback.py "<assessment-dir>"

<assessment-dir> は assessment.json を含むディレクトリです（通常はセッションの .claude/chain/）。スクリプトは、そのディレクトリ内に引き継ぎ用の memory-writeback.json を書き込みます。

自動スキップ条件（すべて終了コード 0 で終了し、すべて WARN としてログに記録されます）：

スキップ理由	発生条件
no composite score	assessment.json にトップレベルの数値フィールド composite がない
yg-mcp-core not importable	yg-mcp-core>=0.3.0 がインストールされていない（orchestkit は公開されていますが、yg-mcp-core は非公開の pypi.yonyon.ai にあります。HQ 専用です）
memory MCP unreachable	memory MCP サーバーが停止している、または .mcp.json に memory の定義がない

作成されるエンティティには、以下が含まれます。

• name：<slug-or-dir>@<timestamp>（再実行しても安定します。再実行のたびに新しいエンティティが作成されます）
• entityType：assessment（--entity-type <type> で上書きできます）
• observations：composite=X.XX、スコアが付いた各ディメンションにつき 1 つの <dim>=X.XX、任意の summary: ... と topic: ...

Yonatan-HQ/hq-ext-plugin#194（audio_podcast ハンドラー）と orchestkit#1886（post-synthesis podcast）のパターンを踏襲しています。Yonatan-HQ/core#993（yg-mcp-core 0.3.0）によりブロックが解除されました。

---

フェーズ 7d：チェーンの判定を出力する（停止ゲート）

合成スコアとグレードが確定した後（反論フェーズ 2.5 の後）、必ず機械可読な判定を書き込みます。これは、フェーズ 1 の前に implement が読み取る停止ゲートです。ワークフローパスでは、返される chainVerdict（またはフェーズ 2.5 で「はい」となった後の chainVerdictIfConfirmed）です。フェーズ 7b の仕様出力パターンに従い、コンパクトな JSON を書き込み、部分的なファイルは決して書き込みません。

// .claude/chain/assess-verdict.json
{
  "rubric": "ork-rubric/1.0",
  "skill": "assess",
  "verdict": "fail",
  "composite": 5.1,
  "dimension_scores": {"correctness": 7.0, "maintainability": 6.5, "performance": 5.5, "security": 3.2, "scalability": 6.0, "testability": 4.8, "compliance": 6.2},
  "blockers": [
    {"dimension": "security", "score": 3.2, "reason": "Unparameterized SQL in auth path (src/api/auth.ts:42)"}
  ],
  "feature": "<assessment topic, e.g. first non-flag token of $ARGUMENTS>"
}

判定ルール — 閾値は rubric.json（スキーマ：../../shared/rubric.schema.json）から取得します。

• composite < min_pass（5.5）の場合、または いずれかの次元のスコアがその min_blocker を下回る場合、verdict = "fail" とします。それ以外は "pass" です。
• min_blocker を下回る各次元について、blockers[] に項目を追加します。項目には次元、スコア、証拠に基づく理由を 1 つ記載します。合格時の blockers は [] です。
• スコアは反論後の数値、つまりレポートに記載されるものと同じです。反論によって不合格が暗黙に合格へ変わることはありません。

利用側：implement のステップ -0.5 では、verdict == "fail" の場合、フェーズ 1 をブロックします（ユーザーは先に修正するか、明示的にオーバーライドする必要があります）。フェーズ 7c のメモリ書き戻しでは、判定と各次元のスコアをメモリグラフに保存し（verdict=pass|fail の観察事項を追加）、セッションをまたいだ学習に利用します。

---

自己申告による不確実性（xhigh の労力レベル）

現世代のモデルは、以前の世代よりも自身の限界をはるかに正確に報告できます。xhigh の労力レベルが有効な場合は、各次元の評価に confidence レベルと caveats のリストを追加します。ここには、モデルが検証できなかったこと、依拠した前提、テストしていないケースを記載します。

次元ごとの出力スキーマ（JSON）：

{
  "dimension": "security",
  "score": 7.2,
  "confidence": "medium",              // "low" | "medium" | "high"
  "caveats": [
    "Didn't execute the SQL queries against a real DB to confirm parameterization",
    "Assumed NODE_ENV=production in deployment; didn't verify CI config",
    "Reviewed 12 of 15 handlers; remaining 3 deferred by scope filter"
  ],
  "evidence": ["src/api/auth.ts:42", "src/middleware/guard.ts:88"]
}

ルール：

• confidence を自動ゲートとして使用しないでください。 これは人間の読者に向けた指標であり、合否の閾値ではありません。
• caveats は具体的に記載してください。 「セキュリティに不確実性がある」よりも、ファイルパスを含む「X を確認していない」のほうが適切です。
• 解決に手間がかからない注意事項は、記録するのではなく解決してください。 注意事項は、スキルの範囲内では本当に検証できない事柄（本番環境での実行時の挙動や、将来の入力パターンなど）に使用します。
• 合成スコアは引き続き score のみから算出し、confidence による重み付けはしません。 これにより、実行間で数値を比較可能な状態に保ちます。

---

💡 グレードの解釈

グレードの閾値とスコアリング基準については、Read("../quality-gates/references/unified-scoring-framework.md") を読み込んでください。

---

重要な決定事項

決定事項	選択	根拠
6 つの次元	包括的な網羅性	圧倒的にならず、すべての品質面を評価できます
0～10 の尺度	業界標準	理解しやすく、比較も容易です
並列評価	workflows/assess-fanout.js、最大 4 人の評価者	スコア、反論、判定を散文ではなくコードで保持します
労力／影響のスコアリング	1～5 の尺度	シンプルな優先順位付けの計算です

---

ルールのクイックリファレンス

ルール	影響	対象範囲
complexity-metrics（rules/complexity-metrics.md を読み込む）	高	7 項目の基準によるスコアリング（1～5）、複雑さのレベル、閾値
complexity-breakdown（rules/complexity-breakdown.md を読み込む）	高	タスク分解の戦略、リスク評価

品質基準

以下のすべてを満たした場合に完了です。

• 対象範囲内のすべての次元を、雰囲気ではなく証拠（ファイル：行）に基づいて 0～10 でスコアリングしている
• 合成スコアが採点済みの次元の加重平均であり、その合成スコアに基づいてグレードが決まる
• 労力レベルが high／xhigh の場合、意思決定に関わるスコアは、合成スコアに含める前に敵対的反論レーンを通過している
• .claude/chain/assess-verdict.json に合否の判定が書き込まれ、min_blocker を下回るすべての次元について blockers[] の項目がある
• 4/10 未満の次元は、優先的な懸念事項として直ちにフラグ付けされている
• json-render 仕様が出力された場合、render-spec.mjs --check に合格し、必須の composite および grade フィールドを含んでいる

📜 関連スキル

• ork:verify - 実装後の検証
• ork:code-review-playbook - コードレビューのパターン
• ork:quality-gates - タスクの複雑さの評価、ゲートのパターン

---

バージョン： 1.9.0（2026年9月）：フェーズ2と2.5はワークフロースクリプト（workflows/assess-fanout.js）として実行されます