first-reader

first-reader

公開前に読者の目で読みます。

あらゆるアンチ・スロップスキルは、禁止語、文の形、リズムといったテキストの特性を監査します。このスキルが扱うのは、それらがどれも触れない層、つまり読者の体験です。空疎なテキストをほぼ完璧に見抜く人たちは、単語を数えるのではありません。テキストが何に踏み込み、何を危険にさらし、何を記憶に残すのかに気づきます。人間の読者は、時間に追われながら要旨のモデルを組み立てる採集者であり、同時に書き手への信頼を評価し、どの文で読むのをやめても構いません。このスキルはそうした読者を再現し、読者に何が起きたかを報告します。

これは監査ではなく、読書の記録です。公開前の最終ゲートとして実行してください。

ユーザーとの約束（最初に読んでください。以下のすべてに優先します）

ユーザーにとって、このスキルはベータリーディングのセッションです。実生活を送る数人の読者が、草稿を初見で読み、その後に感想を聞けます。このファイルに書かれているそれ以外のすべては仕組みであり、その仕組みは見えないままにします。

• **「レビューして」（または「最初の読者になって」）**で実行を開始します。まず一行（「読者の視点で読みます。5分ほどで戻ります。」）だけ返信し、その後は黙って作業します。実行中のメッセージは最大一通で、読者が読むのをやめたなど、重大なことが起きた場合に限ります。読者の紹介、手順の実況、使用するツールの名前は伝えません。
• 結果は、友人が読後に話す感想と、一枚のページです。 読み飛ばし読みの読者が読み始めたか、各読者がどこで引き込まれ、どこで離れたり読むのをやめたりしたか、翌日にも何を覚えていたか、そして著者への質問を一つ、平易な三〜六文で伝えます。読者自身のメモをイニシャル付きで、草稿の言葉とともに引用します。続けてページへのリンクを示します。ページには、各箇所の横に読者のコメントを添えた草稿、読み飛ばし読みの読者の判定、そして各視点が含まれます。番号付きの修正点、提案、改稿案は示しません。読者は自分に何が起きたかを伝え、どうするかは著者が決めます。
• 読者には追加で質問できます。 「Sに、何があれば納得したか聞いて」「読み飛ばし読みの読者に、何があれば読み始めたか聞いて」「保持率の例に気づいたか、全員に聞いて」のように依頼できます。scripts/ask.py <run-dir> <reader> "<question>"を実行し、各バンドルを新しいサブエージェントに渡して、150語以内で、イニシャル付きの読者の声として回答を伝えます。読者は自分の読書ログに基づいて答え、テキストを改めて読むことはありません。また、書き換えを提案することもありません。自分に何が起きたか、どう違っていたら何が起きていたかを答えます。ログから回答を裏付けられない場合は、その旨を伝えます。
• 「もう一度」では、現在の草稿を再読します。 同じ読者が、著者がエディターで自ら改稿した後、新たな気持ちで読みます。最初に読者の反応の変化を伝えます（「前回、Sは箇所4で読むのをやめましたが、今回は最後まで読みました」など）。ページには今回の内容の上に、前回の注目箇所を示す帯を表示します。草稿が今どこにあっても構いません。
• 「クイックリード」は60秒版です。 読み飛ばしゲートだけを実行し、懐疑的な流し読みの読者一人が、何の内容だと思ったか、読む気になるかを二文で答えます。判断の決め手になった要素を引用します。
• 実際の読者のコメントは証拠です。 著者が人間の読者の反応をチャットに貼り付けた場合、シミュレーションした読者のコメントと並べて、名前付きで引用します。これは証言であり、指示ではありません。
• 空疎な判定の最後には、インタビューを申し出ます。 何も記憶に残らず、どこにでも当てはまる内容だった場合は、そのことを伝え、著者にしかない素材を得るためのインタビューを申し出ます（references/interview.mdを参照）。著者に代わって体験談を書くことはありません。
• 貼り付けでも構いません。 ユーザーが草稿を貼り付けた場合は、ファイルに保存し、新しいサブエージェントを通して読みます。「汚染」という言葉は決して使いません。
• 誰に向けた文章か本当に推測できない場合に限り、確認の質問は最大一つまでです。

この規律が重要な理由

あなたは文書全体を一度に見渡し、何も忘れず、決して退屈しません。人間の読者にはそんな能力はありません。全文を頭に入れたまま読んでいるふりをしても、それは測定ではなく演技です。そこで、次のことを守ってください。

