draft-in-voice

draft-in-voice — 記憶に根ざしたゴーストライティング

規約： conventions/brain-first.md を参照してください — 声のプロフィールと内容はすべてブレインから得ます。メモリーや 即興から作り出してはいけません。

規約： 引用とバックリンクのルールについては conventions/quality.md を、 また _brain-filing-rules.md を参照してください — 声のプロフィールは人物を主題とするページであり、people/ に保存します。

これは何か

特定の人物の声で、高い忠実度のゴーストライティングを行います。声の作業は 上流工程で完了しています。つまり、検証済みの声のプロフィールがすでにブレイン内の people/<slug>-voice（例：people/alice-example-voice）に存在し、このスキルはそれを 規律をもって 適用 します。記憶や即興で「創業者らしい声」や「本人らしい声」を 決してでっち上げず、必ずプロフィールを読み込み、その厳格なルールに従ってください。

検証済みのプロフィールがない場合、下書きの作成は 停止 します — 下記の声のプロフィールを作成するを参照してください。 声をでっち上げるより、尋ねるほうが適切です。

ユーザー自身の声は特別なケースです。 対象がユーザーで、ハーネスに 専用の個人用ボイススキル（独自のレジスター調整とアンチAIパターンを備えたもの）が 含まれている場合は、そちらを優先してください。検証済みのプロフィールがある ほかの人物 — 同僚、創業者、パートナー、ユーザーが代筆する相手 — には draft-in-voice を使ってください。また、専用スキルがない場合はユーザーにも 使用できます。

信頼できる情報源（毎回、最初に読むこと）

1. 検証済みの声のプロフィール — gbrain get people/<slug>-voice。フィンガープリント、 定量的な統計（中央値の長さ、語彙、リズム）、および「この人物として書く方法」の 指示ブロックが含まれます。これは必ず守ってください。 ページが存在しない場合、 または status が validated 以外の場合は、下書きの作成を中止してビルダーの付録に 進んでください。
2. 一次情報のコンテキスト — 対象者のメインページ（gbrain get people/<slug>）、およびタイムラインとバックリンク（gbrain timeline <slug>、 gbrain backlinks people/<slug>）：対象者が実際にどのように仕事を捉えているか、 その原点に至る経緯、独自の持ち味を確認します。単に話し方だけでなく、考え方にも 内容が忠実になるよう、内容 のために使ってください。
3. （任意）トピック固有のページ — 下書きが特定のアイデアや会社について書くものなら、 該当するページを取得してください（gbrain search "<topic>"、次に gbrain get <slug>）。 そうすれば、すべての主張が正確になり、作り話を避けられます。

厳格なルール（プロフィールから確認すること）

優れた声のプロフィールには、その人物が譲れないルールが記されています。プロフィールに 書かれた内容をすべて尊重してください。繰り返し登場する次の6つのカテゴリーを抽出し、 従ってください。

1. 避けるべき特徴。 ほとんどのプロフィールでは、最も見抜かれやすい特徴を1つ挙げています （多くの場合、emダッシュ、定型的な書き出し、句読点の癖です）。その特徴を含む下書きは 自動的に誤りです。
2. 長さのルール。 プロフィールに記載された中央値の長さに合わせます。短い投稿では 1つの考えだけを伝えます。削りましょう。
3. レジスターは混ぜずに選ぶ。 多くの人物には、カジュアルなレジスターと 主張・技術的なレジスターがあり、それぞれに異なるルール（大文字・小文字、絵文字、 スラング、専門用語）があります。下書きごとに1つだけ選び、決して混ぜないでください — 同じ行に絵文字と企業的な専門用語があると、不自然に見えます。
4. 特徴的な言い回し。 プロフィールに記された、その人物ならではの言い回しを 使ってください。
5. 禁止された定型表現。 プロフィールで禁止されているもの（ハッシュタグ、 「発表できてうれしいです」、1/n スレッド、特定の流行語）は使わないでください。
6. 世界観を内容に反映する。 内容には、その人物が実際に物事をどう見ているかを 反映させてください。

手順

