specification-writing

仕様書の作成：セクションごとの特許明細書

各レビュアーの枠を開始する前に、選択可能なレビュアーに従ってください。 呼び出しの解決 → .aris/reviewer.json → Codex のデフォルト（新規のネイティブレビュアー）の順に確認し、 正規のヘルパーリゾルバーを通じて reviewer_route.py を使用し、この枠の ティア、新しいコンテキスト、ソース／画像入力、決定論的ゲートを維持してください。 以下の Codex の例／固定指定は backend=codex にのみ適用されます。それ以外のルートでは、 それぞれの初回呼び出し／返信の契約に従ってください。ルートと実際に返された識別情報を保存してください。 選択肢を利用できない場合は REVIEW_UNAVAILABLE とします。実際の ファミリー／完了状況／スコープに基づいて受け入れを判定してください。 呼び出し時のレビュアー／モデル／エフォートの上書き設定は、レビュアーを含む子プロセスに引き継いでください。 生成ワーカーは変更しません。

以下に基づいて特許明細書を作成します：$ARGUMENTS

特許明細書向けに /paper-write を適用したものです。明細書は請求項を裏付けるものであり、論文ではありません。

定数

• REVIEWER_MODEL = gpt-6-astra — 仕様書の品質を審査する外部レビュアー
• JURISDICTION = "auto" — パイプラインから引き継ぐか、引数から判定します。CN、US、EP、ALL
• OUTPUT_FORMAT = "markdown" — Markdown の草案。/jurisdiction-format によって出願用形式に変換されます
• OUTPUT_DIR = "patent/" — 出力先のベースディレクトリ
• LANGUAGE = "auto" — 管轄地域に基づいて自動設定します：CN->中国語、US/EP->英語

入力

1. patent/CLAIMS.md — 作成済みの請求項（主要な資料）
2. patent/INVENTION_DISCLOSURE.md — 発明の分解
3. patent/PRIOR_ART_REPORT.md — 背景技術のセクション用
4. ユーザーが提供した図面（ある場合）

共通リファレンス

仕様書作成の規則、言語のガイドライン、参照符号の慣例については、../shared-references/patent-writing-principles.md を読み込んでください。 管轄地域に基づいて、../shared-references/patent-format-cn.md、patent-format-us.md、または patent-format-ep.md を読み込んでください。

ワークフロー

ステップ 1：仕様書の構成を初期化する

出力ディレクトリと各セクションのファイルを作成します。

patent/specification/
├── title.md
├── technical_field.md
├── background.md
├── summary.md
├── drawings_description.md
├── detailed_description.md
└── abstract.md

ステップ 2：タイトル（发明名称）を記載する

• 最も広い請求項の範囲と一致させる必要があります
• 商標や「改良された」「新しい」「新規の」といった表現は使用しません
• CN 形式：「一种[领域]的[技术主题]」または「[领域]的[技术主题]装置」
• US/EP 形式：「[目的]のための[技術的主題]」または「[技術的主題]およびその方法」
• 簡潔にします（CN：通常 25 文字未満、US：500 文字未満）

ステップ 3：技術分野（技术领域）を記載する

技術分野を特定する 1～2 段落を記載します。

• 「本発明は[広い分野]に関し、より詳細には[具体的な領域]に関します。」
• CN：「本发明涉及[技术领域]，具体涉及[具体领域]。」

ステップ 4：背景技術（背景技术）を記載する

これは文献レビューではありません。問題を直接提示します。

構成：

1. 最も近い先行技術のアプローチを説明します（2～3 段落）
2. 各アプローチに固有の技術的欠点を特定します
3. 欠点は技術的なものでなければならず、商業的または社会的なものであってはなりません
4. 先行技術が「優れている」または「より良い」と認めてはなりません
5. 既知の先行技術でない限り、特定の特許番号を引用してはなりません（引用は US では IDS に、CN では背景技術のセクションに記載します）

CN 形式：「背景技术」セクションで既存技術とその欠点を説明します。

ステップ 5：要約の作成（发明内容）

INVENTION_DISCLOSURE.mdを直接反映した、次の3つのパートで構成します。

技術的課題（要解决的技术问题）:

• 背景技術の欠点から導かれる課題を記載します
• CN：「本发明要解决的技术问题是...」

技術的解決手段（技术方案）:

• 発明がどのように課題を解決するかを記載します
• すべての請求項の構成要件を裏付ける必要があります
• 最も広い請求項から始め、発明の中核となる概念を説明します
• CN：「为解决上述技术问题，本发明采用的技术方案是：...」
• 数式、数学的導出、回路モデルは記載しないでください。これらは发明内容ではなく、具体实施方式に記載します

有益な効果（有益效果）:

