iamshadmirza/to-onepager

会話をワンページャーに変換する: 1つの主張、根拠に基づいた証拠、読みやすく追跡しやすい構成、設定済みの公開先。

入力: transcript のパス/貼り付け（指定された場合）; それ以外の場合は現在の会話。setup / reconfigure → config.md が存在する場合でもセットアップを実行。

設定: この SKILL.md の隣にある config.md（インストール先ローカル）。形状: config.example.md。

ページタイプ（ライブ）: research-finding | proposal。不明な場合は research-finding を優先。両方に該当する場合は一度だけ質問する。作成前に選択をアナウンスする。

ステップ

0. セットアップ

config.md がない場合、またはユーザーが再設定を依頼した場合:

1. 出力先を質問する: local | google-docs | confluence（正確に1つ）。
2. その出力先に必要なフィールドを収集する（config.example.md を参照）。Confluence には confluence_folder_url が必要。
3. このスキルディレクトリに config.md を書き込む。
4. この設定は今後のすべての実行に適用されることをユーザーに伝える。変更するには setup と入力するよう伝える。

完了条件: 既知の destination を持つ有効な config.md。セットアップのみの実行は、ワンページャーも要求されていない限りここで停止する。

1. マイニング

完全な入力を読む。作業用メモのみ（ユーザーには表示しない）:

• セッションの意図: 経験的主張か、意思決定の賭けか
• セッション全体が対応した質問または問題
• テストされた前提（修正点 / 変更された点を先頭に）
• 根拠のある事実（出典あり） vs 出典のない主張（中程度の確信度）
• 方法、限界、未解決の質問、次のアクション（製品/研究上の決定。ローカルな実行手順書ではない）

意図が research-finding 寄りの場合、さらに以下をキャプチャ:

• 説明メカニズムとそのカウント（支配的なシグナル、FP パターン、反実仮想）
• ユーザーが重要と強調した発見（「Key findings に入れて」）
• 実験? セッションが N 個の条件（キャップ、モード、スコープ、設定、A/B アーム）間で同じ測定を比較する場合、各条件と決定的なテーブル（スコアカード、ギャップ構成、等価性チェック）をリストアップ。fill: experiment とフラグを立てる。

意図が proposal 寄りの場合、さらに以下をキャプチャ:

• 問題 / 誰が困っているか、推奨される賭け、なぜ今なのか、アプローチ、代替案（出典があればそれも）、リスク
• セッションで議論された短期的な次のステップ

完了条件: 意図のシグナル、修正点、出典のある事実、ブランチ固有のメモがキャプチャされている。まだ解釈は行わない。

2. ルーティング

以下のカタログからページタイプを正確に1つ選ぶ。アナウンス: ページタイプ: …。

ページタイプ	使用する場合	もう一方を優先する場合
research-finding	証拠が「何が真実か？」に回答した場合	セッションが主に新しい証拠の少ない賭けである場合
proposal	セッションが賭け（問題、経路、理由、方法）を構成する場合	セッションが推奨される変更のない純粋な測定である場合

検証とアーキテクチャは後回しにする。セッションがそれらの形状のみである場合、どのライブタイプが最も近いか質問するか、停止する。

完了条件: 1つのページタイプが選択され、アナウンスされている。

3. 蒸留

ルーティングされたタイプのテンプレートをロードする（コンテキストポインター — そのファイルのみを読む）:

• research-finding → templates/research-finding.md
• proposal → templates/proposal.md

読みやすさのためにその骨格を埋める: 初めて読む人が数秒で主張を理解し、セクションごとに1つのスレッドを追えるようにする。

research-finding の埋め方パス

• デフォルト: 前提 → 結果 → 主要な発見（テンプレートのデフォルトの骨格）。
• 実験（マイニングで fill: experiment とフラグが立てられた場合）: テンプレートの実験骨格を使用する。アナウンス: 埋め方パス: 実験。
  • 発見の階段: 積み上げられた箇条書き（条件ごとに1つの判定）と、オプションのボトムライン。N 個の条件を1つの巨大な文に押し込まない。
  • 条件の前のコンテキスト（オプション）: Answer の後に、比較の側面と混同しやすい用語（例: タイプ vs インスタンス数）を説明する短いブロックを設け、テーブルが誤読されないようにする。Question だけでは不十分な場合にのみ使用する。How to read this のようなプレーンな見出しを推奨。不要な場合は省略する。必須のセクション名を発明しない。
  • 条件セクション: 条件ごとに1つのトップレベルセクション。各セクションは判定、次に分析。セクションのタイトルは、公平性または結果（例：「フェアな A/B: キャップ削除」）で付け、生のノブ（例：「MaxMessages = 100」）だけで付けない。共有可能な証拠は分析に置く（スコアカード、および/または同じ結論 / ギャップ構成のテーブル）。
  • 再現: 決定的/フェアな条件の下にネストする（例: マルチセッションチェック）。繰り返しのためにトップレベルの条件セクションを追加しない。
  • N 条件の実験を前提 → 結果 → 主要な発見に平坦化しない。

