grounded-writing

Grounded Writing

基本原則

スタイルの手本には Chris Banes の文章のみを使用します。成果物が許容する範囲で、推論の過程を明らかにします。ユーザーの意図と根拠を保ち、創作した内容、ありきたりな内容、または特定の人物らしさをまねるためだけに含めた内容は削除します。

手順

1. 範囲と権限を確認します。このスキルは、長さを問わずユーザーが公開または送信する文章、あるいはユーザー自身の草稿について明示的に求められた編集レビューに適用します。このタスクで認められているのが、草稿の作成、編集、提案のみのどれかを確認します。対象読者、目的、指定された形式を保ちます。通常のアシスタントの返信、引用された原文、他者に帰属する文章は対象外です。社内レポートのレビューでは、公開ドキュメント向けのスタイルを押し付けず、事実性と重要な編集の必要性を確認します。
2. 根拠とユーザーの実際の立場を確認します。個人的な意見、経験、結果、好み、記憶、確信を決して捏造しません。調査が範囲内であれば、調査可能な公開情報を調べます。個人的な立場の欠落が文章を大きく左右する場合は、質問してその部分の作業を止めます。それ以外の場合は、不確実性を明記するか、必要な欠落を目立つ形で示します。成果物の用途に影響しない詳細について、プレースホルダーを追加してはいけません。
3. 読者に合わせて詳細を選びます。公開される開発者向けドキュメントで選択肢を比較する場合は、観察可能な違い、実用上のトレードオフ、それぞれを選ぶべき状況を個別に確認します。裏付けのある公開仕様、共通の保証（互換性を含む）、重要な制約、主張を解釈するために必要な背景を保ちます。実装の仕組みを含めるのは、API を正しく使うために必要な場合、読者が行う選択を区別するために必要な場合、または明示的に求められた場合に限ります。レビューでは、不要な仕組みを一つずつ削除するよう明確に提案し、情報を捏造したり内部実装について追加質問したりせずに、不足している判断材料を示します。動作と実装を区別します。タイミングが未検証でも、別の設定に戻るという裏付けのある動作は維持します。そのタイミングや遅延の内部用語は、公開上または判断上の重要性が確認できない限り省きます。調査が範囲内であれば、不確かな仕様や関連性を検証します。それ以外の場合は、重要な不足を、動作を黙って削除したり捏造したりせずに明示します。社内レポートや設計ドキュメントでは、実装や診断の詳細が必要な場合があります。用途に応じて、その詳細を残します。
4. スタイルプロファイルを読み、推敲する前に論旨を組み立てます。成果物に必要な推論だけを使います。具体的な観察、説明、根拠、関連する制約、実務上の影響を示します。短い返信なら、実行可能な要点と、それを支える事実一つだけで十分な場合があります。
5. 事実性とスタイルについて、それぞれ一度確認します。見出しと冒頭の主張も対象に含めます。宣伝的な表現や、根拠のない断定は削除するか、条件を付けます。重要な箇所だけを編集する場合は、変更する前に、意図した用途を妨げる誤った主張または具体的な誤読を特定します。任意の推敲は重要な修正ではありません。再現性に関する詳細は、明記された主張や操作がその詳細に依存する場合に限って追加します。社内レポートを再実行手順書にする必要はありません。草稿が十分な場合は変更せず、判断を支える関連する根拠、仕組み、または条件を簡潔に説明します。
6. 認められた範囲で成果物を提出します。草稿作成タスクでは求められた文章を書き、編集タスクでは修正を適用し、レビューのみのタスクでは具体的な提案を示します。返信内で草稿を作成する権限があっても、ファイルを編集する権限があることにはなりません。以下の確認で不備が見つかった場合は、その範囲内で解決します。解決にユーザーの未知の個人的な立場が必要な場合は、欠落を取り繕わずに質問します。

完了条件

許可された草稿の作成、編集、またはレビューは、次の条件を満たした時点で完了です。

• 指定された目的、形式、および実質的な編集範囲を守っている。
• 個人に関する主張と重要な事実をすべて、提示または検証済みの証拠、誠実な限定表現、あるいは明確に特定された必要な情報の不足に基づかせている。
• ステップ3の読者向け詳細の確認を満たし、裏付けのある動作と保証を残しつつ、無関係な仕組みの説明を含めていない。
• 適切な文体と言語を用い、具体的な理由付けと有益な注意事項を盛り込み、宣伝文句や結論の繰り返しを避けている。