quick-implement

クイック実装

スコープゲート（コーディング前に必須）

以下の条件をすべて満たす場合に限り、タスクをクイック実装の対象として扱います。

1. 要件が明確

   • 期待される動作が明示されている
   • 重大なプロダクト／アーキテクチャ上の曖昧さがない

2. 変更範囲が小さい

   • 通常、変更対象のファイル数が少ない（大まかな目安：5 ファイル以下）
   • モジュールをまたぐ大規模なリファクタリングがない

3. アーキテクチャ上のリスクが低い

   • 基盤となる設計の見直しがない
   • 移行を多く伴う変更がない
   • 複数フェーズに分けたロールアウトへの依存がない

4. 検証が容易

   • 対象を絞ったテスト／チェックを短時間で実施できる
   • 長時間の原因調査を繰り返す必要がない

条件をひとつでも満たさない場合は、write-plan に切り替えてください。

即時停止してエスカレーションする条件

以下のいずれかに該当した場合は、クイック実装をただちに中止して、計画に切り替えてください。

• 設計上の判断が必要な要件の曖昧さ
• 複数のサブシステムにまたがる予期しない依存関係
• 大幅なデータモデルまたはスキーマの変更
• セキュリティ上重要、またはコンプライアンス上重要な変更
• ベンチマークや設計上のトレードオフの検討が必要なパフォーマンス対応
• リファクタリングの範囲が当初の小規模な想定を超えて拡大している
• 明確な根本原因が見つからないまま、試行が繰り返し失敗している
• 段階的なリリース、機能フラグ、または移行戦略が必要

エスカレーション時の対応：

1. すべてのコーディング作業をただちに中止します。
2. 次のメッセージをそのまま出力します："This change exceeds rapid-implementation safety limits. Recommend write-plan first to define phased execution and risk controls."
3. 入力／質問を使って、write-plan スキルへの引き継ぎを開始するかどうか、ユーザーに尋ねます。

ワークフロー

ステップ 1：分析とコンテキストの把握

1. ユーザーの依頼を理解し、受け入れ条件を定義します。
2. 依頼に関連するプロジェクトのコンテキストのみを読み込みます。
   • docs/SUMMARY.md が存在する場合は、最初に読みます。
   • タスクに関連する詳細ドキュメントのみを読み込みます。
   • 実装規約については Code Standard ドキュメントを優先します。
   • ドキュメントがコードまたはユーザーの意図と矛盾する場合は、広範な変更を加える前に、利用可能な入力／質問を使って確認します。
3. 必要最小限のコードパスのみを調査します。
4. タスクが引き続きスコープゲートを満たしていることを確認します。
5. 曖昧さが残る場合は、コーディングを始める前に確認の質問をします。

ステップ 2：実装

1. 要件を満たすための、正確かつ最小限の変更を行います。
2. 既存のパターンや規約を再利用します。
3. 依頼と無関係な、便宜的なリファクタリングは避けます。
4. 該当する場合は、変更を冪等にし、安全に再実行できるようにします。

ステップ 3：検証

適切な実行ツールを使って、変更に見合った検証を行います。

1. 変更した動作に関連する対象を絞ったテスト
2. 変更箇所に関連する lint／型チェック
3. 該当する場合はビルドまたは実行時の検証

検証で予期しない失敗が発生した場合：

• 原因が明らかに局所的であれば、対象を絞って修正します。
• より広範囲への影響が示唆される場合は、write-plan へのエスカレーションを推奨します。

ステップ 4：完了

1. 何を変更したか、またその理由を要約します。
2. 変更したファイルを列挙します。
3. 検証コマンドとその結果を報告します。
4. 動作やドメインルールに小さな変更があった場合は、ドキュメントを更新します。

実行上の境界

• ユーザーの明示的な承認なしに、スコープを拡大しないでください。
• 指定されていない動作を推測せず、確認してください。
• リスクが高まった場合は、無理に完了させず、早めにエスカレーションしてください。
• 複雑さまたはリスクがクイック実装の上限を超えた場合は、write-plan にエスカレーションしてください。
• タスクの主な目的が問題のデバッグである場合は、fix を使ってください。

出力チェックリスト

最終回答の前に、以下を確認してください。

• スコープゲートを満たしている
• アーキテクチャ上の変更を意図せず導入していない
• 検証を実施し、その結果を報告している
• 安全性の上限を超えた場合に、エスカレーションを行っている