improve

改善

すべての基準を満たすまで、各ステップでスコアによる評価を行いながら出力を反復的に改善します。これにより、「より良いかどうか」が主観的になることを防ぎます。

モードの選択

タスクに関わる独立した観点の数を数えて、モードを選択します。単純な依頼に完全な反復プロセスを適用すると時間が無駄になり、複雑な依頼で構成を省くと、方向性の定まらない変更につながるためです。

クイックモード

改善の中心となる観点が1つだけ明確な場合に使用します。たとえば、「この関数を高速化する」「この段落を短くする」「書式を修正する」などです。ユーザーの依頼自体が、単一の基準を示しています。

1. 基準を明示する — 明白に思えても、基準をはっきり述べます（例：「目標：実行時間を短縮する」）
2. 読み、理解する — コードの場合はファイルを読みます。文章の場合はテキストを読みます。内容を把握せずに改善しないでください。
3. 改善する — 変更は1つに絞ります
4. 変更前と変更後を示す — コードの場合は差分または並列表記を示します。文章の場合は、変更点とその理由を説明します。
5. 確認する — 「これで目的を達成できていますか。それとも続けますか？」

エスカレーション： ユーザーが「続けて」と言った場合、または2つ目の懸念を示した場合は、フルモードに切り替えます。現在の基準を第1基準として引き継ぎ、新しい基準を追加して、現在の出力を反復0として評価します。これまでの作業は無駄になりません。

フルモード

タスクに2つ以上の独立した観点がある場合、優先事項が競合する場合、ユーザーの依頼が曖昧な場合（「整理して」「より良くして」など）、またはユーザーが明示的に反復的な改善を求めている場合に使用します。

1. 入力を受け取る
2. 測定可能な基準を1～3個、優先順位を付けて設定する
3. ベースラインを評価する（反復0）。その後、1回につき1つの目標に絞って反復的に改善する
4. 各反復で、改善 → 評価 → ユーザーへの確認 → 判断（続ける／終了する）を行う
5. 反復の履歴をすべて含めて、最終的な出力を提示する

分野別のヒント

出力の種類によって、改善のパターンやワークフローは異なります。「より良い」とは何かを状況に応じて考え、どのように改善に取り組むかを決める際の出発点として活用してください。厳格なルールとして扱う必要はありません。

コード

観点： 可読性、パフォーマンス、正確性、テスト網羅率、慣用的なスタイル
ワークフロー： まずコードを読む → 問題を特定する → 変更する → 差分を示す → 利用可能であればテストを実行する。パフォーマンスを改善する場合は、計算量の変化（例：O(n²) → O(n)）を説明します。可読性を高める場合は、新しいバージョンがより分かりやすい理由を説明します。

文章

観点： 明瞭さ、簡潔さ、語調、構成、対象読者への適合性
ワークフロー： 全文を読む → 構成や明瞭さに関する問題を特定する → 修正する → 変更点とその理由を説明する。簡潔さが目標の場合は、修正前後の単語数を示します。

データ／設定

観点： 正確性、完全性、一貫性、スキーマへの準拠
ワークフロー： スキーマまたは想定形式に照らして検証する → 不足や誤りを特定する → 修正する → 追加・変更・削除した内容を示す。設定の場合は、ハードコードされたシークレットや過度に許可の広い設定など、セキュリティ上の問題も確認します。

デザイン／ビジュアル

観点： 配置、階層、アクセシビリティ、レスポンシブ対応
ワークフロー： マークアップやスタイルを確認する → 視覚的な階層やアクセシビリティに関する問題を特定する → 修正する → 視覚的な影響を説明する。

基準を設定する際は、ユーザーが気付いていない可能性のある、分野に関連する観点も提案してください。

質問をする

利用可能な場合は、回答の選択肢が予測できる質問にはoptions配列を付けて、AskUserQuestionを使用してください。利用できない場合は、choicesを付けてask_userに切り替えてください。どちらも利用できない場合は、通常のテキストで質問してください。方法よりも、質問することが重要です。

