blog-post-writer

Nick Nisi ブログライター

生の素材を、Nick が仕上げる下書きに変えます。このスキルでは、調査、構成、文章をつなぐための prose を作成します。公開できる一人称の文章は作成しません。

このスキルが守るルール

事実はログから得られます。感情は得られません。

以前のバージョンのこのスキルで作成された記事は、読者から AI の粗悪な文章だと言われました。事実は申し分ありませんでした。実際のタイムスタンプ、実際のコミット統計、実際の Slack の引用が使われていました。問題は、Nick の内面まで生成していたことです。何を考え、何を想定し、何に心を動かされたか。そうした主張が9つあり、出典があったのは1つだけでした。読者は必ずしもそれを言葉にできませんが、違和感を覚え、記事を信頼しなくなります。

数値で見ると、その記事における内面の状態への言及は1,000語あたり5.84件で、Nick のコーパス平均である0.97件を大きく上回っていました。6倍の頻度です。Nick は主に、自分が何を作ったかについて書きます。その下書きは、作ったものについてどう感じたかを書いていました。

以下のすべては、そこから導かれます。

プロセス

1. 生の素材を集める

散らかったままでも受け入れます。断片的な考え、コード、コマンド、結論、リンクなどです。整理を求めてはいけません。

素材が少ない場合は、掘り起こします。セッションログ、Slack、git の履歴、リポジトリそのものなどです。これはパイプラインの真の強みなので、遠慮する理由はありません。すべての事実に出典を記録してください。 主張 → 出典を記した作業ファイルがあれば、下書きの信頼性を保ち、ステップ5を機械的に進められます。

2. 掘り起こせない部分をインタビューする

このスキルで最も価値の高いステップです。省略しないでください。

ログに記録されるのは Nick が何をしたかです。何を考えたかは決して記録されません。ask_user_question または通常の文章で、狙いを定めた質問を8〜15個し、回答を一字一句そのまま記録します。

• 「X が起きたとき、実際にどう思いましたか？」
• 「Y をやめた本当の理由は何ですか？ きれいにまとまった理由ではなく、本当の理由を教えてください。」
• 「誰かと議論したくなるのは、この件のどの部分ですか？」
• 「本当は書きたくないけれど、自分が間違っていた点は何ですか？」

急いで入力し、推敲しないよう伝えてください。推敲されていない回答が、記事の声を支えるすべての文の生の素材になります。平坦で、留保が多く、具体的な回答になるでしょう。その平坦さこそが声です。 なめらかに整えてはいけません。

インタビューを断られた場合は、本人の内面を描く箇所に [NICK: ...] マーカーを入れて記事を仕上げます。それは正しい結果であり、失敗ではありません。

3. 説明ではなく、コーパスを読む

src/content/posts/ にある最近の記事を2〜3本、全文で読みます。新しいものから順に読み、さらに類似したトピックの記事があれば読みます。要約ではなく、それらの記事に沿った文章をつなぐ prose を書きます。

次に references/voice-tone.md を読みます。これは、目指すべき特徴の一覧ではなく、上限と禁止事項の一覧になっています。特徴を指定すると、モデルはそれが当てはまるたびに実行します。それが、8つのセクションからなる記事に格言めいた文が8つ生まれた原因です。安全に指定できるのは制約だけです。

4. 素材から構成を作る

事実の中にすでにある時系列や論旨を見つけ、それに沿って進めます。

物語のフレームワークを選んではいけません。 references/frameworks.md は、すでに存在する下書きについて話し合うための診断用語として存在します。埋めるテンプレートではありません。フレームワークを選ぶことは、出来事が何を意味したかを決めることです。それは Nick が決めることであり、ツールが決めることではありません。完璧に実行された Story Circle は、このスキルが生み出しうる成果物の中で最も見抜かれやすいものです。記憶をもとに書く人間が、それを作り出したことはないからです。

