# Write Researched Document

> 根拠を調査・検証し、監査可能なMarkdown文書を作成する対話型スキル。 調査レビュー、複数資料を統合する分析・モデル文書、読者向けの解説記事を、 GitHub Issueや依頼文からworktree上で執筆する。既存のClaim Ledgerや調査資料を優先し、 不足する根拠だけを追加調査する。研究結果を別の集団・制度・地域・時代・概念へ援用する場合は、 research-transfer-checkerを独立したコンテキストで執筆前後に実行する。 `$write-researched-document` と明示された場合だけ使用し、一般的なコード実装、 README・仕様書・議事録の作成、根拠を必要としない文章修正には使用しない。

- Skill: `maro114510/write-researched-document` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add maro114510/write-researched-document`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maro114510/write-researched-document/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: maro114510 (https://skillmd.com/u/maro114510)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/maro114510/write-researched-document

---


# write-researched-document

主要主張から出典、反証、適用範囲、確信度へ遡れる文書を作る。
根拠が不足または矛盾する場合は、文章を整えるより主張の限定・仮説化・削除を優先する。

詳細な様式と判定規則は [`references/evidence-workflow.md`](references/evidence-workflow.md) にある。
各Phaseで参照を指示された節を、そのPhaseに入る前に読む。

## Phase 0: 対象と環境を確定する

1. 依頼、Issue、関連コメント、依存Issue、受け入れ条件、既存成果物を確認する。
2. `AGENTS.md`、README、テンプレート、調査・文体規約、用語集、Claim Ledger、
   source register、search logを探索する。
3. 閉じたIssueは終了理由と既存成果物を確認する。監査・改訂・再執筆の依頼でなければ報告して停止する。
4. 未完了の依存成果物が本文の前提なら、影響を示して停止する。
5. 読み取り専用の依頼ではworktreeを作らない。ファイルを変更する場合はGit状態と既存worktreeを確認し、
   対象用worktreeを再利用するか、mainから`docs/issue-<番号>-<slug>`を基本名として作る。
   無関係な変更は上書きしない。

選択した作業ディレクトリの絶対パスを保存し、以降はそこで作業する。

## Phase 1: 執筆設計を作る

[`evidence-workflow.md`の「執筆設計」](references/evidence-workflow.md#執筆設計)を読む。

成果物を「調査レビュー」「分析・モデル文書」「公開記事」のいずれかへ分類し、
想定読者、読者の問い、作業仮説または中心命題、最も強い反論、対象外、構成案、
Issue受け入れ条件との対応を定める。複数候補で構成が変わる場合だけ質問する。

既存研究を統合して機構を示す成果物は「分析・モデル文書」とする。
公開予定があるだけでは「公開記事」にしない。

## Phase 2: 根拠を棚卸しして承認を得る

[`執筆前の承認`](references/evidence-workflow.md#執筆前の承認)と[`Evidence Map`](references/evidence-workflow.md#evidence-map)を読む。

1. 主要主張を個別に真偽条件を持つ命題へ分解し、経験的主張、推論、価値判断を区別する。
2. 既存のClaim LedgerがあればID、状態、確信度、出典を再利用する。列名が異なる場合は
   Evidence Mapの意味へ対応付け、対応不能な項目を未解決として承認画面に出す。
   既存のsource registerからClaimとの対応、確認済みの資料範囲、情報基準日を継承する。
   Ledgerがなければ作業用Evidence Mapを作る。
3. 各命題へ根拠、反証、適用範囲、確信度、情報基準日を対応させる。
4. 集団、制度、地域、時代、概念、推論をまたぐ射程移送と、
   中心主張を含む本文の全主要主張の証拠ギャップを識別する。
5. 執筆設計と根拠の状態を一つのレビュー単位として提示し、承認されるまで本文を書かない。

`citation_support: pending`の中心命題は確立済みの結論ではなく作業仮説と示す。
承認は現在のユーザーによる明示回答だけを指す。沈黙、過去の承認、ラベルを承認とみなさない。
条件付き承認では条件を反映したレビュー単位を再提示する。
承認済みの項目が文書の意味または構成を変える形で更新された場合は再承認を得る。

ファイルを変更する作業で永続的なClaim Ledgerがなければ、承認後から本文の初回保存前までに
`<document-stem>.evidence.md`を作り、Evidence Mapを保存する。読み取り専用の設計・監査では作らない。

## Phase 3: 証拠ギャップだけを調査する

既存規約に従い、主張を直接検証できる原研究、公的資料、査読研究を優先する。
検索スニペット、出典のない要約、生成された引用は根拠にしない。
支持資料に加えて反証、境界条件、訂正、撤回、更新も確認する。

探索日、対象Claim、検索語、探索先、確認範囲、採用・除外理由、資料の取得状況を記録し、
Evidence Mapへ反映する。永続的なClaim Ledgerがなければ、EvidenceファイルのSearch Logへ保存する。
限定した探索で見つからなくても、根拠が存在しないとは断定しない。

## Phase 4: 射程移送を執筆前に独立検査する

射程移送がある場合だけ、[`evidence-workflow.md`の「独立検査」](references/evidence-workflow.md#独立検査)に従う。

- 親の会話履歴を継承しない新しいコンテキストで`$research-transfer-checker`を実行する。`subagent_type: fork` は使わない — fork は親の会話履歴をそのまま継承するため、独立検査の意味がなくなる。
- 命題の原文、原資料、移送元と移送先、読者、利用目的だけを渡す。
- 各項目には承認済みの値をそのまま使う。原文、原資料の一意な識別情報、読者、利用目的の
  いずれかが欠けていれば推測やプレースホルダーで補わず、不足項目を示して停止する。
- 親の推論、期待判定、Evidence Map、執筆設計、過去の判定、無関係な草稿は渡さない。
- Checker自身に原資料を確認させ、結果をEvidence Mapへ反映する。
- Checker用コンテキストを本文作成や次の検査に再利用しない。

履歴を継承しない実行を保証できなければ独立検査済みと扱わない。
別セッション用の入力パケットを提示して停止する。

## Phase 5: 根拠から本文を書く

- Evidence Mapにない主要主張を作らない。必要になればPhase 2へ戻る。
- 経験的主張、推論、価値判断を文章上でも区別する。
- 原資料の限定語、対象、時点、不確実性を落とさない。
- 分析・モデル文書には成立条件、遮断条件、代替説明、反証条件を含める。
- 公開記事は読者の問いから答えと根拠へ進む構成にする。
- 引用、Claim ID、URL、DOI、確信度、情報基準日はリポジトリの方式に合わせる。

## Phase 6: 射程移送を執筆後に独立検査する

射程移送を含む文書だけで、Phase 4とは別の新しいコンテキストを使う。`subagent_type: fork` は使わない — fork は親の会話履歴をそのまま継承するため、独立検査の意味がなくなる。
草稿中の命題を原文のまま渡し、限定語の脱落、新しい射程移送、推論の格上げを検査する。
修正後に判定が変わり得る命題だけを、さらに新しいコンテキストで再検査する。

判定は[`evidence-workflow.md`の「判定と公開ゲート」](references/evidence-workflow.md#判定と公開ゲート)へ上から順に照合する。
ブロック条件に該当する命題を事実として残さない。
Checker全文ではなく、判定、修正文、不足根拠、資料取得状況を永続的な証拠管理先へ記録する。

## Phase 7: 検証・レビュー・コミット

1. 主要主張から出典、反証、適用範囲、確信度へ遡れることと、受け入れ条件への対応を確認する。
2. リンク、表、図、引用、文字数、メタデータと、リポジトリ固有のCI・lintを検査する。
3. 日本語文書には`ja-style-check`を適用する。
4. `difit`で差分をレビューし、指摘を反映して関連検査を再実行する。
5. 承認後に`commit`を使う。明示依頼があるまでPRは作成しない。

停止条件と成果物別の完成条件は[`evidence-workflow.md`](references/evidence-workflow.md)で最終確認する。

## 最終報告

- 作成・更新した文書と成果物モード
- 追加調査した証拠ギャップ
- Checkerの実行有無と未解決判定
- 検証結果、コミット状態、残る制約