公式一次情報を最優先する

なぜこのスキルがあるか

検索結果の要約と体験談で結論し、公式の文言を自分で読まなかった。 公式は明確に否定していたのに「可能」と伝え、費用と時間のかかる手続きへ誘導した。 別のケースでは、公式に無料の正規手順があったのに、有料の方法を前提に検討を進めた。

共通構造はユーザーに「公式が何と言っているか」が見えないまま判断させたこと。 技術情報の裏取り規約（CLAUDE.md）を、制度・手続きへ明示的に広げたものがこのスキル。

適用トリガー

• ストアの審査基準・提出要件
• アカウントの登録・種別変更・削除
• サブスクの契約・解約・返金・価格
• 外部サービスの利用規約・料金プラン・無料枠の条件
• 税務・法務・行政の手続き
• 「〜できますか」「〜は必要ですか」という可否の問い
• 費用が発生する手順や不可逆な手続きを提案するとき

鉄則

1. 公式の文言を自分で読むまで結論を出さない

検索結果の要約で結論しない。該当ページを実際に開く。開けなかったら**「確認できていない」と明言する**（記憶で補完しない）。

2. 出典の階層を守る

順位	出典	扱い
1	公式ドキュメント・利用規約・料金ページ	これだけが結論の根拠になる
2	公式フォーラムでの運営者本人の回答	準一次情報。日付を確認する
3	公式のリリースノート・変更履歴	変更の有無を追うのに使う
4	技術ブログ・体験談・まとめ記事	裏取りと手順の参考のみ。結論の根拠にしない

3. 矛盾したら公式が勝つ

「通った実例がある」は根拠にならない。公式が否定しているなら、運用の揺れの可能性として扱い、計画の前提にはしない。

4. 「書かれていない」と「否定されている」を区別する

• 否定されている … やらない。代替案を出す
• 書かれていない … 「公式に明文が見当たらない」と明言し、確認方法（問い合わせ先・該当画面）を示す
• 明文が無いことを「できる」の根拠にしない

5. 無料の正規経路を先に探す

費用が発生する手順を提案する前に、公式に無料の方法が案内されていないか確認する。調査段階でも同じ（実行しなければよい、ではない）。

6. ユーザーに判断材料を渡す

要約で結論しない。公式の該当文を引用し、URLを示す。ユーザーが自分で検証できる状態にして初めて、判断を渡したことになる。

出力の型

### 結論
{可 / 不可 / 公式に明文なし}

### 公式の根拠
- {URL}
  > {該当箇所の引用}

### 体験談との差異（あれば）
{異なる主張がある場合、その事実と、公式を採る理由}

### 費用
{発生する / しない。無料の正規経路の有無}

### 確認できていないこと
{明文が見当たらない点。どこで確認できるか}

アンチパターン

• 検索スニペットだけで「〜できます」と断言する
• 個人ブログの成功例を一般化する
• 無料経路を確認せずに有料の手順を提案する
• 「公式に書かれていない」を「できる」と読み替える
• 公式ページを開けなかったことを黙って記憶で補完する
• 出典URLを示さずに結論だけ伝える

クロスチェック：別モデルに白紙で聞く

このスキルを守っても読み違えは残る。間違うと費用や時間が飛ぶ問いに限って、別モデルに同じ問いを投げて突き合わせる（判断軸は事後学習、クロスチェックは未知の失敗にも効く事前の網なので役割が違う）。

環境に別モデルCLIがあれば使う（例: codex が認証モード chatgpt なら追加課金なしで使える。Gemini CLI等も候補）。無い環境では省略してよい。

codex exec --ephemeral --sandbox read-only --skip-git-repo-check "<質問>"

設計上の鉄則

1. 自分の結論を先に伝えない。「こう結論したので検証して」は引きずられる。質問だけを白紙で投げる
2. プロジェクト固有の情報を送らない。外部サービスに渡るため、制度・規約の一般的な問いに切り出す。未公開の設計・個人情報を含めない
3. 出力形式を指定する（結論 / 公式URL＋原文引用 / 明文が無ければ「明文なし」と明言）
4. 答えが割れたら勝手に採らない。一致→確定してよい。不一致→どちらが正しいか自分で決めず、両方の根拠を並べてユーザーに見せる
5. 高リスクな問いにだけ使う（クォータを消費する）

補足

コード生成に最適化されたモデルは、制度・規約・料金のような「変わる情報」で古い知識が混ざりやすい。実装能力と制度の可否判断は別の能力として扱う。