1. 対象者を特定し、 people/<slug>-voice と brain 内の一次情報を読み込みます。検証済みのプロフィールがない場合は、執筆を中止し、プロフィールの作成を提案します（下記の付録を参照）。捏造してはいけません。
2. 文体と目的を確認します。 曖昧な場合は、カジュアル（チャットらしい雰囲気）か、ステートメント（ローンチ告知／技術情報）かを一行で確認します。返信はカジュアル、告知はステートメントをデフォルトとします。
3. 2～3案を作成します。 1案だけにしてはいけません。各案は簡潔にまとめます。文体は変えず、切り口を変えます。
4. 文体のセルフチェックを実施します（下記参照）。チェックに通らない箇所は、草案を提示する前に修正します。
5. 各案とセルフチェックの判定結果を提示します。 ここで行うのは草案の作成のみです。投稿や送信を決めるのは人間であり、通常の承認を必須とする手順を経て行います。これはエージェントが守るべき取り決めであり、機械的な保証ではありません。草案を送信処理に直接つなげてはいけません。

文体のセルフチェック（草案の提示前に実施）

読み込んだプロフィールに照らして各草案を採点し、基準に満たないものは修正してから提示します。

• 特徴的な言い回しのチェック： プロフィールで最も目立つ特徴的な言い回しを使っていないこと。使っていた場合は自動的に不合格です。
• 長さ： プロフィールに記載された範囲内で、できれば中央値に収めます。考えは一つに絞ります。
• 文体の一貫性： 一つの文体に統一し、混ぜ合わせません。
• 禁止された定型文がないこと： プロフィールで明示的に禁止されている表現を含めません。
• 一般的な文章ではなく、本人らしいこと： 本人の実際の投稿の間に自然に挟まる文章になっていますか。判断に迷った場合は、プロフィールの出典情報に記載されたコーパスから実際の投稿を近接するものから3件取り出し、文章のリズムを比較します。
• 内容が事実であること： 事実の主張はすべて、brain 内の実際のページまたは一次情報に基づいている必要があります。指標、顧客、具体的な情報を決して捏造してはいけません。本人が公にしていない限り、非公開の詳細は非公開のままにします。

文体プロフィールが不十分、または存在しない場合

その場で補ってはいけません。 次のどちらかを行います。

• 先にプロフィールを作成する（下記の付録を参照）、または
• プロフィールが存在しない、あるいは不十分であることをユーザーに伝え、参考にするための実際のサンプルの提供を依頼します。

記憶がなければ草案を作成しないという方針こそが、このスキルの要点です。文体にも brain を第一にする規律を適用します。

文体プロフィールの作成

このスキルの作成者向けパートです。プロフィールが存在しない、または検証されていないために草案作成が停止した場合や、ユーザーから「文体プロフィールを作成して」と依頼された場合に実行します。

ステップ 0 — 同意

ユーザーがこの人物のゴーストライティングを行う権限を持っていることを確認し、誰が、どの範囲について許可したか（例：「ツイートとローンチ告知。メールは対象外」）を記録します。同意の内容はプロフィールページ（下記のスキーマを参照）に記録します。同意が記録されていない場合、プロフィールがない状態での草案作成と同様に、プロフィールの作成を中止します。

ステップ 1 — コーパスを収集する（基準：20件以上のサンプル、6か月以上）

• 本人が書いた文章のみを使用します。 本人が公開した投稿、エッセイ、本人が書いたメール、本人が行った講演が対象です。第三者による人物評、報道記事、言い換えは決して使用しません。それらが捉えるのは評判であって、本人の文体ではありません。
• 最低基準：6か月以上にわたる20件以上のサンプル。 サンプルが少ないと一時的な気分に過度に適合し、対象期間が短いと文体の変化を捉えられません。基準に満たない場合、プロフィールは status: draft としてしか保存できません。この状態では草案作成は許可されません。
• 対象の形式をカバーします。 ユーザーがツイートを依頼する可能性がある場合、短い投稿を少なくとも5件含めます。ローンチ告知の場合は、ステートメント調のサンプルを少なくとも数件含めます。
• アップロードを依頼する前に、brain にすでに保存されている内容を確認します。gbrain search "<person name>"、gbrain backlinks people/<slug>、および media/ アーカイブを確認します。プロフィールの出典情報から実際のページを参照できるよう、まず通常の取り込みスキルを使って新しいサンプルを取り込みます。

