review-hog-authoring

PostHog Review スキルの作成

PostHog Review は、PostHog の自動 PR レビュアーです。レビューでは PR を複数のチャンクに分割し、各チャンクに対して、有効になっているすべての観点（それぞれ独立した専門家の視点）を並列で実行します。その後、盲点チェックを 1 回実行します（観点で見つかった内容を踏まえた最終確認）。最後に、残ったすべての候補指摘を 1 つの検証基準スキルに照らして判定し、合格した指摘だけをプルリクエストに公開します。レビューの公開後、解決ステージでは PR の未解決のレビューコメントを再確認し、それぞれを 1 つの解決基準スキルに照らして判定します。価値があり安全な依頼は PR ブランチに実装し、すべてのコメントに返信します。

4 種類はいずれもチームの LLMSkill 行であり、レビューエージェントは実行時に MCP 経由で取得します。PostHog は標準スキルを提供します。このスキルガイドではカスタムスキルの作成方法を説明します。このスキル自体はチームレベルですが、_実行するかどうか_はユーザーごとの設定で、Inbox → Code review から変更できます。

種類	名前の規則	ユーザーごとの設定数	標準例
レビューの観点	review-hog-perspective-<slug>	複数を有効化でき、少なくとも 1 つは有効のままにする	review-hog-perspective-logic-correctness
盲点チェック	review-hog-blind-spots-<slug>	常に 1 つだけ有効。選択すると入れ替わる	review-hog-blind-spots-general
検証基準	review-hog-validation-<slug>	常に 1 つだけ有効。選択すると入れ替わる	review-hog-validation-criteria
解決基準	review-hog-resolution-<slug>	常に 1 つだけ有効。選択すると入れ替わる	review-hog-resolution-criteria

作成の流れ

1. 前提を把握します。 PostHog MCP のスキルツールを使って、チームの review-hog-* スキルを skill-list で一覧表示し、作成する種類の標準スキル（上の表を参照）を skill-get で取得します。構成と文体の参考にしてください。新しい視点が、すでに有効な視点の担当範囲を重複して扱わないよう、既存の review-hog-perspective-* の説明にも一通り目を通します（重複は後で除去されますが、レビューの手間が増えます）。
2. ユーザーにヒアリングします。 スキルで何に焦点を当てるべきかを尋ね、現在のスキルセットがまだ扱っていない具体的な方向性をいくつか提案します。手順1で確認した内容と、役立つ場合はプロジェクト自体の情報を踏まえてください。方向性が決まるまでは書き始めないでください。
3. 本文を作成します。 以下の種類ごとのガイダンスに従ってください。レビューエージェントが1つのチャンクに対して1回で適用できる、焦点を絞った指示セットにします。エッセイにはしないでください。
4. posthog:skill-create を使って、自分でスキルを作成します。 チームの LLMSkill 行を実際に作成してください。ユーザーがコピー＆ペーストできる本文を渡すだけではいけません。上記の契約に従った正確な名前（小文字のスラッグ）、レンズ／スイープ／バーの内容を1段落で説明する description、および本文を渡します。名前のプレフィックスが、そのスキルのアイデンティティ全体です。 コードレビューダブとレビュー実行は、このプレフィックスを使ってスキルを検出します。スキルツールに category パラメーターはなく、設定する必要もありません。バックエンドが review_hog グルーピングカテゴリを付与します（これはスキルページでのグループ分けにのみ影響します）。設定や確認に時間をかけないでください。変更を希望された場合は、posthog:skill-update で更新します。新規に作成してください。標準スキルを複製して編集する skill-duplicate は使わないでください。複製するとシード済みメタデータも引き継がれ、標準スキルとの同期によって上書きまたは削除される可能性があります。
5. 有効化の方法をユーザーに伝えます。 カスタムスキルは、ユーザーにとって最初は無効になっています。
   • 視点 — Inbox → Code review → Perspectives でオンにします。有効にするまでは無効状態で表示されます。少なくとも1つの視点を有効にしておく必要があります。
   • ブラインドスポットチェック／検証基準／解決基準 — 該当するセクションで選択します。一度に実行できるのは1つだけなので、選択すると現在のものと入れ替わります。対象となるのは、そのユーザーのレビューのみです。 レビューでは実行開始時にスキルのバージョンが固定されるため、レビュー中に編集した場合、変更が適用されるのは次回の実行からです。