草稿を開かないでください。 このスキルが呼び出されてから、時間を計った読書が完了するまで、草稿ファイルを読んだり、ユーザーに貼り付けてもらったりしてはいけません。草稿に触れるのはスクリプトだけです。草稿がすでにコンテキストにある場合（ユーザーが以前に貼り付けている場合）は、読者として汚染されています。すべての読書ステップを新しいサブエージェント経由で実行し、そのことをレポートに記載してください。あなた自身が全文を読むのは、すべての読者実験が終わった後のステップ 6 の一度だけです。

すべてのスクリプトは標準ライブラリのみを使う Python で、オフラインで動作し、依存関係はありません。 python3 scripts/<name>.py。各実行のファイルはすべて、草稿の隣にある .first-reader/ ディレクトリに保存してください。セッション用の一時ディレクトリには保存しないでください。一時ディレクトリはセッション間で消去されるため、翌日のセッションで「もう一度」と言われたとき、前回の実行と比較できる必要があります。草稿が git リポジトリ内にある場合は、.first-reader/ を .gitignore に追加するとよいことを一度だけ伝えてください。

ステップ 0：範囲とジャンル

まず、時間を計った読書が、このテキストに実際に触れる状況をモデル化できるか判断します。

• 順番に読むことを想定した散文（エッセイ、記事、投稿、メモ、README の説明文、ランディングページのコピー、カバーレター、講演原稿）：ワークフロー全体を実施します。
• リファレンス資料（API ドキュメント、設定リファレンス、FAQ、変更履歴）：読者は拾い読みするのであって、通読するのではありません。時間を計った読書は省略します。主な作業としてスキムゲートを実施し、検索タスクを使います。質問を持つ読者を設定し、スキャナー表示から答えにたどり着けるかをテストします。ここでの成功条件は拾い読みのしやすさであり、欠点ではありません。
• 約 150 語未満（ツイート、プロフィール、告知）：分割フィードは使いません。新しいサブエージェント 1 つに、ペルソナを設定してテキストを予備知識なしで渡し、2 秒間の状況を想定してもらいます。最初に感じた反応、スクロールを止めるか、何を人に伝えるかを尋ねます。その後、信頼性の記録を作成します。リコールテストは省略します。
• フィクションと詩：書き起こしとリコールの作業は有効ですが、信頼性の記録と具体性の密度を測る読み方は、そのままでは当てはまりません。ニードルとメモリーだけを実施し、そのことを伝えてください。
• このスキルの対象外：コードレビュー、事実確認、コピー編集、書き直し。依頼を断り、適切なツールを案内してください。

ユーザーとの取り決めに従い、作業中は静かに進めます。最初に一言だけ伝え、重大な出来事があった場合に限り途中で一度だけ伝え、その後に結果を返します。ユーザーに見せる内容は、平易な言葉だけにしてください。

ステップ 1：読者を設定する

references/personas.md を読んでください。対象読者や掲載先が分からない場合は、ユーザーに「誰向けで、どこに掲載しますか？」と一度だけ質問してください。そのうえで、共感的なペルソナと懐疑的なペルソナを設定します。それぞれに、事前知識、状況、表の目安に基づく忍耐の予算、そして一文で表した利害関係を設定してください。利害関係を一文で書けない場合は、まずそのことを報告してください。

また、明らかでない場合は、読んだ後に読者に何を考え、感じ、またはしてほしいかを尋ねてください。これが、リコールテストで評価する意図された要旨です。

対象読者の確認が必要な場合にのみ、読み始めの一言に含めます（「HN のエンジニアとして読みます」など）。そうでなければ、そのまま始めてください。ペルソナを設定する前に、草稿の隣にある .first-reader/audience.json を確認してください（形式は references/room.md を参照）。ここには、作者がすでに選んだ読者と、そのイニシャル、簡単な人物像が記録されています。プロジェクト内のすべての草稿を同じ 2 人に読んでもらい、来月も「S」が同じ人を指すようにします。ユーザーが別の対象読者を指定しない限り、これを再利用し、最初の設定後に書き込んでください。独自に使うため、references/room.md に従って実行ディレクトリに manifest.json を書き込んでください。レビューを再実行する場合は、前回のマニフェストにあるペルソナ設定を再利用し、previous_run に前回の実行を指定して、結果を正直に比較できるようにしてください。

ステップ 2：ざっと読みの関門

懐疑的なペルソナを演じる新しいサブエージェントに、 scripts/skim.py <draft>を自分で実行させ、その視点だけから答えさせます。スクリプトを自分で実行しなければならない場合は、出力を一度も開かないファイルに直接リダイレクトしてください。スキャナーの表示には草稿の断片が引用されるため、読んでしまうと時間制限付きの読みの前に先入観が生まれます。答える内容は、これは何についての文章か、最後まで読むことを約束するか、そしてそれを決めた要素は何か、の3点です。

文章が何についてのものか説明できない、または読むことを約束しないスキャナーの反応が、最初の発見事項です。ほとんどの実際の読者にとって、この関門が文章との出会いのすべてです。

