簡単に説明する

目標：読者が1分以内に重要なポイントを理解できること。画面上ではテキストの約20％しか読まれず、特に各行の先頭が読まれるため、重要な情報を最初に配置し、各見出しに内容を持たせます。

スタイルルール

すべてのモードで有効です。

最初の文で決定事項または回答を述べます。 コンテキストはその後です。
1文は25語以内、理想的には15～20語で、それぞれ1つのアイデアを持ちます。
主語、動詞、補語を能動態で、誰が何をするかを明確にします（「サーバーが再試行する」であり、「再試行される」ではありません）。
日常的な言葉を使います。 クライアント、セッション、通知、サーバー、データベースは問題ありません。関数名、ファイル名、変数名は使用しません。これらは詳細にあります。
具体的なケースは一般的な説明よりも価値があります。行為者、その行動、そしてその結果を示します。
内容のある見出し：「今日：通知が失われる」であり、「今日の状況」ではありません。最初の2語で、このテキストに固有の何かを伝えます。
冗長な表現や宣伝なし：「基本的に」「単に」「おそらく」「原則として」「堅牢」「パワフル」は避けます。
リストは並列的な項目にのみ使用し、ネストはせず、段落は最大3文とします。
**悪い点も伝えます：**受け入れられるリスク、代替案との比較、および対象外の範囲。

正確な形式と制限は、planningスキル（ステップ2、「簡単に言うと」）にあり、そのcheck-plan.shがチェックします。「決定」「今日」「今後」「リスク」、オプションで「新規」、「対象外」。

「今日」の各事実はその証拠にリンクし、「今後」の各結果はその段階にリンクします。

「新規」は、リポジトリ内でパターンを検索した後（rg）にのみ使用します。虚偽の「これは新しい」は、計画全体の信頼性を損なうためです。

課題のヘッダーは3行で、他のすべての前に配置します。完全な形式はgithub-issuesスキルにあります。

**何が問題か：** <行為者と影響、1文で>。      （または **何が求められているか：**）
**なぜ重要か：** <1文、数字またはケースを含む>。
**完了条件：** <主要な観測可能な結果>。

誰かが何かの説明を求めているが、文書は介在しない場合：

例：「支払いの再試行はどのように機能しますか？」

- 顧客が「支払う」をタップするとすぐに金額を引き落とします。
- 銀行が残高不足で拒否した場合、「支払いを再試行」と表示します。
- ネットワーク障害の場合は、最大3回まで再試行し、待機時間を増やします。
- 失敗した試行はすべて、理由とともに注文に記録します。

同上ですが、短い段落で。依頼された場合（「続けて話して」）または、前の項目を読まなければ項目が理解できない場合にのみ使用します。

改善前（理解しにくい）：

1. 現在の状況

RetryLinkは操作ごとにmaxRetries=3を適用します。これにグローバルな調整メカニズムがないことが加わり、インシデント時に負荷が大幅に増幅される可能性があります。

改善後：

決定： APIがダウンしている場合、アプリは再試行を停止します。

今日：障害が負荷を増幅する

各クエリは個別に3回再試行します。APIがダウンすると、復旧しようとしているまさにそのときに、3倍のリクエストを受け取ることになります。