six-pager

/six-pager -- Amazon 形式のナラティブメモと PRFAQ

Amazon が 2004 年 6 月 9 日から採用している形式で、意思決定文書を作成します。この日、Bezos は PowerPoint を禁止し、すべての会議を文章形式のナラティブから始めるよう求めました。

このスキルが作成するのは文書です。規律に取って代わるものではありません。Amazon の本来のやり方では、1 週間かけて（下書き → レビュー → 寝かせる → 編集 → 最終版）作成します。このスキルは構成を簡略化しつつ、文章の品質基準は維持します。

これが効果を発揮する理由

互いに独立した 3 つの伝統が、ひとつの原則に行き着きます。文章を書くことは思考の道具であり、思考を記録することではありません。

• Bezos（Amazon、2004 年）： 「ナラティブ形式で構成された 6 ページのメモを書き、明晰に考えないということはあり得ません。」
• Strunk（1918 年、E.B. White が 1959 年に再掲）： 「力強い文章は簡潔です。文には不要な語句を、段落には不要な文を含めるべきではありません。これは、絵に不要な線がなく、機械に不要な部品がないのと同じ理由です。」（規則 17）
• Anthropic（Claude Code のベストプラクティス）： 「各行について、こう問いかけてください。これを削除したら Claude は間違えるでしょうか。そうでなければ、削除してください。」

同じルールを、行・文・指示という 3 つの尺度に適用します。このスキルは、そのすべてを徹底します。

兄弟スキルとの使い分け

スキル	用途	モード
/six-pager memo	重要な判断を伴う意思決定、戦略、状況報告、「〜すべきか？」	ナラティブメモ、6 セクション、厳格な 6 ページ上限
/six-pager prfaq	顧客の成果が問われる製品／機能／ローンチのアイデア	プレスリリース + FAQ 2 件、ローンチから逆算
長文の執筆／文体スキル	散文エッセイ、ナラティブ、感覚的な文章	長文の執筆。意思決定文書の構成ではありません
/council-review	複数の妥当な答えがある未解決の問い	複数エージェントによる審議。文書の生成ではありません
/adversarial-review	完成した成果物（シックスペイジャーも含む！）のストレステスト	単一批評者による攻撃モード

自然な組み合わせ： /six-pager で文書を作成し、/adversarial-review でストレステストを行い、/council-review で推奨案を審議します。これが Amazon 形式の意思決定プロセス全体です。

引数

• 引数 1（必須）： トピック、下書き、またはファイルパス。次のいずれかを指定します。
  • 短いトピック文："Should we migrate the API to cursor-based pagination?"
  • 既存の下書きへのパス：docs/pagination-decision-draft.md
  • 貼り付けたコンテキストのブロック
• モードフラグ（任意）： memo（意思決定の場合のデフォルト）または prfaq（ローンチの場合）。省略すると、スキルが自動分類し、確認を求めます。
• --silent-read: 出力に 20～30 分の「サイレントリード」シミュレーションを追加します。上級レビュアーが余白に書き込むような質問を添えた注釈付きの版を作成します。
• --strunk-only: 構成の生成を省略し、入力を既存の下書きとして扱い、Strunk と Anthropic に基づく文章監査のみを実行します。作成途中の文書を整理するのに便利です。

手順

フェーズ 1：SCOPE

1. $ARGUMENTS からフラグを解析します。
2. 入力を分類します。
   • トピック — 下書きのない短い文。ゼロから作成します。
   • ファイルパス — 既存の下書き。読み込み、出発点として扱います。
   • 貼り付けられたテキスト — コンテキストとして扱います。
3. モードフラグが指定されていない場合：
   • 自動分類：入力に「launch」／「ship」／「announce」／「new product」／「release」が含まれている場合は prfaq を提案します。それ以外の場合は memo を提案します。
   • 続行する前に、ユーザーに確認します。
4. 1 文でスコープをユーザーに確認します。「[トピック] の [memo|prfaq] を作成します。[任意：--silent-read が有効です。]」

フェーズ 2：下書き

モード：memo（6ページ文書）

標準の6つのセクションを作成します。各セクションには特定の目的と、厳格な文章作法があります。

