winter-super-cli 2026.5.32 → 2026.6.6

package/resources/local/ecc/docs/ja-JP/skills/santa-method/SKILL.md

@@ -0,0 +1,306 @@
+---
+name: santa-method
+description: "収束ループを持つマルチエージェント敵対的検証。2つの独立したレビューエージェントが両方合格して初めて出力を出荷できます。"
+origin: "Ronald Skelton - Founder, RapportScore.ai"
+---
+
+# Santa Method
+
+マルチエージェント敵対的検証フレームワーク。リストを作り、二度確認する。問題があれば、良くなるまで修正する。
+
+核心的な洞察: 自分の出力をレビューする単一のエージェントは、その出力を生み出したのと同じバイアス、知識のギャップ、体系的なエラーを共有しています。共有コンテキストを持たない2人の独立したレビュアーは、この障害モードを解消します。
+
+## 起動するタイミング
+
+以下の場合にこのスキルを呼び出します:
+- 出力が公開、デプロイ、またはエンドユーザーに提供される場合
+- コンプライアンス、規制、またはブランドの制約が適用される必要がある場合
+- コードが人間のレビューなしに本番環境にデプロイされる場合
+- コンテンツの正確性が重要な場合（技術文書、教育資料、顧客向けコピー）
+- スポットチェックで体系的なパターンを見逃す可能性のある大規模バッチ生成
+- ハルシネーションリスクが高い場合（主張、統計、API リファレンス、法的言語）
+
+内部ドラフト、探索的調査、または確定的な検証がある場合（それらにはビルド/テスト/Lint パイプラインを使用）には使用しないでください。
+
+## アーキテクチャ
+
+```
+┌─────────────┐
+│  GENERATOR   │  フェーズ1: リストを作る
+│  (Agent A)   │  成果物を生成する
+└──────┬───────┘
+       │ output
+       ▼
+┌──────────────────────────────┐
+│     DUAL INDEPENDENT REVIEW   │  フェーズ2: 二度確認する
+│                                │
+│  ┌───────────┐ ┌───────────┐  │  2つのエージェント、同じルーブリック、
+│  │ Reviewer B │ │ Reviewer C │  │  共有コンテキストなし
+│  └─────┬─────┘ └─────┬─────┘  │
+│        │              │        │
+└────────┼──────────────┼────────┘
+         │              │
+         ▼              ▼
+┌──────────────────────────────┐
+│        VERDICT GATE           │  フェーズ3: 良いか悪いか
+│                                │
+│  B passes AND C passes → NICE  │  両方が合格する必要がある。
+│  Otherwise → NAUGHTY           │  例外なし。
+└──────┬──────────────┬─────────┘
+       │              │
+    NICE           NAUGHTY
+       │              │
+       ▼              ▼
+   [ SHIP ]    ┌─────────────┐
+               │  FIX CYCLE   │  フェーズ4: 良くなるまで修正
+               │              │
+               │ iteration++  │  全フラグを収集する。
+               │ if i > MAX:  │  全問題を修正する。
+               │   escalate   │  両レビュアーを再実行する。
+               │ else:        │  収束するまでループ。
+               │   goto Ph.2  │
+               └──────────────┘
+```
+
+## フェーズの詳細
+
+### フェーズ1: リストを作る（生成）
+
+主要タスクを実行します。通常の生成ワークフローに変更はありません。Santa Method は生成後の検証レイヤーであり、生成戦略ではありません。
+
+```python
+# ジェネレーターは通常通り実行される
+output = generate(task_spec)
+```
+
+### フェーズ2: 二度確認する（独立したデュアルレビュー）
+
+2つのレビューエージェントを並列で起動します。重要な不変条件:
+
+1. **コンテキスト分離** — どちらのレビュアーも相手の評価を見ない
+2. **同一ルーブリック** — 両方が同じ評価基準を受け取る
+3. **同じ入力** — 両方がオリジナルの仕様と生成された出力を受け取る
+4. **構造化出力** — それぞれが散文ではなく型付き判定を返す
+
+```python
+REVIEWER_PROMPT = """
+あなたは独立した品質レビュアーです。この出力に対する他のレビューは見ていません。
+
+## タスク仕様
+{task_spec}
+
+## レビュー対象の出力
+{output}
+
+## 評価ルーブリック
+{rubric}
+
+## 指示
+各ルーブリック基準に対して出力を評価してください。それぞれに対して:
+- PASS: 基準が完全に満たされ、問題なし
+- FAIL: 特定の問題が見つかった（正確な問題を引用）
+
+評価を構造化JSONとして返してください:
+{
+  "verdict": "PASS" | "FAIL",
+  "checks": [
+    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
+  ],
+  "critical_issues": ["..."],   // 修正が必要なブロッカー
+  "suggestions": ["..."]         // ブロックしない改善提案
+}
+
+厳格に評価してください。あなたの仕事は問題を見つけることであり、承認することではありません。
+"""
+```
+
+```python
+# レビュアーを並列で起動（Claude Code サブエージェント）
+review_b = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer B")
+review_c = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer C")
+
+# 両方が同時に実行される — 互いに見えない
+```
+
+### ルーブリックの設計
+
+ルーブリックは最も重要な入力です。曖昧なルーブリックは曖昧なレビューを生みます。すべての基準には客観的な合否条件が必要です。
+
+| 基準 | 合格条件 | 失敗シグナル |
+|-----------|---------------|----------------|
+| 事実の正確性 | すべての主張がソース資料または常識から検証可能 | 作り上げられた統計、誤ったバージョン番号、存在しないAPI |
+| ハルシネーションなし | 作り上げられたエンティティ、引用、URL、参照なし | 存在しないページへのリンク、出典のない引用 |
+| 完全性 | 仕様のすべての要件が対応されている | 欠落しているセクション、スキップされたエッジケース、不完全なカバレッジ |
+| コンプライアンス | すべてのプロジェクト固有の制約に合格 | 禁止語の使用、トーン違反、規制への非準拠 |
+| 内部一貫性 | 出力内に矛盾なし | セクションAがXと言い、セクションBがX以外と言う |
+| 技術的正確性 | コードがコンパイル/実行され、アルゴリズムが健全 | 構文エラー、ロジックのバグ、誤った計算量の主張 |
+
+#### ドメイン固有のルーブリック拡張
+
+**コンテンツ/マーケティング:**
+- ブランドボイスの遵守
+- SEO要件の充足（キーワード密度、メタタグ、構造）
+- 競合他社の商標の誤用なし
+- CTAが存在し正しくリンクされている
+
+**コード:**
+- 型安全性（`any` リークなし、適切なnull処理）
+- エラー処理のカバレッジ
+- セキュリティ（コードにシークレットなし、入力検証、インジェクション防止）
+- 新しいパスのテストカバレッジ
+
+**コンプライアンスが重要な場合（規制対象、法的、財務的）:**
+- 結果の保証や根拠のない主張なし
+- 必要な免責事項が存在する
+- 承認された用語のみ
+- 管轄区域に適した言語
+
+### フェーズ3: 良いか悪いかの判定（Verdict Gate）
+
+```python
+def santa_verdict(review_b, review_c):
+    """両方のレビュアーが合格する必要がある。部分的な評価なし。"""
+    if review_b.verdict == "PASS" and review_c.verdict == "PASS":
+        return "NICE"  # 出荷する
+
+    # 両方のレビュアーのフラグをマージし、重複を排除
+    all_issues = dedupe(review_b.critical_issues + review_c.critical_issues)
+    all_suggestions = dedupe(review_b.suggestions + review_c.suggestions)
+
+    return "NAUGHTY", all_issues, all_suggestions
+```
+
+両方が合格する必要がある理由: 1人のレビュアーだけが問題を検知した場合、その問題は実在します。もう1人のレビュアーのブラインドスポットこそ、Santa Method が解消しようとしている障害モードです。
+
+### フェーズ4: 良くなるまで修正する（収束ループ）
+
+```python
+MAX_ITERATIONS = 3
+
+for iteration in range(MAX_ITERATIONS):
+    verdict, issues, suggestions = santa_verdict(review_b, review_c)
+
+    if verdict == "NICE":
+        log_santa_result(output, iteration, "passed")
+        return ship(output)
+
+    # すべての重大な問題を修正する（提案はオプション）
+    output = fix_agent.execute(
+        output=output,
+        issues=issues,
+        instruction="フラグが立てられた問題のみを修正してください。リファクタリングや未要求の変更は行わないでください。"
+    )
+
+    # 修正した出力で両方のレビュアーを再実行する（新しいエージェント、前のラウンドの記憶なし）
+    review_b = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
+    review_c = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
+
+# イテレーション回数を超えた — エスカレート
+log_santa_result(output, MAX_ITERATIONS, "escalated")
+escalate_to_human(output, issues)
+```
+
+重要: 各レビューラウンドは**新鮮なエージェント**を使用します。レビュアーは前のラウンドの記憶を持ってはいけません。前のコンテキストはアンカリングバイアスを生み出すためです。
+
+## 実装パターン
+
+### パターンA: Claude Code サブエージェント（推奨）
+
+サブエージェントは真のコンテキスト分離を提供します。各レビュアーは共有状態を持たない別個のプロセスです。
+
+```bash
+# Claude Code セッションでエージェントツールを使用してレビュアーを起動する
+# 速度のために両エージェントを並列で実行する
+```
+
+```python
+# エージェントツール呼び出しの擬似コード
+reviewer_b = Agent(
+    description="Santa Review B",
+    prompt=f"この出力の品質をレビューしてください...\n\nルーブリック:\n{rubric}\n\n出力:\n{output}"
+)
+reviewer_c = Agent(
+    description="Santa Review C",
+    prompt=f"この出力の品質をレビューしてください...\n\nルーブリック:\n{rubric}\n\n出力:\n{output}"
+)
+```
+
+### パターンB: 逐次インライン（フォールバック）
+
+サブエージェントが利用できない場合、明示的なコンテキストリセットで分離をシミュレートします:
+
+1. 出力を生成する
+2. 新しいコンテキスト: 「あなたはレビュアー1です。このルーブリックのみに対して評価してください。問題を見つけてください。」
+3. 所見を逐語的に記録する
+4. コンテキストを完全にクリアする
+5. 新しいコンテキスト: 「あなたはレビュアー2です。このルーブリックのみに対して評価してください。問題を見つけてください。」
+6. 両方のレビューを比較し、修正して繰り返す
+
+サブエージェントパターンは厳密に優れています — インラインシミュレーションはレビュアー間のコンテキスト漏れのリスクがあります。
+
+### パターンC: バッチサンプリング
+
+大規模バッチ（100件以上）の場合、全アイテムへの完全な Santa 適用はコスト的に非現実的です。層別サンプリングを使用します:
+
+1. ランダムサンプルで Santa を実行（バッチの10〜15%、最低5件）
+2. 種類別に失敗を分類（ハルシネーション、コンプライアンス、完全性など）
+3. 体系的なパターンが現れた場合、バッチ全体に対象を絞った修正を適用
+4. 修正されたバッチを再サンプリングして再検証
+5. クリーンなサンプルが合格するまで継続
+
+```python
+import random
+
+def santa_batch(items, rubric, sample_rate=0.15):
+    sample = random.sample(items, max(5, int(len(items) * sample_rate)))
+
+    for item in sample:
+        result = santa_full(item, rubric)
+        if result.verdict == "NAUGHTY":
+            pattern = classify_failure(result.issues)
+            items = batch_fix(items, pattern)  # パターンに一致する全アイテムを修正
+            return santa_batch(items, rubric)   # 再サンプリング
+
+    return items  # クリーンなサンプル → バッチを出荷
+```
+
+## 障害モードと緩和策
+
+| 障害モード | 症状 | 緩和策 |
+|-------------|---------|------------|
+| 無限ループ | レビュアーが修正後に新しい問題を見つけ続ける | 最大イテレーション上限（3回）。エスカレートする。 |
+| スタンプ承認 | 両方のレビュアーがすべてを通す | 敵対的プロンプト: 「あなたの仕事は問題を見つけることであり、承認することではありません。」 |
+| 主観的ドリフト | レビュアーがエラーではなくスタイルの好みにフラグを立てる | 客観的な合否基準のみを持つ厳格なルーブリック |
+| 修正による退行 | 問題Aの修正が問題Bを引き起こす | ラウンドごとの新鮮なレビュアーが退行を検知 |
+| レビュアーの合意バイアス | 両方のレビュアーが同じことを見逃す | 独立性によって緩和されるが排除はされない。重要な出力には3人目のレビュアーか人間のスポットチェックを追加 |
+| コスト爆発 | 大規模出力に対して多すぎるイテレーション | バッチサンプリングパターン。検証サイクルあたりの予算上限。 |
+
+## 他のスキルとの統合
+
+| スキル | 関係 |
+|-------|-------------|
+| Verification Loop | 確定的なチェック（ビルド、Lint、テスト）に使用。Santa はセマンティックチェック（正確性、ハルシネーション）に使用。先に検証ループを実行し、その後 Santa を実行。 |
+| Eval ハーネス | Santa Method の結果がEval メトリクスに反映される。Santa の実行全体で pass@k を追跡して、経時的なジェネレーターの品質を測定。 |
+| Continuous Learning v2 | Santa の発見が本能になる。同じ基準での繰り返し失敗 → パターンを避ける学習された行動。 |
+| Strategic Compact | コンパクト前に Santa を実行する。検証途中でレビューコンテキストを失わない。 |
+
+## メトリクス
+
+Santa Method の効果を測定するためにこれらを追跡します:
+
+- **初回合格率**: ラウンド1で Santa を通過する出力の % （目標: >70%）
+- **収束までの平均イテレーション**: NICE になるまでの平均ラウンド数（目標: <1.5）
+- **問題の分類**: 失敗の種類の分布（ハルシネーション対完全性対コンプライアンス）
+- **レビュアー合意**: 両方のレビュアーがフラグを立てた問題 対 片方のみの % （低い合意 = ルーブリックの改善が必要）
+- **エスケープ率**: Santa が検知すべきだったが出荷後に見つかった問題（目標: 0）
+
+## コスト分析
+
+Santa Method は検証サイクルあたり、生成単体のトークンコストの約2〜3倍のコストがかかります。高リスクな出力のほとんどにとって、これは割安です:
+
+```
+Santa のコスト = (生成トークン) + 2×(ラウンドあたりのレビュートークン) × (平均ラウンド数)
+Santa を使わないコスト = (評判の損害) + (修正の労力) + (信頼の侵食)
+```
+
+バッチ操作では、サンプリングパターンにより、体系的な問題の>90%を検知しながら、完全な検証の約15〜20%のコストに削減されます。