レビュー視点の作成

本文では、1つのPRチャンクに対して、1人の専門家が1回レビューするよう指示します。標準のロジック正確性スキルと同じ構成にします。

• 担当範囲 — このレンズが担当する領域を1文で示します。担当範囲内のすべてを報告し、それ以外は他の視点に委ねます。
• 確認箇所 — 具体的な確認項目をいくつか番号付きで示します。それぞれ、チャンクに対してエージェントが実行できる具体的なチェックにしてください（「一緒に反映されるべき書き込みを分割してしまうトランザクション境界」など）。抽象的な美徳（「正確性を確保する」など）にはしないでください。
• 担当範囲の境界 — このレンズが触れず、隣接する懸念事項を担当する視点を示します。
• 指摘の基準 — 公開に値する指摘では、具体的な発生条件と具体的な結果を明示します。最後に完了基準を記します（「変更されたすべてのファイルについて、確認箇所のそれぞれに照らして問題を指摘するか、問題なしと判断できたら完了」など）。

レビュー用ハーネスは、パイプラインの仕組み（並列での視点レビュー、後段での重複除去、重大度レベル、テスト対象外ファイルのルール）をすでにエージェントに伝えています。そのため、スキルにはレンズの内容だけを記載してください。ハーネスのルールを繰り返すと、焦点が薄れます。

ブラインドスポットチェックの記述

本文では、有効化されたすべての視点が各チャンクの確認を終えた後に実行される最終チェックを指示します。 対象となった指摘に応じて内容が変わる（プロンプトには、どの視点が実行され、何を見つけたかが列挙されます）ため、その情報の活用方法を本文で示します。対象となった指摘から、すでにどこに注意が向けられたかが分かるので、チェックではその空白、つまりエラーパス、未処理の入力、ファイル間の相互作用、前提条件に価値があります。特定の専門分野に限定せず、無理に指摘を水増しするより、結果が空であるほうが望ましいです。カスタムチェックでは、この探索範囲を絞ったり、重み付けを変えたりできます（たとえば、チームが繰り返し問題に悩まされている領域を重点的に調べます）。

検証基準の記述

本文では、各指摘候補を公開前に評価する際の採用・却下の基準を定めます。組織のデフォルトは再現率より精度を重視する方針です。ノイズを増やすレビュアーはミュートされるため、指摘が実在し、作者の注意を引く価値があると判断する条件（ユーザーに影響する正確性、セキュリティ、データ損失、契約違反、パフォーマンス）、却下する内容（過剰設計、憶測、過剰な防御、到達不能なエッジケース、スタイル）、そして真に不確かな場合の扱い（デフォルトでは却下）を定義します。カスタム基準では厳格さを変えたり、重視する懸念事項を調整したりできますが、感覚ではなく、実際のコードベースからの根拠を引き続き求める必要があります。

解決基準の記述

本文では、PR 上の未解決のレビューコメントごとに、解決ステージが適用する基準を定めます。すなわち、実装する価値があること（実際の改善であり、変更内容の範囲内で PR に含めるべきもの）と、人の介入なしに安全に実装できること（影響範囲が小さく、契約や API を変更せず、横断的な書き換えもなく、ローカルで検証できること）です。実装する内容、理由を示して却下する内容（過剰設計の要求、スコープの拡大、スタイルだけの変更、フォローアップで対応するほうが適切な要求）、そして人間にエスカレーションする内容を定義します。ハーネスには譲れない最低基準があります。人間が作成したコメントをボットが解決することはなく、エスカレーションによってコメントが解決されることもなく、返信では常に判断の理由を説明します。そのため、カスタムスキルでは基準を厳しくしたり、何を価値あるものとみなすかの重み付けを変えたりできますが、これらの最低基準を緩めることはできません。