1. はじめに（約0.5ページ） — この文書は何か。対象読者は誰か。求める判断は何か。1段落で意思決定の枠組みを示します。
2. 目標（約0.5ページ） — 具体的で測定可能な成果を示します。各目標は検証可能でなければなりません。可能な限り数値を含めます。
3. 基本方針（約0.5ページ） — この提案が最適化する原則を示します。限定表現は使いません（Strunk の「寄生語を避ける」という注意に従います）。基本方針は、留保のない約束です。形式：1. [方針名]: [単一の断定文。]
4. 事業の現状（約1.5ページ） — 現在のデータを示します。率直に、具体的な数値、システム名、日付のある事実を盛り込みます。Strunk のルール16（明確で、具体的で、実際的に書く）を徹底します。
5. 学んだ教訓（約1ページ） — 過去の試みから何を学んだか。今回は何が違うのか。各教訓では、抽象的な原則ではなく、具体的な過去の出来事や実験を挙げます。
6. 戦略的優先事項（約2ページ） — 推奨する行動とその根拠を示します。具体的なマイルストーン、担当者、スケジュールを含めます。
7. 付録（制限なし） — 図表、補足データ、検討したうえで却下した代替案（その理由を含む）。

（V2）プレモーテム（戦略的優先事項または付録に必須）。 12か月後にこの意思決定が失敗したと仮定します。失敗からさかのぼって、最も可能性の高い原因を3つ記述します。これは前向きなリスク発見の手法です。後ろ向きの「学んだ教訓」では構造上見落とされます。Kahneman が最も価値の高い意思決定手法として挙げているものであり、検証とも組み合わせられます。各プレモーテムの原因は、監視する項目に対応させてください。一般論の「リスク」ではなく、具体的な失敗シナリオを記述します。

厳守事項： セクション1〜6は、11ポイントの本文で合計6ページ以内に収めてください。このスキルはページ数を表示し、上限を超えた場合は警告します。

モード：prfaq（プレスリリース＋FAQ）

3つの文書を作成します。逆算して進めます。まず、製品がすでに発売されたかのようにプレスリリースを書きます。

1. プレスリリース（約1ページ） — 顧客向けの表現で、メリットを先に伝えます。（仮想の）発売日の日付を入れます。形式は Amazon 社内の PR 慣例に従います。
   • 見出し（1行、顧客が得られる成果を中心に）
   • サブ見出し（1行、対象者＋主なメリット）
   • リード段落（都市名、日付、「本日、XはYを発表しました……」）
   • 問題の段落（この製品が登場する前は何が難しかったか）
   • 解決策の段落（製品がその問題をどう解決するか）
   • 顧客のコメント（架空だが現実味のあるもの）
   • 社内のコメント（これが重要である理由について、チームからのコメント）
   • 行動喚起／提供状況
2. 社外向け FAQ（約1ページ） — ジャーナリストや顧客から寄せられる質問を扱います。
   • これは何ですか？
   • （明白な代替手段）と何が違いますか？
   • 価格はいくらですか？
   • いつから利用できますか？
   • できないことは何ですか？
3. 社内向け FAQ（約1〜2ページ） — Amazon 形式でリーダーシップから寄せられる質問を扱います。
   • なぜ今なのですか？
   • 成功とはどのような状態ですか？（具体的な指標、具体的な日付）
   • どのような依存関係がありますか？
   • どのような失敗モードがありますか？
   • 何を開発しないと決めていますか？
   • 何があれば、これを中止しますか？

PRFAQ の判定基準： 信頼できるプレスリリースを書けないなら、製品はまだ存在しません。少なくとも、重要な形では存在していません。

フェーズ3：制約を適用する

フェーズ2でドラフトを作成したら、分量を測定します。

# rough page count: assume 450 words/page at 11pt
WORDS=$(wc -w < draft.md)
PAGES=$(echo "scale=1; $WORDS / 450" | bc)

上限を超えた場合：

• memo の場合：最も長いセクションを特定し、重要な内容を保ったまま30％削減する案を提示します
• prfaq の場合：長くなりすぎた FAQ のサブセクションを特定し、質問の統合または削減を提案します

黙って切り詰めてはいけません。削減案とその理由を必ずユーザーに示します。

Phase 4：監査（Strunk + Anthropic）

草案の文章品質を監査します。指摘事項ごとにルールを示します。