• 構造上・技術上の特徴から導かれる利点を、定性的に説明します
• CN：「本发明的有益效果是：...」
• 具体的な数値結果は記載しないでください（例：「検出限界70μm」「応答時間105ms」）。これらは発明の特性ではなく、実験結果です
• 構造に基づいて効果を説明します：「...の構造を採用しているため、...の効果があります」

ステップ 6：図面の簡単な説明（附图说明）

ユーザーから図面が提供されている場合は、サブスキルとして/figure-descriptionを呼び出します。

/figure-description "patent/figures/"

ユーザーから図面が提供されていない場合は、請求項に基づいて存在すべき図面を説明します。

形式：

• CN：「图1是...的示意图；图2是...的流程图；」
• US：「FIG. 1 is a block diagram showing...; FIG. 2 is a flowchart illustrating...」

ステップ 7：詳細な説明の作成（具体实施方式）

サブスキルとして/embodiment-descriptionを呼び出します。

/embodiment-description "patent/CLAIMS.md"

このセクションでは、次の内容を満たす必要があります。

• 参照符号を用いて、少なくとも1つの実施形態を一通り説明する
• 当業者（POSITA）が発明を実施できるようにする
• すべての請求項の構成要件を明示的な説明で裏付ける
• より広い請求項の解釈に対応できるよう、変形例や代替案を含める

ステップ 8：要約書の作成（摘要）

管轄ごとの語数制限：

管轄	語数制限	備考
CN	300語（中国語の文字数）	最も代表的な請求項の参照を含める
US	150語（2500文字）	効率的な検索を可能にし、法律用語的な表現は使わない
EP	約150語	メリットや価値について述べない

要約書では次の内容をまとめます。

1. 技術分野
2. 解決する課題
3. 技術的解決手段（中核となる特徴）
4. 主な利点

ステップ 9：請求項の裏付けの確認

すべての請求項の構成要件が明細書で裏付けられていることを確認します。

請求項	構成要件	明細書のセクション	段落	参照符号
1	ステップ a	detailed_description	¶3	202
1	ステップ b	detailed_description	¶4	204
X	コンポーネント A	detailed_description	¶2	102

裏付けのない構成要件がある場合は、次に進む前に必要な説明を追加します。

ステップ 10：新しいエージェントによるレビュー（デフォルトでは同一ファミリーの仮出願）

推論レベルxhighの専用Codexレビュアーエージェントを通じてREVIEWER_MODELを呼び出します。

このレビュー担当の枠を先に解決してください。以下はbackend=codexの例です。

spawn_agent:
  model: gpt-6-astra
  reasoning_effort: xhigh
  message: |
    You are a patent examiner reviewing a specification for completeness.
    CLAIMS: [all claims]
    SPECIFICATION: [all specification sections]

    Check for:
    1. Written description support: Does every claim element have explicit or inherent support?
    2. Enablement: Can a POSITA practice the invention from this specification?
    3. Consistency: Do reference numerals match across figures and specification?
    4. Language quality: Any subjective terms, relative terms without definition, or result-to-be-achieved language?
    5. Missing embodiments: Are there claim features that need additional embodiments?
    6. Background deficiencies: Are they technical and specific enough?

ステップ 11：出力

明細書の各セクションはpatent/specification/に配置します。

要約ファイル：patent/specification/SPECIFICATION_INDEX.md。次の内容を含めます。

## Patent Specification

### Sections
| Section | File | Word Count | Status |
|---------|------|-----------|--------|
| Title | title.md | | Complete |
| Technical Field | technical_field.md | | Complete |
| Background | background.md | | Complete |
| Summary | summary.md | | Complete |
| Drawings Description | drawings_description.md | | Complete |
| Detailed Description | detailed_description.md | | Complete |
| Abstract | abstract.md | | Complete |

### Claim Support Status
| Claim | Elements Supported | Elements Missing |
|-------|-------------------|-----------------|
| 1 | All | None |
| X | All | None |

主なルール

• 明細書は請求項を裏付けるものであり、その逆ではありません。すべての請求項の構成要件に裏付けが必要です。
• 用語を統一してください。同じ概念には、文書全体を通じて同じ語を使用します。
• 実験結果、精度指標、実証評価は記載しないでください。
• 主観的な表現（「優れた」「驚くべき」「卓越した」など）は使用しないでください。
• 参照符号を統一してください。同じ構成要素には、常に同じ参照符号を使用します。
• 背景技術のセクションでは、「改善の必要性」を一般的に述べるのではなく、具体的な欠点を説明します。
• 複数の実施形態は明細書を補強しますが、常に必須というわけではありません。
• 大きなファイルの取り扱い：Write操作に失敗した場合は、Bashのcat <<'EOF'ヒアドキュメントで再試行します。
• 現在のCodexホストでレビュアーへの委任が利用できない場合は、処理を中断し、続行する前にCodexエージェントのサポートを有効にするようユーザーに依頼します。