book-mirror

Name: book-mirror
Author: garrytan

github.com/garrytan生産性31.3k222 回インストール今日更新

book-mirror について

book-mirrorは、EPUBまたはPDFの各章の分析を、読者のgbrain内の経験と照らし合わせた脳ページを作成するスキルです。CLIが読み取り専用のサブエージェントで章ごとに分析し、一般的な要約ではなく個人の経験とのつながりを重視します。

主な機能

01書籍の章を抽出して分析
02章ごとに読者の脳を検索
03章の考えを個人の経験に結び付ける
04読み取り専用サブエージェントで分析
05結果を脳ページにまとめる

活用シーン

01心理学書を個人の振り返りと関連付ける
02ビジネス書を仕事の経験と照らし合わせる
03章ごとの個人向け読書ノートを作る

MCP 対応

CLIはサブエージェントに`get_page`と`search`による脳の読み取り専用MCPアクセスを許可します。その後、結果をまとめて`put_page`で1ページを書き込みます。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/garrytan/gbrain --skill book-mirror

インストール後、Claude Code で/book-mirrorを入力して読み込まれたか確認します。

同梱ファイルrouting-eval.jsonl

詳細

book-mirror — パーソナライズされた章ごとの書籍分析

規約： このスキルが配置されている media/<format>/<slug> の特例として認められている規則については、_brain-filing-rules.md を参照してください。

規約： 引用ルール、バックリンクの徹底、出力品質の基準については、conventions/quality.md を参照してください。

規約： コンテキスト収集フェーズでたどる検索順序（brain → search → external）については、conventions/brain-first.md を参照してください。

これは何をするものか

書籍（EPUB または PDF）を入力すると、各章の詳細な要約を片側（「章の内容」）に、読者自身の実生活をもう片側（「鏡」）に対応させた brain ページを作成します。brain にある読者自身の言葉、状況、人物、パターンを用います。出力される brain ページは media/books/<slug>-personalized.md です。

これは一般的な書籍の要約ではありません。価値を生むのは「鏡」です。読者の生活を深く知っている気の利く友人が、余白に気づきを書き込んでくれているような読み心地を生み出します。「鏡」の役割は、読者に「まさに自分のことだ」と気づかせ、その後は引き下がることです。ユーザーが単なる要約を求めている場合は、別のスキルを案内してください。

信頼に関する契約（実行前にお読みください）

book-mirror は CLI コマンド（gbrain book-mirror）として実行されます。エージェントがツール経由で呼び出す純粋な Markdown スキルではありません。信頼できる実行環境は CLI であり、このスキルはその周辺のオーケストレーション手順を記述するものです。

エージェントにとって、これは次のことを意味します。