チェック項目	ルール	対応
受動態	Strunk R14	受動態の構文をすべて指摘し、能動態への書き換えを提案します
曖昧な表現	Strunk R16	数値を伴わない「改善」「さまざまな」「いくつかの」「多くの」をすべて指摘し、具体化を求めます
不要な語句	Strunk R17 + Anthropic の削除可能性	冗長な表現（「するために」→「する」、「という事実により」→「ため」など）をすべて指摘します
限定語	E.B. White の「ヒル」の注意	「むしろ」「非常に」「少し」「かなり」「とても」「やや」をすべて指摘し、削除を提案します
並列構造	Strunk R19	リスト／信条／目標内で文法形式が一貫していない箇所を指摘します
文の長さの単調さ	Strunk R18	5語以内の長さの差に収まる文が4文以上続く箇所を指摘し、変化を提案します
トピックセンテンス	Strunk R13	主張が前置きの後ろに埋もれている段落を指摘します。各段落は要点から始めてください。1段落につき、論旨の1段階を示します。これは、ナラティブ形式のメモにおける中核的な規律です
誇張	E.B. White、『誇張しないこと』	無造作な最上級や、根拠を添えない誇張表現（「圧倒的」「革命的」「巨大な」「ゲームチェンジャー」など）を指摘します。たった一つでも読者を警戒させ、以降の内容への信頼を損なうため、数値を示すか削除を求めます
限定表現を含む信条	Bezos の原則	信条は確約です。「X の最適化を目指します」→「X を最適化します」、または削除
削除可能性のテスト	Anthropic	各段落について、削除すると読者が誤った判断をするかを確認します。そうでなければ削除します

構造化された監査レポートを作成します。

## Prose Audit (Strunk + Anthropic)

**Findings:** N critical, M important, K nit

### Critical (block the document)
- Line 23: passive voice in Strategic Priorities ("It was decided that...") → "We decided to..."
- Line 47: vague Goal ("improve performance") → demand a number
- Tenet 3 hedges ("We strive to be customer-obsessed") → cut "strive to" or cut the tenet

### Important (fix in next pass)
- 4 sentences in a row of 18-22 words in State of Business → vary
- Parallel-form break in Goals: 3 noun-phrase goals + 1 verb-phrase goal
- State of Business ¶2 buries its claim in the final sentence → lead the paragraph with it
- Overstatement in Introduction ("a massive, game-changing opportunity") → name the number or cut

### Nit
- "in order to" appears 3 times → "to"
- "various improvements" → name them or cut

Phase 5：提示

ユーザーに以下を提示します。

1. 最終文書（または --silent-read が指定されている場合は、監査注釈付きの草案）
2. ページ数と上限
3. 監査の概要（重大／重要／軽微な指摘の件数）
4. 監査で指摘した箇所について、原文の草案と書き換え案を並べて提示

次のように尋ねます。「監査の修正を適用しますか？（yes / partial / no）」

yes の場合：修正をその場で適用します（入力がファイルなら必要な箇所だけを編集し、そうでなければ新しい文書全体を表示します）。 partial の場合：各修正を個別に確認します。 no の場合：監査を適用していない草案を提示し、監査をスキップした旨を添えます。

Phase 6：保存

デフォルトの保存先：入力がファイルの場合はそのファイルと同じ場所、それ以外の場合は <cwd>/six-pager-<topic-slug>-<YYYY-MM-DD>.md。

--silent-read を使用した場合は、余白への質問を HTML コメントまたはコールアウトブロックで記載した <same-name>-annotated.md も作成します。

サイレントリードのシミュレーション（--silent-read）

Amazon の会議で使われている元来のプロトコルです。会議の開始時に文書を配布し（事前に読ませるのではありません）、20～30分間、ペンを手に黙読した後、ページや行への具体的な注釈をもとに議論します。

--silent-read を有効にすると、文書の生成後に、スキルが2回目の確認を行います。

各セクションについて、上級レビュアーが余白に書き込むような質問を2～4個作成します。例：

• 「23pct という数値の信頼度はどのくらいですか？実測値ですか、それとも推定値ですか？」
• 「信条2は信条4と矛盾しています。矛盾する場合はどちらを優先しますか？」
• 「教訓3には、以前の試みが X のために失敗したとあります。根拠は何ですか？」
• 「戦略的優先事項1には担当者が明記されていません。」

これにより、実際の会議の前に「書き手には明確でも、読み手には伝わらない」という問題を検出できます。

品質基準

以下のチェックがすべて満たされていれば、6ページ文書の合格です。それ以外の場合は、修正を繰り返します。