読みやすさ（すべてのページ）

• 具体的なものでリードする: タイトルと Finding は、数値、判定、または賭けで始める。コンテキストはその後。ページの冒頭にはしない。実験の場合、Finding が箇条書きの階段として stakes を保持してもよい。タイトルは、Finding が数値を保持する場合、比較を名前にしてもよい。
• 例の後に説明する: Results、Key findings、Analysis、How では、最初に測定された結果または選択されたパスを述べ、次に必要に応じて短いコンテキストを1行。
• セクションごとに1つの役割: 各見出しは1つの役割を果たす。セクションが2つのことを論じている場合は、分割するか削除する。
• Answer は、ページタイプを気にせずに初めての読者が使用できること: Finding（TLDR）/ Confidence / So what
• タイトルは主張（トランスクリプトに測定値がある場合はそれを含める。実験では数値を Finding に置いてもよい）。
• 推奨事項: セッションで議論されたアクションのみ。セッションが質問に回答しただけ（クローズドリサーチ、製品の賭けなし）の場合は、なし（または「研究完了: フォローアップなし」）と書く。次のステップ、ドキュメントの TODO、レビューアの宿題、または「〜1週間」計画を発明しない。
• ヘッダー: Owner、Go deeper
• Review セクションを存在させる

Owner: 実在の人物を特定する。Confluence 出力先の場合は、公開時に Atlassian メンションを使用する（publish.md）。それ以外の場合は表示名。不明な場合は質問する。TBD は先送りされた場合のみ。

完了条件: ルーティングされた骨格が埋められている（デフォルトまたは実験）; クロームが完了している; Owner が解決されているか明示的に TBD; タイトルと Finding が具体的な主張でリードしている。

4. グラウンディング

すべてのチェックに合格するまで修正して編集する。このステップは品質に関する唯一の真実の情報源である（テンプレートはこれらのルールを再記載しない）。

すべてのページ

• すべての事実のセル/箇条書きはトランスクリプトにトレース可能であること
• 未測定の大きさがないこと
• コールドリーダーの Answer がページタイプを読まなくても機能すること。Finding は TLDR であり、具体的な主張でリードすること（実験の Finding は箇条書きの階段でも可）
• タイトルは主張でリードすること（トピックやソフトなヘッダーではない）。実験の場合、Finding が stakes/数値を保持する場合は、タイトルで比較に名前を付けてもよい
• 本文はルーティングされたページタイプと一致すること（ハイブリッドな骨格は不可）
• セクションごとに1つの役割。説明と推奨の両方を行うセクションがないこと
• クロームが完了している（Owner、Go deeper）
• Go deeper / 推奨事項は、ローカルな実行手順書の乱雑さを含まないこと
• Confidence は証拠と一致すること。タイトルは（存在する場合）測定された数値と一致すること（または実験の階段の場合は Finding が一致すること）
• 1ページの予算: 散文で約600ワード。超過した場合は、最も重要でないアイデアを削除する（タイプを縮小したり、付録を詰め込んだりしない）。例外: 実験の決定的テーブル（スコアカード、ギャップ構成、等価性チェック）は予算に合わせて削除しない。代わりに、その周囲の箇条書きを短くする。
• Answer + 推奨事項でプレーンパス: 能動態、短い単語、不要な単語と専門用語を削除
• テンプレート風の橋渡しなし: 「今日の状況では」「ゲームチェンジャー」「これが重要な理由はこちら」、またはエンゲージメントのためだけに追加された締めくくりの質問などのフレーズを削除
• ソフトな要約なし: 推奨事項は Finding を言い換えない
• 発明されたフォローアップなし: 次のステップはトランスクリプトで議論された場合のみ。それ以外の場合、推奨事項は「なし」/「研究完了」
• すべてのセクションが何か新しいものを追加する。以前のセクションを言い換えるだけのフィラーを削除する

research-finding ページの場合

• Claim は測定された事実: トランスクリプトが示すことを超えた一般化や「可能性がある」は禁止
• Experiment fill: 適切なスパインを使用: 実験スパインのセクション構造（判定、分析、条件セクション、階段の箇条書き）を使用する。デフォルトのスパインを強制しない。
• 条件テーブル: 条件セクション内で使用され、ラベル付けされていること。文脈のない生の数値のブロックは禁止

proposal ページの場合

• Bet は意志の表明: 「〜すべき」または「賭け: X」
• Grounded: すべての代替案に証拠が添付されている（存在する場合）
• Next steps: 実際のアクション項目。議論されなかった「次に検討すべきこと」は禁止

完了条件: すべての品質チェックに合格。ページは依然として約600ワード。決定的テーブルはそのまま。