concise-copy

簡潔なコピーコマンド

コピーやドキュメントを整え、文章を直接的かつ効率的にするため、以下を適用します。

ルール

• 不要な語句を削除する：「should」「must」「the process of」「the ability to」などを取り除きます。
• 動作や状態から始める：「- The system should support X」ではなく、「- X」とします。
• 直接的に書く：能動態を使い、簡潔に表現します。
• 冗長さを避ける：10語で表せる内容を3語で表せるなら、3語を使います。

承認に関する議論は、短縮ではなく削除を検討する

ドキュメントの中で最も冗長な箇所が、会話の記録である場合があります。誰が承認したか、何を検討して却下したか、やり取りを経てルールが決まった経緯などです。これは冗長さの問題ではなく、文章を短くするのは適切ではありません。approval-policy スキルに従えば、そもそもコミットするファイルに含めるべきでない場合があります。PR、issue、または決定事項へのコメントに記録するのが適切です。

該当する記述の例：approved by …、we decided …、we considered X but …、as discussed …、ルールを述べるのではなく議論の経緯を語る根拠説明の段落、以前の版を変更した理由を説明する注記。

人間がキーボードの前にいる場合、つまり直近のやり取りでメッセージを送り、今回の実行がそれへの応答である場合は、その箇所に手を加える前に確認してください。 選択肢を3つ示して尋ねます。その記述を削除する（tracker に残す）、まず tracker に移してから削除する、またはこのファイルが本来の記録場所なのでそのまま残す、のいずれかです。

人間がその場にいない場合は、質問せず、削除もしないでください。 長時間にわたる無人実行、スケジュールされたジョブ、多数のファイルを対象にした一括処理、人間とのやり取りを挟まずに別のスキルから続く処理などでは、回答者がいない質問で全体を止めるほうが、段落を残すよりも悪い結果になります。その記述はそのまま残し、見つけたものをすべて出力に列挙してください。人間が後で判断できます。

いずれの場合も、不要な語句として黙って削除してはいけません。 記録の情報量が減るように圧縮することは、このスキルが独断で行ってはならない唯一の編集です。記録を削除するかどうかは、どれだけ簡潔に書くかではなく、記録をどこに置くかの判断だからです。

例

変更前：

• インポート処理は、部分的なデータ状態（例：セッションはあるが、部屋の割り当てがない「Draft」フェーズ）をサポートする必要があります。

変更後：

• 部分的なデータ状態（例：Draft のセッション -> 部屋の割り当てなし）。