• ページ数が6ページ以下（メモの場合）、またはサブ文書として適切な長さ（prfaq の場合）
• すべての目標に数値、または具体的で検証可能な成果がある
• すべての信条が限定表現のない断定的な確約である
• 事業の現状に、1ページあたり少なくとも5つの具体的な数値／システム名／日付入りの事実が記載されている
• 戦略的優先事項ごとに、少なくとも1人の担当者が明記されている
• Strunk の監査で重大な指摘がゼロ（受動態、曖昧な目標、限定表現のある信条）。重要な指摘は、理由が説明されていれば許容されます
• 「どのような場合にこれを中止するのか？」という質問（PRFAQ 内部 FAQ）に、「パフォーマンスが低下した場合」のような曖昧な回答ではなく、実質的で具体的な回答がある

注意点

• 6 ページを超えないでください。 この制約そのものが価値です。収まらない場合は、まだ十分に考え抜かれていません。
• 「事業の現状」に背景説明を詰め込まないでください。 現在のデータのみを記載します。過去の経緯は「学んだ教訓」に記載します。
• 基本方針を曖昧にしないでください。 「試みる」や「努める」を含む基本方針は、基本方針ではありません。
• 架空の数値を生成しないでください。 目標に指標が必要で、ユーザーが提示していない場合は質問してください。「X%」のような一般的なプレースホルダーは認められません。
• 目標と基本方針を混同しないでください。 目標は成果（測定可能）です。基本方針は原則（取り組み）です。どちらも必要です。混同すると考えが曖昧になります。
• 監査を省略しないでください。 フェーズ 4 は任意ではありません。このスキルの要点は、文章の規律と構成の両立です。
• 自動保存しないでください。 フェーズ 6 では、どこに書き込むかをユーザーに確認します。
• 文章記事には使用しないでください。 専用の長文執筆／文体スキルを使用してください。このスキルは意思決定文書向けであり、エッセイ向けではありません。

変更履歴

V2（2026-05-27）

skillforge optimize によって最適化（成果の調査：意思決定メモの有効性と意思決定科学）。シックスペイジャーはすでに優れていたため、焦点を絞り、重複を避けて追加しました。

• メモモードで事前検証を必須化しました。前向きな「失敗したと仮定した場合、その原因は何か？」という失敗分析を行い、それぞれの原因を検証シグナルに結び付けます。後ろ向きの「学んだ教訓」では見落とされる点を補います。カーネマンが最も価値の高い意思決定手法として挙げたものであり、カウンシルレビュー V2 にも活用された、同じ意思決定科学の流れをくむものです。
• 成果目標：意思決定の後ではなく、前に致命的なリスクを明らかにするメモ。出典：カーネマン（事前検証）、Amazon のナラティブ手法（黙読、顧客起点）。同じ意思決定科学の流れ（事前検証、媒介評価）に基づいています。

参考資料

ベゾス／Amazon の主要資料：

• Bryar, Colin & Carr, Bill — Working Backwards: Insights, Stories, and Secrets from Inside Amazon（St. Martin's Press、2021）— 代表的な書籍
• Slab — ジェフ・ベゾスはいかにしてナラティブを Amazon の競争優位性に変えたか
• Maestra — Amazon の 6 ページ文書の書き方（テンプレート付き）
• Anecdote — Amazon の 6 ページのナラティブ構成はどのようなものか

ストランク＆ホワイトの主要資料：

• Strunk, William Jr. & White, E.B. — The Elements of Style、第 4 版（Pearson Allyn & Bacon、2000）
• ストランクによる 1918 年の原著（パブリックドメイン）：Bartleby — The Elements of Style

Anthropic の文章規律：

• Anthropic — Claude Code のベストプラクティス — 削除可能性テスト

認知スタイルに関する背景資料：

• Tufte, Edward — The Cognitive Style of PowerPoint（2003）— 箇条書きに反対する論拠

テスト

これはプロンプトのみのスキルです。付属の tests/eval.sh で構造上の要件を検証します。エンドツーエンドでの動作を確認するには、次の手順を実行してください。

1. 実際の意思決定を選びます："/six-pager Should we migrate the API to cursor-based pagination?"（メモモード）
2. 6 つのセクションがすべて生成され、ページ数が 6 以下で、指摘事項を含む監査が実施されたことを確認します
3. ローンチ案を選びます："/six-pager prfaq Acme AI assistant public launch"（PRFAQ モード）
4. プレスリリースと 2 つの FAQ が生成され、「何があれば中止するのか？」に具体的な回答があることを確認します
5. 既存の草稿に対して --strunk-only を実行し、監査のみが実行され、新しい構成が生成されないことを確認します
6. --silent-read を実行し、各セクションについて余白に記入する質問が作成されることを確認します