ce-noslop

冗長さのない文章を書く

AI らしさがなく、読者が一度読んだだけで理解でき、しかもソースに記載された事実をすべて残す文章です。この二つの目標は同時に満たす必要があります。AI らしさはなくても情報が詰め込まれた文章は不合格です。また、平易でも主張の確実性を変えてしまう文章も不合格です。

完了条件： このモードの出力が返され、入力に含まれる事実、数字、名前、引用、引用元がすべて維持され、ソースや呼び出し元から提供されていないものが追加されていないこと。

境界： ユーザーが修正対象として明示した場合を除き、コードブロック、引用文、フロントマター、リンク先、識別子、または呼び出し元自身の契約で維持が求められているトークンには手を加えないでください。テキストがモデルによって書かれたかどうかは決して述べないでください。依頼で求められた場合に限り、指定されたファイルをその場で書き換えてください。それ以外の場合は、テキストを返してください。

モード

指定があれば mode: トークンに従います。指定がない場合、下書きがなければ author、下書きに対する命令文があれば edit、下書きについての質問があれば detect とします。

• author. 呼び出し元が執筆している間は、以下のテストを適用し、何も返しません。内容を渡されて執筆を求められた場合は、同じテストに従って草稿を作成します。
• edit. テストに不合格となる文だけを書き換え、テキストを返します。合格した文はそのまま残すため、返したテキストに二度目の編集を加えても変更はありません。呼び出し元から変更点の説明を求められた場合に限り、書き換えたテキストの外側かつ成果物の外側に、変更点を一行だけ記します。
• detect. 見つかったパターンをそれぞれ挙げ、該当する行を引用し、簡潔に修正案を示します。書き換えは行いません。

edit と detect では、author でテストだけでは判断できない文章を扱う場合も、references/patterns.md を参照してください。英語以外のテキストには、テストのみを適用します。パターンカタログは、detect の指摘内容の中、および呼び出し元から求められた変更点の説明の中には適用されません。それ以外の場所には適用されます。

文体

読み手に合わせて選びます。呼び出し元とのやり取りに関する契約が、この節のどの記述よりも優先されます。

• ユーザーに話すエージェント。 読み手は、ドメインを理解しているものの作業を見ていないチームメイトです。その人に話しかけるように、一文ずつ書きます。
• リポジトリまたはチームの成果物。 中立的な文体にします。周囲のドキュメントの表現に合わせます。一人称は使わず、成果物に不要な意見も加えません。読み手が指定されていない場合は、この文体を使います。
• ユーザー自身の文章。 文体を保ち、必要最小限の編集にとどめます。わかりやすさのための編集は、ユーザーの語句を保ったまま文を分けることと、動作の主体を補うことに限ります。

テスト

author モードでは制約として、edit または detect モードでは確認項目として、すべての文に以下を適用します。

1. 仕組み。 その文は、対象が何をするかを述べていますか。それとも、どう感じられるかを述べていますか。感覚的な表現は、それが置き換えている事実に直すか、文を削除してください。
2. 移植性。 その文を別のプロジェクトにそのまま移せますか。移せるなら、このプロジェクトに関する事実が含まれていません。
3. 主体。 動詞の動作主は誰ですか。ソースに記載がある場合は、その主体を明記してください。主体が不明な場合や、明記しても意味がない場合は受動態のままにします。
4. 一つの考え。 読者は文の内容を理解するために読み返す必要がありますか。必要なら文を分けてください。一度で理解できる文は、どれほど長くてもそのままにします。
5. 情報密度。 パターンが一つあるだけでは何も証明しません。段落内に異なるパターンが三つ以上ある場合、または複数の段落で同じパターンが繰り返される場合は、指摘対象となります。
6. 結論を先に。 最初の文に、読者が必要とする結論がありますか。
7. 読者。 ドキュメントやコードを開かなくても、読者は行動できますか。識別子には説明を加えるか、結果を明示してください。

識別子、パス、コマンド、しきい値は正確に維持してください。表現の選択については、references/terminology.md を参照してください。