CLI は読み取り専用のサブエージェントジョブを N 個（章ごとに 1 個）送信します。各サブエージェントに許可されているツールは ['get_page', 'search'] のみです。put_page や、変更を加える操作は呼び出せません。最終メッセージで Markdown 分析を生成します。
CLI は各子ジョブの job.result を読み込み、最終ページを組み立て、オペレーターの信頼に基づく単一の put_page で書き込みます。
つまり、信頼されていない EPUB/PDF のコンテンツから people/* ページに対するプロンプトインジェクションはできません。信頼範囲を限定する仕組みはスラグのプレフィックス層ではなく、ツールの許可リストにあります。

パイプライン

1. ACQUIRE   → User has the EPUB/PDF locally (manual; book-acquisition is
               not currently shipped — see "Acquiring the book" below).
2. EXTRACT   → Pull chapter text from EPUB/PDF into one .txt per chapter.
3. CONTEXT   → Gather everything the brain knows about the reader.
4. ANALYZE   → `gbrain book-mirror` fans out N read-only subagents.
5. ASSEMBLE  → CLI reads each child result and writes one put_page.
6. PDF       → Optional: render via skills/brain-pdf for delivery.

1. 書籍の入手

法的にグレーなダウンローダーである book-acquisition は、このスキルの今回の提供範囲には意図的に含めていません。ユーザーが EPUB/PDF を手動で配置します。ユーザーが使用する可能性のある一般的なパスは次のとおりです。

# User-supplied path
ls path/to/book.epub
ls path/to/book.pdf

# Or already in the brain repo (recommended for tracking)
ls $BRAIN_DIR/media/books/

gbrain の設定（gbrain config get sync.repo_path）から $BRAIN_DIR を解決するか、ユーザーから受け取ってください。

2. テキストの抽出

目標：一時ディレクトリに章ごとの .txt ファイルを 1 つずつ作成します。エージェントは shell と python にアクセスできます。CLI はこの後の処理を担い、抽出済みのディレクトリを入力として受け取ります。

EPUB

SLUG="this-book"                                # kebab-case
WORK="$(mktemp -d)/$SLUG"
mkdir -p "$WORK/chapters"
unzip -o path/to/book.epub -d "$WORK/unpacked"

# Find content files (XHTML/HTML), sorted (chapter order = sort order)
find "$WORK/unpacked" -name "*.xhtml" -o -name "*.html" | sort > "$WORK/files.txt"

# Strip HTML to text per chapter
python3 - <<'PY'
from bs4 import BeautifulSoup
import os, sys
work = os.environ['WORK']
files = open(f'{work}/files.txt').read().splitlines()
for i, path in enumerate(files, 1):
    html = open(path, encoding='utf-8', errors='replace').read()
    text = BeautifulSoup(html, 'html.parser').get_text('\n')
    text = '\n'.join(line.strip() for line in text.splitlines() if line.strip())
    with open(f'{work}/chapters/{i:02d}.txt', 'w') as f:
        f.write(text)
PY

bs4 が見つからない場合：pip3 install beautifulsoup4 lxml。

章ファイルを調べ、実際の章と前付け（目次、著作権、謝辞）を見分けます。EPUB では章ごとに 1 ファイルが用意されていることが多いですが、複数の章が 1 ファイルにまとめられている場合もあります。head -5 "$WORK/chapters/"*.txt を使ってサンプルを確認してください。

PDF

pdftotext -layout path/to/book.pdf "$WORK/full.txt"

次に、awk または python を使って章見出し（「Chapter N」、「CHAPTER N」、またはすべて大文字のタイトル行）を目印に分割します。PDF がスキャン画像で埋め込みテキストがない場合は、skills/brain-pdf または別のビジョンツールを使って OCR に切り替えてください。

品質チェック

各章ファイルについて：

単語数が 1500 を超えていること（一般的な章の範囲は 2k～8k 単語です）。
HTML タグがないこと。
段落が \n\n で保持されていること。

参照用に、章番号 → タイトル → ファイル → 単語数を対応付けた chapters/INDEX.md を保存してください。

3. コンテキストの収集

ここが最も重要な手順です。「鏡」の質は、各章のサブエージェントに渡すコンテキストの質に左右されます。

何を取得するか

テンプレート: USER.md と SOUL.md — ユーザーが管理している場合 (gbrain はテンプレートを templates/USER.md と templates/SOUL.md に同梱しています。内容が入っている場合は brain リポジトリ内に存在します)。全文を読みます。
最近のデイリーメモリ — 直近 14 日分の brain ページのうち wiki/personal/reflections/ 配下、またはユーザーがデイリーノートを置いている場所にあるもの。
書籍のテーマに合わせたトピック関連の brain 検索:
- 結婚に関する書籍なら gbrain query "marriage"、gbrain query "couples therapy"。
- ビジネス書なら gbrain query "founders"、gbrain query "fundraising"。
- 心理学書なら gbrain query "shame"、gbrain query "anger"。
関連エンティティの brain ページ — 登場しそうな人物について gbrain query "<name>" を実行します。
定着しているパターン — ユーザーのリフレクションやオリジナルの中で繰り返し現れているもの。

深い検索 (デフォルト — 任意ではない)

薄い静的なコンテキストパックは、ありきたりなミラーの最大の原因です。品質の上限は brain そのものであり、1 つのファイルに手作業で詰め込まれたものではありません。CLI を呼び出す前に、セクションごとの検索を行ってください:

書籍をセクション (章、部、またはテーマ単位) に分割します。
各セクションについて、そのセクションで著者が述べている内容に基づいて 15〜20 件の的を絞った brain 検索を生成します。
それらの検索から上位の brain ページを取得します。
取得した素材を章ごとにグループ化してコンテキストパックに折り込み、各章のサブエージェントが自分のセクションに対応するページを参照できるようにします。

クエリ生成戦略 (セクションごと):

文字どおりのテーマ一致 — 著者は文字どおり何について語っているか？
心理的な類似 — これは読者の人生におけるどのパターンに対応するか？
具体的な出来事の探索 — 著者が描写していそうな日付のある出来事は何か？
人間関係・人物の類似 — 読者の人生の誰がこれに対応するか？
時間的な類似 — 読者の人生のどの時期が最も近いか？

実行:

gbrain query "QUERY" --limit 3
gbrain get "PAGE_SLUG"

予算: セクションごとに 15〜20 件の検索 × N セクション、さらに 40〜60 件のページ全体の取得。すべてローカル DB クエリなので、実質無料です。取得する brain コンテキストは合計 50〜80K 文字を目標とします。章のサブエージェントは実行時に読み取り専用の search + get_page ツールも持つため、コンテキストパックは下限であり上限ではありません。ただし、オーケストレーションのパスがすでに見つけたものをサブエージェントに再発見させることに頼らないでください。

重要なミラーに必要な最低限の取得素材:

すべてのセクションを通じて 40 件以上の brain ページを取得。
読者自身の発言からの 10 件以上の直接引用 (brain ページからの逐語)。
可能であれば、日付のある出来事と繰り返し現れるパターン。
人生の領域を横断するカバレッジ: ジャーナルとリフレクション、仕事と創造的な成果物、人間関係、公共・市民生活、具体的な喜びの瞬間、文化的アイデンティティ — 最も重い素材だけでなく。

コンテキストパックを組み立てる

CLI が読み取れる単一のファイルにすべてを書き出します:

CONTEXT="$WORK/context.md"
{
  echo "## USER.md (if any)"
  [ -f "$BRAIN_DIR/USER.md" ] && cat "$BRAIN_DIR/USER.md"
  echo
  echo "## SOUL.md (if any)"
  [ -f "$BRAIN_DIR/SOUL.md" ] && cat "$BRAIN_DIR/SOUL.md"
  echo
  echo "## Recent reflections (last 14 days)"
  # Pull recent daily reflections — adapt to the user's filing scheme
  # ...
  echo
  echo "## Topic-relevant brain pages (grouped per chapter)"
  # Deep-retrieval results from above, grouped by the chapter they serve
  # ...
  echo
  echo "## Themes & cruxes"
  # A 1-page summary, written by the agent, calling out:
  # - What's currently active in the user's life that this book intersects
  # - Specific quotes from the user that map to book themes
  # - People and dates that should appear in the mirror
  # - The anti-repetition constraints (domain map + phrase caps, below)
} > "$CONTEXT"

これを密にしてください。すべての章のサブエージェントがこれを読みます。反復防止の制約 (次のセクション) をここにエンコードしてください。章ごとの領域割り当てとフレーズ上限は、すべてのサブエージェントがそれらを参照できる場合にのみ機能します。

品質システム (厳格なルール)

これらのルールは、クロスモーダル評価との反復を通じて獲得されたものです。すべての book-mirror にとって必須です。

原則: Chapter の半分こそがバリエーションのエンジン

最も重要な教訓はこれです: 豊かな章の要約が多様なミラーを生み出します。素材を圧縮すると、ミラーは自身の最大のヒット作以外に反応する対象を持ちません。2 つの半分は共生関係にあり、スペースを奪い合うものではありません。

ルール: 著者が提示するすべての異なるアイデア、ストーリー、フレームワーク、番号付きリスト項目、記憶に残るフレーズは、それぞれ独自のセクションを持ちます。著者が 6 種類の孤独を挙げれば、それは 6 つのセクションです。3 つのストーリーを語れば、それは 3 つのセクションです。Chapter の半分は、誰かが本を飛ばしてもあまり失わないほど詳細であるべきです。Mirror の半分は、それぞれの具体的なアイデアに対して、異なる個人的なマッピングで応答します。

レイアウト：上揃えの HTML テーブル、またはセクションを縦に並べる（厳守）

単独の | The Chapter | The Mirror | という Markdown のパイプテーブルを出力してはいけません。GitHub（およびほとんどのレンダラー）は、テーブル行のセルの高さを同じにし、短いセルのテキストを垂直方向に 中央揃え します。そのため、左右の文章量が異なる場合（必ず異なります）、一方の列は上部に空白のブロックを残したまま下にずれてしまいます。プレーンな Markdown では、セルごとに垂直方向の配置を指定できません。根本原因はこれであり、見た目の細かな問題ではありません。

有効なコンテナーは 2 種類あります。どちらも正しいので、用途に応じて選んでください。

上揃えの HTML テーブル（CLI のデフォルト）。 gbrain book-mirror の章プロンプトでは、すべての <td> に valign="top" を指定した HTML <table> を使うようすでに定められており、これは信頼されたランタイムに組み込まれています。手作業でミラーを作成または修正する際に知っておくべきこと：GitHub は valign="top" を保持しますが、インラインの style="vertical-align" は削除します。また、raw <td> 内の Markdown の強調表現はレンダリングされません。強調表現は <em>／<strong> に変換し、セル内の段落区切りには <br><br> を使ってください。
セクションを縦に並べる — モバイルやチャットでの配信に最適であり、手作業で組み立てるあらゆるミラー（子ども向けバリアント、古いページの遡及的な修正など）に適した方法です。
```
### Chapter N: <title>

**The Chapter**

<chapter prose, normal paragraphs separated by blank lines>

**The Mirror**

<mirror prose, normal paragraphs separated by blank lines>
```
テーブルのセル以外では、<br><br> ではなく、実際の空行で段落を区切ってください。どの場合も冒頭から冒頭へと読めるため、配置の不具合は発生しません。Chapter／Mirror という命名と、アイデアごとに 1 セクションを設けるという豊かさのルールは変わりません。変わるのはコンテナーだけです。

繰り返しの防止（雰囲気ではなく、厳格な制約）

「もっと変化をつける」という指示ではうまくいきません。LLM は与えられたカードの束を組み替えるだけです。カードが 6 枚なら、N 回繰り返しても出てくるのは 6 枚です。コンテキストパックの「Themes & cruxes」セクションに、厳格な制約として明記してください。

ドメインの割り当て： 執筆前に、各章の主要な人生の領域を 1 つ割り当てます（キャリア、家族、市民活動、創作活動、特定の人間関係、子ども時代、知的活動、精神的な実践など）。隣り合う章で主要な領域を共有してはいけません。
フレーズの上限： テーマの要となる単語やフレーズが、4 つ以上の章に登場してはいけません。制約がなければ全体を占めてしまう、読者にとっての「定番」（支配的になりそうな 5～6 個のテーマ）を特定し、明確な上限または禁止事項を設定します。
ストーリーの重複排除： 各ミラーを書く前に、次の点を確認します。「このストーリー／出来事／引用を、以前の章ですでに使っていないか？」使っている場合は、別のものを探してください。
感情の幅に関する要件： 章の少なくとも 25% は、喜び、ユーモア、創作への高揚感、または勝利に当てはまる必要があります。傷や苦労だけを扱ってはいけません。著者が何か美しいものを描写したなら、ミラーでも読者の人生に美しいものを見つけてください。

編集上のルール（最重要ルール）

深い情報検索は原動力であり、成果物そのものではありません。読者に、研究論文や検索結果のページを読んでいるように感じさせてはいけません。ミラーは、読者を深く理解している人が書いた、優れたエッセイのように読めるべきです。下調べをしたことを証明するレポートのようになってはいけません。

判定基準： 引用と出典の記載をすべて取り除いても、ミラーを読んだ人は自分を理解してもらえたと感じるでしょうか？ひらめきが生まれるでしょうか？独立した文章として成り立つでしょうか？そうであれば、情報検索は目的を果たしています。ミラーが引用に頼らなければ成り立たないなら、情報検索は失敗です。

引用： 任意です。出典が本当に価値を加える場合（「19 歳のときにこれを書いた」という言葉は、読者が日記の記述を実際に読んだとわかると、受け取り方が変わります）は、脚注として控えめに使ってください。ただし、引用を主役にしてはいけません。ミラーを、徹底ぶりを見せつけるような文章にしてはいけません。

クロスモーダル評価ゲート（重要度の高いミラーに推奨）

ミラーを生成した後、次のカスタム評価軸を使って gbrain eval cross-modal（または skills/cross-modal-review/SKILL.md に記載されている手動ゲート）を実行します。

VARIETY（各章で新鮮さがあるか？）
SPECIFICITY（実際のストーリー／日付／引用があるか？）
DEPTH（プロフィールの言い換えではなく、新たな洞察があるか？）
LEFT_COLUMN_FIDELITY（本の内容を忠実に保っているか？）
EMOTIONAL_RANGE（苦労だけでなく、喜びもあるか？）

gbrain eval cross-modal --slug <slug>-personalized \
  --dimensions VARIETY,SPECIFICITY,DEPTH,LEFT_COLUMN_FIDELITY,EMOTIONAL_RANGE

合格基準：すべての評価軸がモデル間で平均7以上であること。いずれかの評価軸が6未満の場合は、対象を絞った修正を加えて再構築します。評価→修正→再評価のサイクルが品質を大きく高めます。評価モデルの組み合わせと拒否時のルーティングは、conventions/cross-modal.yaml に従います。

児童書向けの形式

絵本や児童書（約5,000語未満）には、標準的なミラーの代わりに保護者向け読書ガイドの形式を使います。

章の半分：各ページ／見開きで本が述べていること。
ミラーの半分：読み聞かせをする保護者向けに書きます。各ページがどのように感じられるか、年齢ごとに子どもがどんな質問をするか、質問されたら何と答えるか、そして簡単な言葉の裏で本が本当に教えていることを記します。
含める内容：読むタイミング、具体的な反応への対応方法、発達心理学の研究に照らし合わせた本のより深い構造。
トーン：温かく実用的で、読者の子どもの名前と年齢（脳のコンテキストから取得）に合わせた具体的な内容にします。

このような手作業で組み立てる形式では、積み重ねセクションのコンテナを使います。

4. 分析：`gbrain book-mirror` を呼び出す

gbrain book-mirror \
  --chapters-dir "$WORK/chapters" \
  --context-file "$CONTEXT" \
  --slug "$SLUG" \
  --title "Book Title Goes Here" \
  --author "Author Name" \
  --model claude-opus-4-7

CLI は次の処理を行います。

入力を検証し、章ファイルを読み込みます。
コスト見積もり（Opus で1章あたり約$0.30）を表示し、確認を求めます。
読み取り専用の allowed_tools を使って、N個の子サブエージェントのジョブを送信します。
すべての子エージェントの完了を待ちます。
各子エージェントの job.result（Markdown形式の分析テキスト）を読み込みます。
すべての章を、フロントマター＋導入＋章ごとのセクション＋締めくくりを含む1ページにまとめます。
media/books/<slug>-personalized.md に put_page を1回だけ書き込みます。
標準出力にJSONエンベロープを出力します： {"slug": "...", "chapters_total": N, "chapters_completed": N, "chapters_failed": 0}。

章が1つでも失敗すると、CLI は終了コード1で終了し、ユーザーは再実行できます。冪等性キー（book-mirror:<slug>:ch-<N>）がキューレベルで完了済みの章を重複排除するため、再試行のコストは低く抑えられます。本の引用を原文のまま再現し、さらに読者の言葉も原文のまま再現すると、プロバイダーの出力フィルターに引っかかることがあります。その場合、ブロックされた章は失敗として扱われます。再実行するか、別の --model で再試行してください。

モデル：デフォルトは Opus

デフォルトモデルは claude-opus-4-7 です。Sonnet も使えます（--model claude-sonnet-4-6 を使用）が、ミラーの品質は明らかに低下します。分析を読者をよく知る人が書いたように感じさせる細やかな表現には、Opus グレードの推論が必要です。

コストゲート

TTY ではないコンテキストでは、--yes を指定しない限り CLI は支出を拒否します。CI／スクリプトから実行する場合は、明示的に --yes を渡す必要があります。TTY のユーザーには、送信前に [y/N] プロンプトが表示されます。

深い検索を行うと、薄い静的コンテキストパックと比べて総コストが大幅に上がります（Opus の料金では、およそ1桁増）。読者にとって大切な本であれば、品質の向上にはその価値があります。重要度の低い実行に限り、静的パックを使ってください。

5. PDF（任意）

ブレインページを書き込んだ後（CLI がすでに put_page を実行しています）、skills/brain-pdf を使ってPDFに変換します。

# See skills/brain-pdf/SKILL.md for the invocation.

ユーザーが成果物を求めている場合、生の Markdown を送るよりPDFを優先してください。ブレインページが信頼できる唯一の情報源であり、PDFが持ち運び可能な成果物です。

6. 事実確認と相互リンク

ページを公開したら、読者に関する事実の記述（親、きょうだい、結婚歴、仕事、ルーツ）を事実確認してください。よくある誤りのパターンとして、次の点に注意します。

読者の親の関係と、親戚を含む家族全体に見られるパターンを混同する。
読者の親が今も一緒にいるのに、「親の離婚後……」といった経歴を作り上げる。
子どもの人数や年齢、配偶者・子ども・きょうだいの名前を間違える。

記述を確認できない場合は削除してください。誤りを持ち込むくらいなら、細部を減らすほうがよいです。

分析で言及した人物に相互リンクを追加します。

ミラーが脳に関するページを持つ人物に言及する場合は、その人物の people/<slug> から新しい media/books/<slug>-personalized ページへのバックリンクを追加します（conventions/quality.md の鉄則に従います）。

品質基準（基準）

章のパートでは、次のことを満たしてください。

著者自身の体験談、統計、フレームワーク、事例を忠実に残す。
印象に残る言い回しは、原文どおりに引用する。
読者が本を読まなくても大半の内容を把握できるほど、詳しく書く。

ミラーのパートでは、次のことを満たしてください。

コンテキストパックにある、読者自身の実際の引用文を使う。
具体的な日付、状況、実名を挙げる。
読者の人生を深く知っている、頭の切れる友人のように、指示を出すのではなく、気づいた点を伝える。
観察に徹し、指図はしないでください。 ミラーは読者に自分を映すものです。どうするかは読者が決めます。指示も、行動項目も、「〜すべき」も、「〜かどうか検討してみて」も、読者の人生を組み替える提案もありません。
つながりを、観察やさりげない気づきとして表現します。「これは、あのときと同じパターンですね」や「ここには、あのときの響きが聞こえてくるようです」などです。「ここに対処する必要があります」や「このフレームワークを第3四半期の計画に適用してください」などとは書きません。
直接当てはまることは、率直に述べます（「これはまさに、実際に起きたあの状況です」）。
当てはまらない場合も、正直に述べます（「この章は、〜なので、直接関係する部分が少なめです」）。無理に関連づけないでください。
心に響くものであり、行動を促すものではありません。 ミラーの役割は、認識してもらうことであり、指示を出すことではありません。「まさに、今私たちがやっていることだ」と思ってもらえれば成功です。「これを改善するための7項目の計画はこちらです」は踏み込みすぎです。
チーム向けのミラーの場合： 文脈を示すためにチームメンバーの名前を挙げます（「これは、あるチームメイトの行動とつながっています」）。タスクを割り当てる目的では決して使いません（「チームメイト：金曜日までにXを実行」）。チームが決めていない組織の方針、拒否権の連鎖、チェックリスト、構造上の決定を作り上げないでください。チームの実際の文書に記載されている決定だけに言及します。それ以外は、質問や観察として表現します。

文書全体を通して、ひとつの一貫した語り口を保ち、一般的な人物像ではなく、読者の実際の生活に合わせ、特定の読者にとって本の捉え方が当てはまらない点も正直に示してください。読者に、研究対象ではなく、自分を見てもらえたと感じさせる必要があります。また、引用をすべて取り除いても、読み物として成立する文章にしてください。

アンチパターン（次のことはしないでください）

❌ 章を流し読みする。 常に詳細を維持してください。
❌ 型にはまった反映。 「これまでにこんなふうに感じたことがあるなら、当てはまるかもしれません……」→ 見つけ次第、削除してください。
❌ 読者の生活について事実を誤る。 組み立てた後は、必ず事実確認してください。
❌ サブエージェントに put_page へのアクセスを与える。 信頼の前提は読み取り専用です。書き込みは CLI が行います。
❌ 無理に関連づける。 章が当てはまらない場合は、率直にそう伝えてください。
❌ 反映の中で、おもねったり説教したりする。 「〜すべきです」や「〜を検討してください」、あるいは「そろそろ〜する時期かもしれません」は使わないでください。
❌ コンサルタントモード。 反映は戦略資料ではありません。アクション項目、名前を挙げた人へのタスク割り当て、でっち上げた方針や組織構造、「四半期ごとに監査する」、番号付きの実施チェックリストは含めないでください。反映は観察し、共感を呼び起こすものです。「この部分、私たちらしいね」とバーで友人が語りかけるようなものであり、コンサルティング案件ではありません。読者が観察を計画に変えたいなら、それは読者自身の判断です。私たちがすることではありません。
❌ 読者が一度も述べていないルールをでっち上げる。 拒否権の連鎖、編集とマーケティングの分離、オンブズパーソンの体制、キャンペーンのチェックリストなど、読者が定めていないものを反映が断言してはいけません。著者なら尋ねるであろう質問（「ここで拒否権を持つのは誰ですか？」など）として提示するか、含めないでください。
❌ 章の前半だけで終わらせる。 本の実際の内容を残す必要があります。これは品質上の最大の失敗です。章が豊かであれば、反映にも多様性が生まれます。
❌ Markdown のパイプ表をそのまま使う。 GitHub やほとんどのレンダラーでは、セルの幅が不均等な場合に中央揃えが崩れます。すべての <td> に valign="top" を指定した HTML の <table> を使うか、セクションを縦に並べてください。上記のレイアウトに関する必須ルールを参照してください。
❌ すべての章で同じ 5〜6 個のテーマを繰り返す。 品質システムのドメインマッピングと表現の上限を活用してください。
❌ 情報が乏しいコンテキストパック。 コンテキストパックが USER.md の箇条書きだけなら、反映は型にはまったものになります。検索と取得を深く行ってください。
❌ 重要度の高い反映で評価ゲートを省略する。 最低限、自己チェックを行い、各章における重要なテーマへの言及数を数えてください。いずれかのテーマが 3 章を超えて登場する場合は、納品前に修正してください。

出力チェックリスト

契約

このスキルが保証すること：

ルーティングが frontmatter の標準トリガーと一致する。
該当する場合、writes_to: に記載されたディレクトリ内に出力を書き込む。
参照される規約（quality.md、brain-first.md、_brain-filing-rules.md）に従う。
プライバシーに関する契約を維持する。実名、フォーク固有のファイルシステムパスのリテラル、上流フォークへの言及を含めない。

完全な動作契約は上記の本文セクションに記載されています。このセクションは適合性テストのために設けられています。

出力形式

スキルの出力形式は、本文の該当セクション（「Output」、「Brain page format」など）に記載されています。ここにあるセクション見出しは、適合性テスト（test/skills-conformance.test.ts）のために設けられています。

エラーが発生した場合

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

CLI が費用確認のために停止した場合（終了コード 3、または --yes を指定していないときに TTY 以外の環境で拒否された場合）：章ごとの見積もりを伝え、--yes を追加する前にユーザーの同意を待ってください。
ユーザーが設定した費用上限により、有料の実行が no_pricing で停止した場合：モデルのトークン単価を調べてユーザーに伝え、同意を得た後、brain ホストのオペレーターに gbrain pricing set <model> --input <usd-per-1M> --output <usd-per-1M> を実行するよう依頼してから再試行してください。
chapters_failed > 0 で終了コード 1 になった場合：完了済みの章は保持されます。同じコマンドを再実行して失敗した章のみを再試行し、残りの未完了の章数をユーザーに伝えてください。

アンチパターン

アンチパターンの全一覧は本文の該当セクションにあります。本文で異なる大文字・小文字表記が使われている場合に備え、この見出しは適合性テスト用に設けられています。

Markdown 対応

ログインしてコメント

基本情報

作者: garrytan
リポジトリ: garrytan/gbrain
カテゴリ: 生産性
インストール数: 222
GitHub スター: 31,312

問題を報告