ステップ 2 — 指紋を抽出する（スキーマは6つの基本ルールに対応）

コーパスを分析し、6つのカテゴリすべてを埋めてください。それぞれがプロフィールページのセクションになります。

指紋フィールド	抽出する内容
tells_to_avoid	最も目立つ特徴と、そのほかの特徴：句読点の使い方、定型的な書き出し、決して使わない構文。
length	実際の文字数から算出した、形式ごとの中央値と範囲（ツイート、返信、投稿、メール）。感覚ではなく実数に基づきます。
registers	それぞれ固有のルールを持つ、異なるレジスター（カジュアル／声明文／技術文）：大文字の使い方、絵文字、スラング、専門用語。
signature_moves	特徴的な構文、書き出し、リズム、繰り返し使われる言い回し。
banned_boilerplate	実際に使われたことがないと確認できるものすべて：ハッシュタグ、「発表できることをうれしく思います」、スレッドの番号付け、流行語。
worldview	分野を実際にどう捉えているか：立場、繰り返し述べる主張、重視すること。brain のページを引用してください。

ステップ 3 — プロフィールページを作成する

ファイルは people/<slug>-voice（_brain-filing-rules.md に従った人物を主題とするページ）に作成します。ページの内容を標準入力で渡し、gbrain put people/<slug>-voice を実行してください。必須のページ先頭メタデータブロック：

# Alice Example — Voice Profile

```yaml
subject: people/alice-example
status: draft            # draft | validated | stale — only `validated` unlocks drafting
profile_version: 1       # bump on every rebuild; prior versions via `gbrain history`
built_at: 2026-08-11
validated_at: null
validated_by: null
consent:
  granted_by: the user
  granted_at: 2026-08-11
  scope: "tweets + launch copy"
provenance:
  corpus_size: 26
  corpus_span: "2026-01 to 2026-08"
  sources:
    - media/x/alice-example/
    - writing/acme-example-launch-draft.md
```

## Fingerprint
### 1. Tells to avoid
### 2. Length discipline
### 3. Registers
### 4. Signature moves
### 5. Banned boilerplate
### 6. Worldview to channel

## How to write as this person
(the binding directive block the drafting half reads)

対象者のメインページからプロフィールへのバックリンクを追加してください（gbrain link people/alice-example people/alice-example-voice --link-type has-voice-profile または、利用環境における同等の add_link 操作を使用します）。

ステップ 4 — 検証する（ブラインドチェック）

プロフィールが status: validated になるのは、ブラインドテストに合格した場合のみです。

1. 指紋の抽出元ではない実際のサンプルを5件、除外しておきます。
2. プロフィールに基づいてテスト文を3件作成し、除外した実サンプルと混ぜます。
3. 混ぜたセットをユーザー（または対象者）に提示します。作成した文が目立たなければ、status: validated、validated_at、validated_by を設定し、それ以外は何も変更しません。目立つ場合は、どの特徴で見分けられたかを記録し、指紋を調整して再度テストします。

メンテナンス

• 古さ： コーパスの最新サンプルが約12か月以上前のもの、または本人の公開時の文体が明らかに変化した場合は、status: stale に設定して更新してください。古いプロフィールがあると、プロフィールがない場合と同様に、文章の作成は中断されます。
• バージョン管理： 再構築のたびに profile_version を増やし、ブラインドチェックを再実施します。gbrain history people/<slug>-voice が監査記録になります。

契約

このスキルでは、以下を保証します。

• ルーティングは frontmatter の正規トリガーと一致します。
• people/<slug>-voice に status: validated の文体プロフィールがない限り、文章の作成には決して進みません。プロフィールがない、下書き状態、または古い場合は、必ずビルダーに処理を引き継ぎます。
• リクエストごとに下書きの選択肢を2～3件提示し、それぞれ表示前に文体のセルフチェックを行います。
• 出力は下書きのみです。投稿や送信は、承認を経る経路で人間が判断します。
• このスキルが brain に書き込むのは、writes_to: に従い、people/ 配下に作成する文体プロフィールページと、そのバックリンクのみです。
• プライバシーに関する契約を維持します。例に実名を使わず、フォーク固有のファイルシステムパスを直接記載せず、上流フォークに言及しません。下書きで、対象者が公開していない個人情報を明かすこともありません。