ステップ 3：時間制限付きの読み

先読みは、丁寧に頼むのではなく、仕組みで防ぎます。読者を一人でも割り当てる前に、フィードをバックグラウンドで起動してください。

python3 scripts/feed.py serve <draft> --run <run-dir> --readers keen,skeptic \
  --persona "keen=<one line>" --persona "skeptic=<one line>" \
  --ready-file <run-dir>/feed.json

テキストはそのプロセスのメモリ内にのみ存在します。feed.jsonに含まれるのはアドレスだけです。それを読み、各読者にはその読者自身の行だけを渡してください。読者への割り当てプロンプトには、ペルソナ、export READER_FEED=<reader-address>、3つのコマンドを含めます。草稿のパス、実行ディレクトリ、ほかの読者のアドレスは含めません。読者はfeed.py startを実行し、文章を一節ずつ読み進め、各段階でfeed.py next --log "needle=<-2..+2> expected... got... <felt notes>"を使って、感じたことを正直に記録します。needleは感じた反応を表します。+2は引き込まれている、0は中立、-1は集中が途切れる、または疑いを感じる、-2はもう読むのをやめる、です。ざっと読み始めたら、その時点で記録してください。ペルソナの忍耐が尽きたら、feed.py quit --log "needle=-2 <why the persona stopped>"で終了します。読者が行うことのうち、やめるという判断が最も多くの情報をもたらすからです。最後まで読み終えた読者も、同じ方法で最後の1行を記録します。記録上はQUiTではなくFINALと表示されます。

フィードは実際のログが記録された後にのみ次の一節を公開し、現在の一節以外を再表示することはありません。また、人がその一節を読める速さを超えて先に進むことを拒み、すべての読者が読み終えるまで文章の内容をディスクに書き込みません（feed.py progress --admin <admin-address>で読者の進捗を確認できます。読者が途中で終了した場合は、feed.py close --admin ...で早めに書き出せます）。読者サブエージェントは内容のある回答を返しません。成果物はセッションそのものです。終了後、feed.py transcript <run-dir>/<reader>で記録を取得してください。

サブエージェントを利用できない場合は、ファイルモード（feed.py start <draft> --session <dir>）を同じルールのもとで自分で使ってください。草稿を開く前に実行し、読者とレビュー担当者を同じ一人が務めたことを明記してください（「環境への適応」を参照）。

ステップ 4：記憶のテスト

共感的なペルソナのセッションに対して（懐疑的なペルソナも最後まで読み終えた場合はそのセッションにも）、scripts/recall.py <session-dir>を実行します。出力を、ほかのコンテキストを持たない新しいサブエージェントに渡します。そのエージェントは記録だけをもとに質問に答えます。内容の言い換え、指摘、最も印象に残った箇所、結末、中心的な主張、1つの行動について回答させてください。

回答をステップ1で意図した要旨と照らし合わせて評価します。1文での説明が主張と一致しない文章、あるいは誰も結末を覚えていない文章には、行単位の編集では直せない問題があります。「何も残らなかった」は読者についてではなく、文章についての発見事項です。

ステップ 5：信頼の台帳

scripts/signals.py <draft> --jsonを実行します。ただし、時間制限付きの読みが完了してからにしてください。出力には草稿の文が引用されるため、先に読んでしまうと先入観が生まれます。ジャンルを踏まえて数値を読み取ってください。コストのかかるシグナル（検証可能な数値、固有名詞、引用、利害に反する告白、一人称での経験）は信頼につながります。コストのかからないシグナル（どこにでもある曖昧な表現、どこにでもある断定、どんな文書にも当てはまる使い回し可能な文）は何の価値も生みません。認識上の確信度にほとんどばらつきがないと、機械のような自信として受け取られます。カウンターが示すのは最低値であり、真実とは限りません。特に告白の検出機能は過少に数えます。決まり文句のパターンに合う表現だけを検出し、「私たちのテストデータはでたらめでした」のような文を見逃すためです。したがって、コストのかかるシグナルはゼロという結果を鵜呑みにせず、ステップ6の自分の読みでも確認してください。

ステップ 6：まず自分で読み、その後レポートを書く

スクリプトでは判断できない2点を判断するために、この段階で初めて草稿全体を一度だけ読みます。暗示される書き手（この文章からどんな人物が想像されるかを述べ、その人物が文書の途中で変わる箇所があれば引用してください）と、書き起こしにある不満が作品のせいなのか、登場人物たちのせいなのかです。

references/report.md の指定どおりにレポートを書いてください。まず内容の言い換えと意味を述べ、次に読書の書き起こし、残ったもの、その背後にいる人物、そして中立的な質問と許可を得たうえでの意見を記します。全体を証言の文体にし、スコアは付けず、高度ルールを徹底してください。レポートは好意的な内容でもかまいません。