package/resources/local/ecc/docs/ja-JP/skills/scientific-db-pubmed-database/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: pubmed-database
+description: 生物医学文献、MeSH クエリ、PMID 検索、引用取得、および API を利用した文献モニタリングのための PubMed および NCBI E-utilities の直接検索ワークフロー。
+origin: community
+---
+
+# PubMed Database
+
+一般的なウェブ検索ではなく PubMed から生物医学文献が必要なタスクにこのスキルを使用します。
+
+## 使用するタイミング
+
+- MEDLINE または生命科学文献の検索。
+- MeSH 用語、フィールドタグ、日付、または文献種別を使った PubMed クエリの構築。
+- PMID、アブストラクト、出版メタデータ、または関連引用の検索。
+- 再現可能な検索文字列が必要なシステマティックレビューの検索パスの実行。
+- Python、シェル、または別の HTTP クライアントから直接 NCBI E-utilities を使用。
+
+## クエリの構築
+
+研究質問から始め、概念に分割し、ブール演算子で概念を組み合わせます。
+
+```text
+concept_1 AND concept_2 AND filter
+synonym_a OR synonym_b
+NOT exclusion_term
+```
+
+有用な PubMed フィールドタグ:
+
+- `[ti]`: タイトル
+- `[ab]`: アブストラクト
+- `[tiab]`: タイトルまたはアブストラクト
+- `[au]`: 著者
+- `[ta]`: 雑誌タイトル略語
+- `[mh]`: MeSH 用語
+- `[majr]`: 主要 MeSH トピック
+- `[pt]`: 出版種別
+- `[dp]`: 出版日
+- `[la]`: 言語
+
+例:
+
+```text
+diabetes mellitus[mh] AND treatment[tiab] AND systematic review[pt] AND 2023:2026[dp]
+(metformin[nm] OR insulin[nm]) AND diabetes mellitus, type 2[mh] AND randomized controlled trial[pt]
+smith ja[au] AND cancer[tiab] AND 2026[dp] AND english[la]
+```
+
+## MeSH とサブヘッディング
+
+概念が安定した統制語彙用語を持つ場合は MeSH を優先します。トピックが新しいまたは用語が多様な場合は MeSH とタイトル/アブストラクト用語を組み合わせます。
+
+正しいサブヘッディング構文では、サブヘッディングをフィールドタグの前に置きます:
+
+```text
+diabetes mellitus, type 2/drug therapy[mh]
+cardiovascular diseases/prevention & control[mh]
+```
+
+`[majr]` は論文の中心的なトピックである必要がある場合にのみ使用します。精度は向上しますが、関連する研究を見逃す可能性があります。
+
+## フィルター
+
+出版種別:
+
+- `clinical trial[pt]`
+- `meta-analysis[pt]`
+- `randomized controlled trial[pt]`
+- `review[pt]`
+- `systematic review[pt]`
+- `guideline[pt]`
+
+日付フィルター:
+
+```text
+2026[dp]
+2020:2026[dp]
+2026/03/15[dp]
+```
+
+利用可能性フィルター:
+
+```text
+free full text[sb]
+hasabstract[text]
+```
+
+## E-utilities ワークフロー
+
+NCBI E-utilities は再現可能な API ワークフローをサポートします:
+
+1. `esearch.fcgi`: 検索して PMID を返す。
+2. `esummary.fcgi`: 軽量な記事メタデータを返す。
+3. `efetch.fcgi`: XML、MEDLINE、またはテキストでアブストラクトまたはフルレコードを取得。
+4. `elink.fcgi`: 関連記事とリンクされたリソースを検索。
+
+本番スクリプトにはメールアドレスと API キーを使用します。API キーは環境変数に保存し、コミットされたファイルやコマンド履歴には絶対に入れないでください。
+
+```python
+import os
+import time
+import requests
+
+BASE = "https://eutils.ncbi.nlm.nih.gov/entrez/eutils"
+
+
+def esearch(query: str, retmax: int = 20) -> list[str]:
+    params = {
+        "db": "pubmed",
+        "term": query,
+        "retmode": "json",
+        "retmax": retmax,
+        "tool": "ecc-pubmed-search",
+        "email": os.environ.get("NCBI_EMAIL", ""),
+    }
+    api_key = os.environ.get("NCBI_API_KEY")
+    if api_key:
+        params["api_key"] = api_key
+
+    response = requests.get(f"{BASE}/esearch.fcgi", params=params, timeout=30)
+    response.raise_for_status()
+    time.sleep(0.35)
+    return response.json()["esearchresult"]["idlist"]
+
+
+pmids = esearch("hypertension[mh] AND randomized controlled trial[pt] AND 2024:2026[dp]")
+print(pmids)
+```
+
+バッチの場合、非常に長い PMID リストを URL に渡す代わりに、NCBI ヒストリーサーバーパラメーター（`usehistory=y`、`WebEnv`、`query_key`）を優先します。
+
+## 出力の記録
+
+各検索パスについて以下を記録します:
+
+- 正確な検索文字列
+- 検索したデータベース
+- 検索日
+- 使用したフィルター
+- 結果件数
+- エクスポート形式
+- 手動除外
+
+例:
+
+```markdown
+| データベース | 検索日 | クエリ | フィルター | 結果 |
+| --- | --- | --- | --- | ---: |
+| PubMed | 2026-05-11 | `sickle cell disease[mh] AND CRISPR[tiab]` | 2020:2026[dp], English | 42 |
+```
+
+## レビューチェックリスト
+
+- フィールドタグは有効な PubMed タグか？
+- 新しいトピックについて MeSH 用語は自由テキストの同義語とペアになっているか？
+- 日付範囲は明示的で適切か？
+- 検索ログにクエリを再現するのに十分な詳細が含まれているか？
+- API キーは環境から読み込まれているか？
+- HTTP コードは解析前に `raise_for_status()` を呼び出しているか、または 200 以外のレスポンスを処理しているか？
+- レート制限は守られているか？
+
+## 参考文献
+
+- [PubMed ヘルプ](https://pubmed.ncbi.nlm.nih.gov/help/)
+- [NCBI E-utilities ドキュメント](https://www.ncbi.nlm.nih.gov/books/NBK25501/)
+- [NCBI API キーガイダンス](https://support.nlm.nih.gov/kbArticle/?pn=KA-05317)
+- NCBI サポート: <eutilities@ncbi.nlm.nih.gov>

package/resources/local/ecc/docs/ja-JP/skills/scientific-db-uspto-database/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: uspto-database
+description: 公式記録の検索、PatentSearch クエリ、TSDR チェック、譲渡データ、および再現可能な IP 調査ログのための USPTO 特許・商標データワークフロー。
+origin: community
+---
+
+# USPTO Database
+
+USPTO システムから米国の公式特許・商標記録が必要なタスクにこのスキルを使用します。
+
+## 使用するタイミング
+
+- 付与済み特許または出願前公開の検索。
+- 特許出願ステータス、ファイルラッパーデータ、譲渡、または公開の訴追履歴の確認。
+- 商標ステータス、文書、または譲渡履歴の検索。
+- 再現可能な先行技術、ポートフォリオ、または IP ランドスケープの調査ログの構築。
+- USPTO 記録と Google Patents、Lens.org、Semantic Scholar、または企業の特許ページなどのセカンダリツールとの比較。
+
+このスキルを法的アドバイスに使用しないでください。データ収集と記録確認のワークフローとして扱ってください。
+
+## ソース選択
+
+公式の USPTO またはUSPTO がサポートするサーフェスを優先します:
+
+- Open Data Portal (ODP): USPTO の移行済みデータセットと API の現在のホーム。
+- Patent File Wrapper: 公開特許出願の書誌データとファイルラッパーレコード。
+- PatentSearch API: 付与済み特許と出願前公開データセット向け PatentsView 検索 API。
+- TSDR Data API: 商標ステータスと文書取得。
+- Patent and Trademark Assignment Search: 所有権移転記録。
+- ODP の PTAB データ: 特許審判・控訴委員会の手続き。
+
+セカンダリソースは便宜上のインデックスとしてのみ使用します。答えが重要な場合は、公式記録と照合してください。
+
+## 認証とシークレット
+
+多くの USPTO API フローには API キーが必要です。キーは環境変数またはシークレットマネージャーに保存し、コミットされたファイルや貼り付けられたトランスクリプトには絶対に入れないでください。
+
+一般的な環境変数名:
+
+```bash
+export USPTO_API_KEY="..."
+export PATENTSVIEW_API_KEY="..."
+```
+
+PatentSearch では `X-Api-Key` ヘッダーでキーを送信します。TSDR については、現在の USPTO API マネージャーの指示とレート制限ガイダンスに従ってください。
+
+## PatentSearch ワークフロー
+
+質問がトレンド、発明者、譲受人、分類、日付、またはポートフォリオのスライスに関するものである場合、特許と出願前公開の広い検索に PatentSearch を使用します。
+
+ワークフロー:
+
+1. 現在の PatentSearch リファレンスまたは Swagger UI からエンドポイントを特定する。
+2. 明示的なフィルターを持つ JSON クエリを構築する。
+3. 分析に必要なフィールドのみをリクエストする。
+4. 確定的にソートしてページネーションする。
+5. エンドポイント、クエリ本体、日付、データの通貨に関する注記、結果件数を記録する。
+
+Python リクエストのスケルトン:
+
+```python
+import os
+import requests
+
+API_KEY = os.environ["PATENTSVIEW_API_KEY"]
+BASE = "https://search.patentsview.org/api/v1"
+
+payload = {
+    "q": {
+        "_and": [
+            {"patent_date": {"_gte": "2024-01-01"}},
+            {"assignees.assignee_organization": {"_text_any": ["Google", "Alphabet"]}},
+        ]
+    },
+    "f": ["patent_id", "patent_title", "patent_date"],
+    "s": [{"patent_date": "desc"}],
+    "o": {"per_page": 100, "page": 1},
+}
+
+response = requests.post(
+    f"{BASE}/patent/",
+    headers={"X-Api-Key": API_KEY, "Content-Type": "application/json"},
+    json=payload,
+    timeout=30,
+)
+response.raise_for_status()
+print(response.json())
+```
+
+クエリを再利用する前に、ライブの PatentSearch ドキュメントで現在のエンドポイント名、フィールドパス、リクエストパラメーター、API キーの利用可能性を確認してください。
+
+## 商標/TSDR ワークフロー
+
+タスクが商標のケースステータス、文書、画像、所有者履歴、または訴追イベントを必要とする場合は TSDR を使用します。
+
+ワークフロー:
+
+1. シリアル番号または登録番号を正規化する。
+2. 現在の TSDR API の指示と必要な API キーヘッダーを確認する。
+3. まずステータスを取得し、必要な場合にのみ文書を取得する。
+4. PDF、ZIP、および複数ケースのダウンロードに対するより低いレート制限を守る。
+5. 出力にデータ取得日とシリアル/登録識別子を記録する。
+
+大規模な商標取得の場合は、公開ページのスクレイピングではなく、文書化されたバルクデータフローを優先します。
+
+## ファイルラッパーと訴追履歴
+
+出願ステータス、取引履歴、および訴追文書については:
+
+- ODP Patent File Wrapper 検索から始める。
+- 利用可能な場合は正確な識別子を使用: 出願番号、公開番号、特許番号、または当事者名。
+- 記録が付与済み特許、出願前公開、または係属中の出願のいずれであるかを記録する。
+- 文書の日付とステータスを引用する前に記録詳細ページと照合する。
+
+## 譲渡ワークフロー
+
+特許または商標の所有権については:
+
+1. 特許/出願/登録番号、譲渡人、譲受人、または利用可能な場合はリール/フレームで公式の譲渡データを検索する。
+2. 譲渡文、実行日、記録日、当事者を記録する。
+3. 譲渡記録と現在の法的所有権の結論を区別する。
+4. 所有権が重要な場合は、弁護士または専門家によるレビューのために結果にフラグを立てる。
+
+## 再現可能な出力
+
+すべての USPTO 調査パスにはログテーブルを含める必要があります:
+
+```markdown
+| ソース | 検索日 | 識別子/クエリ | フィルター | 結果 | 注記 |
+| --- | --- | --- | --- | ---: | --- |
+| PatentSearch | 2026-05-11 | `assignee=Alphabet AND date>=2024` | patent endpoint | 118 | 実行前に API ドキュメントを確認 |
+| TSDR | 2026-05-11 | `serial=90000000` | status only | 1 | API キーフロー、バルク文書取得なし |
+```
+
+最終的な書き込み物では、以下を分離します:
+
+- 公式記録の事実
+- 推論された分析
+- セカンダリソースの便宜上のマッチ
+- 未解決のギャップまたは法的レビューが必要な記録
+
+## レビューチェックリスト
+
+- 公式の USPTO またはUSPTO がサポートするソースを最初に使用したか？
+- コードを実行する前に現在のエンドポイントとフィールド名を確認したか？
+- API キーはファイル、シェル履歴、出力ログから除外されているか？
+- クエリログには検索日と正確なリクエスト形式が含まれているか？
+- レート制限は守られているか？
+- 法的結論は回避されているか、または明示的にエスカレートされているか？
+- セカンダリソースはセカンダリとして明示的にラベル付けされているか？
+
+## 参考文献
+
+- [USPTO APIs カタログ](https://developer.uspto.gov/api-catalog)
+- [USPTO Open Data Portal](https://data.uspto.gov/)
+- [PatentSearch API リファレンス](https://search.patentsview.org/docs/docs/Search%20API/SearchAPIReference/)
+- [PatentSearch API アップデート](https://search.patentsview.org/docs/)
+- [TSDR API バルクダウンロード FAQ](https://developer.uspto.gov/faq/tsdr-api-bulk-download)