構成に関する指示は、ただ一つです。記事の核となる転換点を一つ特定し、それが伝わるように事実を並べ、それ以外の箇所はすべて平坦に保ちます。

セクション見出しは説明的なものにします。トピックの名前を付けます（「Fleet とは」「単独ではどれも信頼できない3つのシグナル」）。暗示的な物語の節目を示す見出し（「漂流」「帰還」）は章タイトルのように読めます。大量に使うと、それが手がかりになります。

5. 見栄えのしない初稿を書く

情報は網羅し、修辞は抑えます。平坦さを目指してください。

Nickは、平易な文章に語り口を加えるのが得意で、巧みな文章からパスティーシュを取り除くのが苦手です。すでに完成したように聞こえる初稿は、彼に渡すものとして最悪です。彼はそれと格闘しなければなりません。明らかに彼の手が必要なものを渡してください。

下書き中の厳守事項：

ルール	理由
心理状態についての文は、手順2からの逐語的な引用、または [NICK: what were you actually thinking here?] マーカーに限る	根本的な失敗です。タグのない内面の捏造は即失格です。
各セクションは情報で終えること。事実、数値、コマンド、あるいは単にそこで終わる形にします	格言めいた締めくくりが8つ並ぶのは、このテンプレート特有の輪郭です。
すべての数値の出典をたどれること	「好奇心の12分間」は、人生を物語化するために作り出された、根拠のない精密さでした。
継続して使う比喩は、投稿全体で最大1つ	3つ以上のセクションにまたがって繰り返される比喩は、フレームワークの痕跡です。
語り手による進行の指示を入れない	「では、次に何が起きたか見てみましょう」は、Nickが決して司会を務めない投稿を仕切っているようなものです。

修辞的なひねりを加えたくなったら、代わりに平易な文を書き、さらに工夫する価値があるかどうかはNickに判断してもらってください。

6. 構造ゲートを実行する — Nickに読ませる前に

python3 scripts/slopcheck.py \
  --corpus '/Users/nicknisi/Developer/nicknisi.com/src/content/posts/*.md*' \
  --draft path/to/draft.mdx

このゲートはNickの実際の投稿を基準に調整されており、両方向の外れ値を検出します。**抑制しすぎることも、過剰と同じくらい疑わしいものです。**指標を回避するように作られた初稿は、その指標を一度も意識しなかった初稿とは違って見えます。

ゲートの役割は、初稿を認定することではなく、Nickが書き直す箇所のリストを作ることです。指摘された箇所を直してから、引き渡してください。

内面描写のセクションは必ず出力され、コーパスとの比較採点は行われません。確認されていない主張が残っている間は、終了コードが0以外になります。一人称の主張が未確認のままでも構造上は問題のない初稿は、合格ではありません。その部分はあなたではなく、Nickに確認してもらいます。

語彙チェック（tighten-prose スキル）は最後に実行され、重要度は最も低いものです。「delve」や「leverage」のような2024年頃の特徴的な語句を検出しますが、スロップの特徴が最大限に表れた初稿でも通過してしまいます。この書き直しのきっかけとなった投稿でも、実際にそうなりました。

7. 公開せず、引き渡す

以下を提出します。

1. 平坦な初稿
2. 内面描写のリスト — 彼の内面を主張するすべての文。書き直すか削除するかは彼に判断してもらいます
3. ゲートの出力
4. 未解決の質問

**Nickが読んで承認していない一人称の文を含む投稿を公開してはいけません。**この成果物の編集者は彼ではありません。その半分について、彼だけが情報源です。

出力形式

フロントマターのスキーマとファイル規則については、references/post-template.md を参照してください。

同梱リソース

• references/voice-tone.md — コーパスから測定した基準値とともに、許容範囲と禁止事項を記載しています
• references/post-template.md — フロントマターのスキーマと構造のひな形
• references/frameworks.md — 完成した初稿を批評するための診断用語
• scripts/slopcheck.py — コーパスに合わせて調整された構造検出ツール