基準の推定

ユーザーに基準を尋ねる前に、リクエストから基準を推定してみてください。ユーザーは「基準」という言葉を使わずに、求めていることをそのまま伝えることがよくあります。

• 「もっと速くして」→ パフォーマンス（クイックモード）
• 「わかりにくくて長すぎる」→ 明瞭さ＋簡潔さ（フルモード、基準はすでに2つ提示されています）
• 「きれいにして」→ あいまいなので、ユーザーにとって「きれい」とは何かを尋ねます
• 「この README を改善して。オンボーディングに時間がかかりすぎる」→ 実際の基準は README の見た目ではなく、オンボーディングの速度です

基準を推定できる場合は、最初から尋ねるのではなく、確認してください。「[X] と [Y] に重点を置きます。それでご希望に合っていますか？」と尋ねれば、やり取りを1往復減らせます。

基本ルール

1. 少なくとも1つの基準なしに改善してはいけません。 クイックモードでも、ユーザーのリクエストには基準が含まれています。それを明示してください。
2. 必ず改善前と改善後の両方を採点してください（フルモード）。各イテレーションにスコアカードを付けます。
3. 1回のイテレーションにつき、焦点を絞った目標を1つ設定します。 密接に関連する変更はまとめてもかまいませんが、単一の改善目標に貢献する必要があります。無関係な変更を複数行うと、何が効果をもたらしたのかわからなくなります。
4. 最も大きなギャップから取り組みます。 他の基準が未達のまま、達成済みの基準を磨いてはいけません。
5. 後退を検出します。 以前に達成した基準の評価が下がった場合は、続行する前に元に戻すか修正してください。
6. 適切なタイミングで終了します。 すべての基準を達成した場合、3回のイテレーションで進展がない場合、合計10回のイテレーションに達した場合（目安）、またはユーザーから終了の指示があった場合です。
7. ユーザーによる確認は重要です。 各イテレーションの採点後、スコアカードを簡潔に共有し、その評価に同意するかユーザーに確認してください。自己採点には見落としがあります。ユーザーの視点こそが判断の基準です。

ワークフロー（フルモード）

詳細な採点基準、スコアカードの形式、優先順位のルール、完了条件については、references/EVALUATION-GUIDE.md を参照してください。

1. 受け取る — 入力（既存の成果物または未加工のリクエスト）を受け付けます
2. 基準を設定する — 測定可能な評価基準を1〜3個抽出するか、ユーザーに尋ねて優先順位を付けます
3. ベースラインを記録する — 最初の出力を作成し、採点します（イテレーション0）
4. 改善する — 最も大きなギャップを対象に、焦点を絞った変更を1つ行います
5. 評価して確認する — 新しい出力を採点し、スコアカードをユーザーと共有して、認識が一致しているか確認します
6. 判断する — 続行、終了、または基準の調整を行います
7. 成果物を提示する — すべてのイテレーション履歴とともに、最終出力を提示します

ステップ1 — 受け取る

入力を受け取り、取り組む対象を把握します。

• 既存の成果物 — ユーザーがコード、テキスト、またはファイルパスを提示します。作業を進める前に、内容を十分に確認してください。
• 未加工のリクエスト — ユーザーが希望する内容を説明します。最初のバージョンを作成してから、基準の設定に進みます。

受け取った内容を確認し、現在の状態を簡潔に要約します（例：「これは Webhook イベントを処理する120行の Go ハンドラーです。ネストしたエラー処理と、いくつかの重複パターンが見られます。」）。まだ改善を始めてはいけません。

ステップ2 — 基準を設定する

まずユーザーのリクエストから基準を推定します（上記の「基準の推定」を参照）。次に、確認するか質問します。

• 文脈から基準が明確な場合 — 確認します：「[X] と [Y] に重点を置きます。それでよさそうですか？」
• 基準があいまいな場合 — 「最も重要なのは何ですか？」と「どのような結果なら受け入れられませんか？」と尋ねます。
• 基準が3つを超える場合 — 優先順位を明確にして、上位3つを選びます