出力形式

文章作成モード： ラベル付きの選択肢を2～3件提示します。それぞれにレジスターと長さを記載し、選択肢ごとにセルフチェックの判定（合格、または修正した箇所）を続けます。投稿、送信、brain への書き込みは行いません。

Option A (casual, 92 chars): ...
Option B (casual, 140 chars): ...
Option C (statement, 210 chars): ...

Self-check: A pass · B pass (trimmed to band) · C pass

ビルダーモード： 上記のスキーマに沿った people/<slug>-voice ページ（メタデータブロック＋6つの指紋セクション＋指示ブロック）と、コーパスの規模、対象期間、検証状況を示す1行の報告を出力します。

失敗した場合

gbrain のエラー code、終了コード、[AGENT] ブロック、通知ブロックについては、エージェントオペレータープロトコルに従ってください。このスキル固有の対応は以下のとおりです。

• 音声プロフィールに同意の記録がない場合、または status: draft の場合、このスキルは仕様上、下書きを拒否します。誰がどの範囲のゴーストライティングを承認したのか、ユーザーに確認してください。
• プロフィールページが page_not_found を返す場合、または縮退通知がある状態でコーパス検索結果が空の場合、一般知識をもとに下書きを作成しないでください。ユーザーに、音声の記憶が見つからない、または検索がキーワードのみだったことを伝えてください。
• プロフィールの保存で revision_conflict が返された場合は、再読み込みしてマージしてください。プロフィールは優先されるため、古い読み込み結果で上書きしないでください。

アンチパターン

• 記憶を頼りに声を即興で作る。 検証済みプロフィールがなければ、下書きは作成しません。例外はありません。
• draft／stale のプロフィールを十分だと見なす。 下書き作成が許可されるのは validated のみです。
• 文体を混ぜる。 下書きごとに文体は1つにしてください。混ぜると不自然に聞こえます。
• 内容をでっち上げる。 指標、顧客、具体的な情報を作らないでください。すべての主張はブレインのページにたどれる必要があります。
• 自動投稿する。 下書きを送信／公開の経路に接続すると、ゴーストライティングを安全にするための人間による確認手順を省いてしまいます。
• 本人について第三者が書いた文章からフィンガープリントを作る。 コーパスは本人が書いたものに限ります。
• 同意の確認を省く。 記録された承認なしにゴーストライティングを行うのは、支援ではなくなりすましです。
• 2～3案ではなく1案だけ作る。 選択肢が1つだけでは、文体と切り口のトレードオフがユーザーに見えません。

重複の整理（明確な境界）

• voice-note-ingest（skills/voice-note-ingest/SKILL.md）— ユーザーの音声を、正確な言い回しを保ったままブレインのページに取り込みます。これは音声をコンテンツとして記録するものです。draft-in-voice はプロフィールをもとに、特定の人物の文体で新しい文章を作成します。重なるのは「音声」という言葉だけです。投稿にする音声メモは、まず voice-note-ingest で記録し、その後 draft-in-voice で文体に合わせて書き直します。
• reports／briefing（skills/reports/SKILL.md、skills/briefing/SKILL.md）— ブレインの内容をエージェントの文体で要約します。draft-in-voice は、人間が自分の文章として公開するための、本人の文体によるコンテンツを作成します。誰かのフィンガープリントを模倣していない場合、このスキルには該当しません。
• ハーネスレベルのヒューマナイザー系スキル — あらゆる文章から、一般的なAIらしさを取り除きます。draft-in-voice は、検証済みプロフィールに基づいて、特定の人物1人のフィンガープリントを対象にします。名前が指定されていない対象について「AIらしさを減らす」ことは、このスキルには該当しません。
• media-ingest（skills/media-ingest/SKILL.md）— ビルダーの付録用にコーパスを収集する場合は、通常の取り込みスキルを使用します。このスキルは、取り込み後のページを読み取るものであり、一括取り込みは担当しません。