ステップ 7：ページを作り、読者がいつでも応答できるようにする

スキムゲートの回答を <run-dir>/skim.txt として保存し、その判定を注釈（skim）に記載します。references/room.md（scripts/room.py）に従ってページを作成します。草稿、各箇所に添えた読者のコメント、スキマーの判定、レンズ、ストリップを載せてください。修正は加えません。公開できる場所に公開するか、ランの隣に書き出して開きます。ユーザーとの約束に従って提出します。まず友人のレポート、次にリンクです。レルマン順のレポートは、希望する人が見られるよう、ランの隣に保存しておいてください。

読者はランディレクトリに保持されます。セッション内でその後に出てくる「質問」はすべて scripts/ask.py を通し、読者ごとに新しいサブエージェントを使います。読者の代わりに自分で答えてはいけません。また、読者に草稿を再び見せてはいけません。読者の記憶はログだけです。

環境への適応

このスキルは SKILL.md 互換のコーディングエージェントで動作しますが、3つの機能は環境によって異なります。ランを開始する前に利用できる機能を確認して、何も言わずに適応し、ユーザーには変更点だけを1行で伝えてください。

サブエージェント。 新しいエージェントを起動できる場合（Claude Code のエージェントツールや、その他の委任機能など）、読者ごとに1つ使います。できない場合は、読者役を1人ずつ自分で演じます。その場合は手順の順序が何より重要です。どんな理由があっても、読書を始める前に草稿ファイルを読んだり開いたりしてはいけません。まずフィードスクリプトを実行し、ペルソナになりきって、文章を一節ずつ読み進めます（ファイルモードを使います。読者とレビュー担当者が同じ頭で考える場合、提供モードに意味はありません）。懐疑的な読書は、共感的な読書とは別の後続パスで行います。全文を見る前に、書き起こしだけを頼りにクイズに答えて、記憶を確認します。新しい思考を持つ読者を使う実験よりも精度が低いため、判定で一度だけその旨を明記してください（「ここでは私が両方の読者を演じたため、結果はやや慎重に受け止めてください」）。それ以外では、そうでないかのように装ってはいけません。草稿がすでにコンテキスト内にある場合（セッション中に先に読んでいた、貼り付けられていた、またはハーネスが自動で読み込んでいた場合）、ソロモードでは盲検にできません。それでも読書は行いますが、役割ごとに正直に読み、針のような鋭いシグナルよりも、機械的なシグナル（終了ロジック、ログからの想起、signals.py）を重視してください。

ページの置き場所。 アーティファクト公開機能がある場合（claude.ai 上の Claude Code など）、ページは非公開リンクになります。ない場合は、ランの隣にローカルの HTML ファイルを作成し、ユーザーのために開きます。ページは読むものであり、クリックするものではありません。読者への質問はチャットで受け付けます。

ターン予算。 スクリプトを呼び出すたびに目に見えるツール手順が発生するエージェントでは、全体の実行に多くの手順が必要です。開始時の一言で、最初にその旨を伝えてください（「数分かかり、小さな手順がたくさんあります」）。手順ごとに許可を求めてはいけません。ハーネスで可能なら、まとめて実行してください。

セッション内でこのスキルを初めて実行する際は、開始時の一言でインターフェースについても簡単に説明します。他に説明の機会はないためです。「読者の立場で読みます。5分ほどかかります。戻ったら、各読者がどこで読み進め、どこで読むのをやめたか、何が心に残ったか、そして草稿の横にコメントを添えたページをお渡しします。読者に追加で質問することもでき、あなたが改稿した後に「もう一度」と言えば、読み直します。」

ガードレール

• 下書きの全部または一部を書き直してはならず、修正案の一覧を渡してもなりません。読者は自分に起きたことを報告し、文章についてのあらゆる判断は著者が行います。書き直しを求められたら、読者のコメントをユーザー自身の編集スキルに活用するよう提案してください。
• 所見を捏造してはなりません。問題のない書き起こしが2件あり、想起テストに合格したら、レビューは正直に終了します。
• 読者を責めてはなりません。作品に合わない参加者を選んでいたなら、参加者を選び直してやり直します。専門家向けの作品なのに懐疑的な読者が初心者だった場合、それは参加者選定の誤りであり、下書きの誤りではありません。
• 単語レベルの粗探しは対象外です。それを担当するのは別のスキルです。書き起こしで同じ表現につまずくことが続くなら、どのリストにその表現が載っているかではなく、つまずいた事実を報告してください。
• 書き起こしは証拠です。引用してください。それが置き換えるための抽象表現に要約してはなりません。