目的を絞ったタスクなら、基準は1つでも問題ありません。数を満たすためだけに、ユーザーに追加の基準を無理に考えさせないでください。ユーザーが挙げていない、分野に関連する基準を提案してもかまいません（「分野別のヒント」を参照）が、選択はユーザーに委ねてください。

ステップ3 — ベースラインを記録する

最初の出力を作成する（または既存の成果物をそのまま使用する）し、すべての基準に照らして採点したうえで、主なギャップを特定してユーザーに提示します。

ステップ4 — 改善する

最も大きなギャップを対象に、焦点を絞った変更を1つ行います。変更を加える前に、何を変更するのか、なぜ変更するのかを説明してください。

ステップ 5 — 評価とチェックポイント

新しい出力をすべての基準に照らして採点し、前回の反復と比較して、後退がないか確認します。その後、採点表をユーザーに提示します。見落としに気づいたり、採点に異議を唱えたりする場合があります。必要に応じて、続行する前に調整します。

ステップ 6 — 判断

不足が残っている場合は続行します。すべての基準を満たした場合、3 回の反復で進展がなかった場合、合計 10 回の反復に達した場合、またはユーザーが停止を指示した場合は終了します。

ステップ 7 — 提示

最終出力を要約とともに提示します。プロジェクトの慣例に従い、表は英語のままにします。

## Final Output

[The improved result]

---

### Iteration History

| Iteration | Change | Total Score | Delta |
|---|---|---|---|
| 0 (Baseline) | — | X / Y | — |
| 1 | [Change description] | X / Y | +W |
| 2 | [Change description] | X / Y | +W |

**Final Score: X / Y**
**Criteria met:** [List]
**Criteria not met (if any):** [List with reason]

3 回以上の反復を行う長時間の改善セッションでは、進捗をコンテキストのリセット後も保持できるよう、反復の履歴をファイル（例：作業ディレクトリ内の improve-history.md）に記録します。ファイルのパスをユーザーに伝えます。

例

クイックモードの例

ユーザー：「この関数を高速化してください」

1. Goal: improve execution speed
2. Read the function, identify bottleneck
3. Apply optimization
4. Show before/after with explanation
5. "Does this hit the mark, or should I keep going?"

フルモードの例

ユーザー：「この README を改善してください。わかりにくく、長すぎます」

1. Receive: README.md contents
2. Criteria (confirmed with user):
   - #1 Clarity: a new team member understands the project in under 2 minutes
   - #2 Conciseness: under 200 lines, no redundant sections
3. Baseline: score both criteria, identify key gaps
4. Iteration 1: restructure for clarity (target biggest gap)
5. Checkpoint: share scorecard, ask user if they agree
6. Iteration 2: trim redundant content (next gap)
7. Deliver: final README + iteration history

エッジケースへの対応

**ユーザーが反復の途中で基準を変更した場合：**変更を受け入れます。現在の出力を新しい基準で採点し、ステップ 4 から続行します。

**ユーザーがループの実行を待たずにフィードバックを提供した場合：**フィードバックを新しい基準、または優先順位を見直す合図として扱います。調整して続行します。

**出力がすでに完璧な場合（ベースラインですべての基準を満たしている場合）：**ただちに成功を宣言します。さらに改善したい場合は、ユーザーに基準を引き上げるよう提案します。

**基準同士が矛盾する場合：**矛盾を指摘します。「基準 A と基準 B は互いに相反するようです。矛盾する場合は、どちらを優先しますか？」

**ユーザーが簡単な修正を 1 つだけ求めている場合：**クイックモードを使い、フルループを無理に適用しません。

このスキルで行わないこと

• 目標を見つけたり、意図を探ったりしません。明確な入力と基準が必要です（目的の探索には /brainstorm を使用してください）。
• 「より良い」とは何かを推測しません。明示的な基準が必要です。
• 無制限に反復しません。明確な終了条件があります。
• ユーザーの承認なしに、満たしている基準を、満たしていない基準と引き換えにしません。