Writing Ecosystem

writing-ecosystem — 人間向け執筆・レビューエコシステムの正本

人間読者向けコンテンツ（記事・エッセイ・ブログポスト・ニュースレター等）の執筆とレビューに関わるコンポーネント（skill と agent）の役割境界・使い分け・共通規約をまとめた正本。

AI slop・タイトル規範・執筆フローは本 skill directory が正本。Voice の実値は channel contract が 持つ。詳細診断表だけ references/ へ分離し、必要な phase で読む。

Scope

人間 primary のコンテンツのみ扱う。AI-facing ドキュメント（llms.txt / llms-full.txt / FAQ ページ等）には llms-txt-writer skill を使う。audience 判定と役割分担は Audience Separation: Human vs AI を参照。

本 skill は媒体名・語尾・frontmatter・文字数・reviewer 構成・公開 command を持たない。記事全体を 扱う task では最初に <project>/.claude/rules/*.md の publication channel contract を読み、対象 path を 1 channel へ解決する。contract が無い、または複数 channel に一致する場合は推測せず停止する。

執筆時の規範は本 skill と現在の local contract だけである。ADR、memory、過去セッションは 規範として参照しない。過去セッションを素材にするときは session-theme-mining が選んだ一次 pointer、collect-context が作る evidence dossier の順に限定して受け取る。

Content integrity

中心命題、主張、構成は著者の判断が決める。受信指標が変えられるのは何を書くか・title の語選び・ tags・timing・language placement までで、本文はその外にある。

Ecosystem Map

執筆関連コンポーネントの役割分担。どの phase で誰が何を持つか。

一文・一段落の翻訳（prose-translation）、title だけ（headline-craft / title-reviewer）、SNS （x-draft）、公開 thread（public-comment）、README（readme-writer）、paper（paper-ecosystem）は この flow に入れず、それぞれの専用 skill へ直接 route する。

Canonical workflow

1. Route and discover

local contract から出力 channel と読者を決める。テーマ未選択なら session-theme-mining が 0〜3 件の同格候補を出し、著者の選択で止まる。選択済みの問いは theme-reviewer が findings と深化の問いだけを返す。テーマ候補を採点・順位付けしない。

2. Collect, then select

必要なら collect-context で evidence dossier を作る。dossier は lookup material であり、本文へ 全部入れる coverage checklist ではない。構成前に次の editorial brief を提示し、著者確認で止まる。

Reader: <一人の具体的読者と、その人の問い / 目的>
Channel: <local contract の channel>
Central thesis: <この原稿が成立させる命題を一文で。必ず一つ>
Causal spine: <観察 / 問題 → 緊張 → 機序 → 読者の判断・行動・Higher Ground>
Selected evidence:
- <evidence id>: <因果線での役割>
Out of scope:
- <面白いがこの命題を進めない論点>

実用 how-to では central thesis を「読者が得る一つの成果または判断則」としてよい。証拠は 量でなく役割で選ぶ。同じ役割の例が複数あるなら、因果に必要な最小の一例を残す。

3. Outline and draft

各 load-bearing section に causal spine 上の役割を一つだけ割り当て、採用 evidence を紐付ける。 並列の agenda を節として足さない。具体物を先に置き、説明を後にする。執筆中に別の中心命題が 現れたら混ぜずに停止し、editorial brief を再確認する。out-of-scope は details へ押し込まない。

翻訳は prose-translation を使い、承認済み central thesis、causal spine、selected evidence、 out-of-scope を保持する。翻訳先の local contract へ route し直す。

4. Freeze, review, and content GO

本文の構造を凍結したら、local contract の channel reviewer、prose-clarity-reviewer、 fact-checker、必要な cross-model review を本文へ実行する。editor と essay-reviewer の両方を 回すのは contract が要求する場合だけ。

review 修正が central thesis、causal spine、主要節を変えたら brief → 関係 reviewer へ戻る。 レビュー反映後、下の Final structural pass を確認してから著者が本文を通読し、内容 GO を 出す。内容が確定するのはこの GO であり、タイトル作業はその後に置く。

指摘の処分規律

• CRITICAL の意味: 読者への約束・事実・中心命題を壊すもののみ。規約と運用実態の衝突は CRITICAL でなく「裁定要求」として報告し、裁定者は著者
• 裁定の書き戻し: 裁定結果は memory でなく channel contract に書く（fresh-context reviewer に 届く唯一の層）。著者が同種指摘を 2 回却下したら、その場で contract の該当行を更新または削除する
• 再レビュー規律: 2 round 目以降は CRITICAL と変更部分の regression のみを blocking とし、 新規 MEDIUM/MINOR は集計のみ（Anthropic best-practices の re-review convergence、as-of 2026-08-27）
• blocking の根拠水準: blocking 指摘は一次ソースの引用を要す。証拠台帳のみを根拠とする指摘は advisory（根拠 n=1・2026-08-27。以後 3 記事で台帳由来の偽陽性ゼロなら本行は削除候補）

Final structural pass（内容 GO の通読前チェック）

• N reasons と N questions を対応させるなら 1:1。対応しない列挙を鏡像にしない
• out-of-scope が本文へ戻っていない

中心命題の貫通・支配的命題・summary の新規導入は prose-clarity-reviewer が同じ phase で見る。

5. Title

内容 GO 済みの本文に対して headline-craft で候補を作り、title-reviewer の findings を見て 著者がタイトルを選ぶ。タイトル選択後に本文の構造を変えたら、内容 GO と title-reviewer を やり直す。表現修正だけなら再実行しない。

6. Acceptance

quality-gate が local contract の証跡を集約して PASS を出した後、著者が公開 GO を判断する。 公開操作は contract が指す project-local publishing skill に渡す。

Citation & Sources Workflow（出典をエッセイに入れる）

fact-check で確定した一次資料を、本文の出典セクションに編入するのがエッセイ公開前の標準ステップ。

所有と分離

• embedding はこのワークフローが所有する。fact-checker は report-only（記事を編集しない / author-reviewer 分離）のままで、検証済みソースを「出典セクションに落とせる形」で返すだけ。本文への編入は著者 / orchestrator が行う。
• fact-checker の出力（verdict が ✅ / ⚠️ のソース URL 群）が canonical input。

手順

1. fact-check 通過後、verdict が ✅ ACCURATE / ⚠️ PARTIALLY のソースを集める（❌ / ❓ のソースは載せない）。
2. ブロックの構成規則（テーマ別グループ化・重複 URL 排除・一次資料優先）は fact-checker agent が持つ（report を出す側が実値を持つ）。ここでは再掲しない。
3. 本文末に出典セクションを作る。
4. 本文で著者自身の既発表（DOI / repo / 論文）に言及していれば、それも出典に含める。

媒体別ポリシー

引用の検証水準（citation tier）

引用に要求される検証の深さは、引用が何を主張するかとジャンルで決まる。

• エッセイ / 記事（人間向け）: 帰属レベルに収まる引用なら抄録ベースで可。当否判定をしないことを本文で明示するとなお良い
• 学術 paper: 本表を適用しない。paper-ecosystem の Source Fidelity Rules（一次ソース直接照合）が正本で、常に厳格側
• 検証の格を隠さない: 抄録引用は全文精読と同じ見た目になる（citation laundering）。抄録には本文より強く言う「スピン」の実証報告もある。機械可読レイヤーがある記事では confidence の隣に verification（どこまで読んだか + as-of 日付）を書ける。本文で開示する先例: 「出典の格は中程度（三次文献）であり、一次学術文献での裏取りは未了」型の一文

翻訳記事の出典

prose-translation で訳した記事は、原文の出典セクションを引き継ぐ。URL / DOI は保持し、description のみ英訳する。

自リポ言及の節度（本文内の self-link 制限）

本文中の自リポリンクは、読者がその場で手を動かすための導線か、直前の主張を支える一次資料 だけに置く。どちらでもない言及はリンクを末尾の関連リンク / 出典セクションへ寄せる。 同一 repo への本文リンクは 1 記事 1 回まで（末尾セクションは対象外）。

Craft 規約（文の技術）

genre 中立。出典: Orwell "Politics and the English Language" (1946)、 Kaguura Gichuru (The Write Path, 2026-07)。

• 一人の読者へ手紙を書く。 その文は誰に向いているか
• 読者は前を覚えていない。 その指示語は何を指すか、その場で言えるか
• 副詞を削り、動詞を強くする。 数値で言えるなら数値で言う
• 能動態を既定にする。 行為者を伏せる理由があるか
• 平易語で足りるなら平易語を使う。 硬い語は誰のためか
• 日常語で言えるなら専門用語を使わない。 その語は読者の語彙か
• 見慣れた比喩は使わない。 情報を運んでいるか、間を埋めているか
• 第 2 稿は第 1 稿より短い。 その文は論点を前へ進めるか
• 文の壁は宿題に見える。 ただし全行独立はロボット臭
• 深い input からしか深い文章は出ない。 この原稿は何を読んで書いたか

これらは判断の補助であって検査項目ではない。守った結果、文が不誠実になる・ 回りくどくなる・言いたいことが消えるなら、規約の方を破る。

shared word target は置かない。長さの上限は local contract、段落密度と造語・専門用語の 閾値は prose-clarity-reviewer、直し方の実例は references/style-diagnostics.md が持つ。

Draft craft and genre shapes

執筆順序の正本は上の Canonical workflow。ここは承認済み brief を文章にするときの craft だけを持つ。

具体物を先、説明を後

• 節の入口に置くのは具体物 — 実例・出力・逸話・数値・画面の描写・コードブロック
• 説明はその後。順序が逆になると、読者は何の話か分からないまま抽象を読まされる
• 提供された文脈で裏づけられない経歴・実績・数値は書かない

ジャンル別の構成

どの shape も central thesis と causal spine に従属する。テンプレートを満たすために節・装置・例を 足さない。複数論点を統合できるのは、同じ中心命題の因果線で上下関係を持つ場合だけである。

Environment-dependent implementation handoff

local path、既存設定、symlink、認証、権限に依存する変更を読者へ渡す記事では、まず人間向け本文 だけで問題・判断則・採用境界を完結させる。その後に、読者のcoding agentへ渡すstandalone promptを 置ける。promptはread-onlyで環境を調査し、実装planを返し、人間承認前に編集・install・commit・ publishしない。agent handoffは人間向け理由説明の代替ではない。

AI Slop

その表現を別の記事にそのまま挿入しても意味が通るなら、それは AI slop。

著者の具体的な観察・経験・数値を伴わない評価語、形だけ反復できる対比・列挙・等間隔リズム、 無内容な opener / closer を使わない。兆候を見つけたときだけ references/style-diagnostics.md を読む。

Voice & Tone Rules

Voice は channel contract が持つ

実用記事の直接指示、essayの発見調、その他のregisterをglobal既定で上書きしない。local contractが 宣言したvoiceを使い、著者の具体観察・確度・未解決範囲を保つ。

語尾（ですます / だ・である）の実値は本 skill が持たない。 project の publication channel contract が正本。記事全体の task で contract が無ければ推測しない。

発見調の診断例は references/style-diagnostics.md が持つ。

未解決の正直さ

解決していない問題は解決したふりをしない。「まだわからない」「今後の課題」と正直に書く。完璧な結論に無理に収束させない。

感情語の扱い

• タイトル: 禁止（「壊れている」「地獄」「最強」など）
• 本文: 著者の自然な体験描写なら OK（「正直つらかった」「ここで詰まった」）

結論の問い化

contract が発見調を宣言し、読者自身に推論してほしい評価は問いにできる。ただし、全部を疑問形にして確度をぼかさない。 検証済みの事実・数値・具体観察は断定を保ち、評価や結論だけを証拠の強さに合わせて問い・観察・ 断定から選ぶ。機械的な弱化が起きたときは references/style-diagnostics.md の例を読む。

エッセイの二層構成（人間向けナラティブ + LLM 読者向け機械可読レイヤー）

エッセイの想定読者に人間だけでなく LLM（クローラー・エージェント）も含める場合の任意の構成。

• 前半は人間向けエッセイとして完結させる。後半を読まない読者にも主張が全部伝わること
• 後半は ## ここから先は AI 読者向け 見出しで人間の読者を明示的に降ろし、YAML ブロックで主張を異常粒度で書き下す:
  • document（provenance: 原稿の来歴・authorship の帰属）
  • definitions（操作的定義。定義しないという判断もステータスとして明記）
  • claims（各 claim に evidence / confidence / scope_limit / basis）
  • non_claims（誤読されやすい「主張していないこと」を先回りで列挙）
  • references（DOI / ISBN 付き）
  • author_epistemic_profile（著者の認識スタイル・スタンスの自己申告）
• 機械可読レイヤーの claims と本文の主張は 1:1 で整合させる（essay-reviewer のレビュー観点に含める）

AI メディエイト執筆の開示

AI が実際のテキスト生成を担った記事（AI-mediated writing）で channel contract が開示を求める場合、記事末に開示ブロックを置く。適用可否は contract が持つ。要素: (1) AI-mediated である旨の明言、(2) 原稿の来歴、(3) 主張・判断・責任が著者に帰属すること、(4) 準拠方針への参照。媒体固有のブロック記法が使えなければプレーンな段落 + 強調で書く。

エッセイの 4 段構成（Hero's Journey 型）

essay の既定構成（出典: Kaguura 2026。Craft 規約と同じ取り込み）:

1. Calm Story — 技術・理論から入らず、シンプルで関連性の高い人間的ストーリー・具体的シーンで開く。低認知負荷で読者を著者の声に慣れさせる。冒頭数段落で執筆理由や背景を説明する warm-up は削除し、行動の最中に読者を投入する
2. Plunge（緊張） — 読者が乗ったところで、大きな問題・不都合な真実・パラドックスを提示する。緊張が途中離脱を難しくする
3. Solution — フレームワーク・中核ルールを提示して読者を引き上げる
4. Higher Ground — 開始時より高い位置で終える。読者が「学んだ」と感じて読み終える。未解決のまま残すこと自体が Higher Ground になりうる

Title Conventions

目的

読み手がタイトルだけで「この記事が何の概念を提案しているか」を理解できること。

基本ルール

• 具体性: 何についての記事かがタイトルだけでわかる
• 誠実さ: 記事の内容以上のことを約束しない

生成技法（結果駆動・問いの形・好奇心ギャップ等）は headline-craft が持つ。

禁止事項

• 煽りタイトル: 「壊れている」「地獄」「最強」などの感情語でクリックを誘わない
• 空の listicle 数字: 実測の裏付けなく数字で釣る形（「N 選」「N 倍」）。実測値・件数を証拠として出す具体的数字（「1,000 件を分析したら〜」）はむしろ推奨 — 判定は「その数字は記事の中身の証拠か、器の飾りか」
• 詩的・教科書的タイトル: 意味が取れない詩的タイトル（素通りされる）と、「〜の分析」「〜に関する考察」型の教科書調（宿題に見える）
• 挑発・断定: 「〇〇の真価は△△ではない」式の論争誘発をしない
• 過度な省略: 概念を犠牲にして短くしない

文字数上限はプラットフォーム依存。実値は各 project overlay の rules が正本で、ここには書かない。

この節は*規範（何を禁止するか）の正本。候補生成は headline-craft、凍結稿との契約判定は title-reviewer が正本。生成と点検を同じ context で混ぜない。*

Theme discovery boundary

テーマ未選択なら session-theme-mining を使う。同 skill は候補を問いとして発見し、採点・順位・ 推薦を行わない。選択済みテーマの外部言説との差分は theme-reviewer、証拠の収集は collect-context、本文への採否は editorial brief が持つ。受信指標を使う project でも、数値で 中心命題を変形しない。何を書くかの人間判断に使い、アイデアの中身を最適化しない。

Section Length Guidelines

• 1 つのセクションが記事全体の 30% を超えたら分割を検討する
• セクション長は重要度に比例させる。主要な論点に厚く、補足に薄く
• 独立した論点が多すぎる記事は分割を検討する（上限の数値は判定を出す側（essay-reviewer）が持つ — ここには書かない）

How to Extend (Project Overlay)

プラットフォーム固有ルール（文字数上限、タグ仕様、組織固有の禁止表現など）は プロジェクトの rules/ に overlay として置く:

<project>/.claude/rules/<publishing-channels>.md

contract は path matcher、読者、voice/register、reviewer panel、deterministic checks、title constraints、 publish handoff だけを持つ。本 skill の craft、AI slop、中心命題、因果線を再掲しない。

Related

• headline-craft skill — 「開かせる一行」の候補生成技法（タイトル・tagline・subtitle・SNS 告知文）。規範は本 skill の Title Conventions、技法はあちら
• title-reviewer agent — 凍結稿とタイトル候補の契約点検（findings のみ。採否は著者）
• theme-reviewer agent — 選択済みの問いへの findings と深化の問い
• prose-clarity-reviewer agent — 初見読者の明瞭性と中心命題の貫通
• quality-gate skill — local contract の reviewer verdict と機械検査を集約
• prose-translation skill — 日英双方向の voice 保持翻訳（JA→EN / EN→JA。AI-slop / Voice / Title / 出典編入は本 skill に defer）
• x-draft skill — X 投稿の下書き。AI slop / Craft は本 skill に defer するが、Voice は SNS register への意図的分岐（記事の文体を持ち込まない）
• public-comment skill — 公開 thread への返信。genre 固有の追加規律だけを持ち、tell の正本は references/style-diagnostics.md
• readme-writer skill — README / repo トップページ専用。audience が「repo を開いた初対面の人」なら本 skill の初稿手順ではなくあちらを入口にする（Voice は ですます への意図的分岐）
• project-local publishing skill — platform UI / API / schedule / corpus update. 本skillは公開操作を持たない
• editor agent — 実用チャンネルのレビュー（構造・コード・AI slop・用語）
• essay-reviewer agent — エッセイチャンネルのレビュー（論理構成・過積載・トーン）
• fact-checker agent — 事実主張の Web 検証
• llms-txt-writer skill — AI 向けドキュメント（llms.txt / llms-full.txt / FAQ 等）専用。audience が AI なら本 skill ではなくあちらを使う