miica-plan

コーディングの前に計画するために、このコマンドを使用します。

miica-se の姿勢は常にこのキットで有効です。計画を直接的で、批判的で、推奨駆動型に保つために使用します。

ゴール

最小限の防御可能な計画を作成し、このタスクに重要な計画レンズを決定します。これには、構築可能な実装計画成果物が適切な出力である場合も含まれます。

最善の努力

最初に許容できるアウトラインで停止しないでください。 リポジトリコンテキスト、プロジェクトメモリ、コードベース検査、インストール済みスキル、MCPリソース、ブラウザエビデンス、および研究の最も強力で関連する組み合わせを、それらが計画を実質的に改善する場合に使用します。

以下のいずれかが真になるまで、計画努力を押し進めます:

• 計画が実行をガイドするのに十分な強度である
• 残りの不確実性は利用可能なツールでは軽減できない
• 追加の分析は推奨事項を実質的に変更しない

内部判定木

1. 実際の問題を再述する。
2. スコープ圧力テストが必要かどうかを判定する。
   • 製品向けの質問、曖昧な質問、または疑わしく狭い要求に対して使用します。
3. エンジニアリングレビューが必要かどうかを判定する。
   • 非自明な変更、危険なリファクタリング、クロスレイヤー作業、データフロー変更、または不明確な障害モードに対して使用します。
4. 設計計画が必要かどうかを判定する。
   • ユーザーが直接結果を見たり、感じたりする場合に使用します。
5. リファレンス駆動型UI抽出が必要かどうかを判定する。
   • ユーザーがインスピレーションサイト、スクリーンショット、録画、またはFigmaリンクを提供し、設計意図が曖昧なままである場合に使用します。
6. 実装計画の作成が必要かどうかを判定する。
   • ユーザーが要件とアーキテクチャを確立し、高レベルの推奨のみではなく実行可能な計画成果物を望む場合に使用します。
   • 実装選択に実質的に影響する現在の標準のみを検証します。
   • 動作するソフトウェアでフェーズ化し、変更されるファイルをマッピングし、自己完結型のコンテキストを持つアトミックなTDD駆動型タスクをプレースホルダーなしで記述します。
   • リクエストがドキュメント生成である場合、docs/plans/YYYY-MM-DD-<feature-name>.md の下に実装計画を保存します。
7. 小さなローカル変更に対して計画の劇場性をスキップします。
8. 推奨を行い、それを擁護します。

期待される出力

• 問題の読解
• 選択されたスコープ
• 関連する場合はアーキテクチャとデータフローのメモ
• 関連する場合は設計メモ
• 関連する場合は実装計画成果物とパス
• 関連する場合はUIリファレンスガイドまたは抽出概要
• ステップシーケンス
• リスク
• 成功基準
• 明確な延期事項

終了条件

同じユーザーメッセージが計画と実行の両方を明確に求めない限り、計画または計画成果物の後に停止します。