要件分析
要件（ユーザーストーリー＋ビジネスルール、該当する場合）を受け取った際に分析するための一般的な指示 — 構築用ではありません（構築は implementar-requerimiento スキルを使用）。移植可能：どのプロジェクト／クライアントで使用しても同様に適用されます。
1. 読み取りと抽出
- 文書全体を読み、目的、スコープ、アクター、フロー、明示的なビジネスルールを抽出する。
- 文書内の矛盾を指摘する（例：目的で言及されているがその後詳細が記述されていない、またはルールが他の部分と矛盾している）。
- 埋め込まれた画像／証拠（レイアウト、画面、ダッシュボード）もすべて確認する — 明らかなものだけではない。テキストにない詳細が含まれていることが多く、テキストが未解決のままにしているギャップを解決できる場合がある。
2. 既存との比較（該当する場合）
- 要件が既に構築されたモジュール／プロセス／機能に触れる、または類似している場合、現在のプロジェクトの実際のコードと比較し、何が再利用可能か、何を新規で作成すべきかを特定する。
- 既に使用中のもの（別のモジュール、別の統合、別の共有フロー）を変更する必要がある場合、既存への影響リスクを評価し、要件が明示的にその動作変更を要求しない限り、新規部分を分離して現在の動作を変更しないことを優先する。
- 発見事項は実際のDEVデータベースに対して確認してから確定すること — スキーマやデータを推測せず、問い合わせること。サーバーと認証情報：会話中で既に持っていない場合はユーザーに依頼する；ユーザーの明示的な許可なくコメントやコード内で見つけた認証情報を再利用しない。
3. 未解決の質問
- あいまいな点、未指定の点、ビジネス／クライアントの決定に依存する点（例：交渉条件、金額、期限、しきい値、権限、例外）を明示的にリストアップする。
- それぞれを未解決としてマークし、回答が得られたら回答を文書化して解決済みに変更する。
- まだ回答できない質問に依存するものは見積もりに含めない。
4. 棚卸
影響を受ける、または新規となるデータベースオブジェクト、画面、ビジネスルール／バリデーション、レポートの完全なリスト。それぞれに （新規） または （変更） を付記する。
5. 成果物
Analisis_Impacto_[コード].docx— クライアント／ベンダーの開発チームに送付するインパクト文書。Estimacion_tiempos_[コード].xlsx— オブジェクト／タスクごとの工数（時間）と合計。Plan_Implementacion_[コード].docx— フェーズごとの計画と相互依存関係（すべてを1フェーズにしない）。- デフォルトでは、要件分析時にファイルとして生成されるのは
Estimacion_tiempos_[コード].xlsxのみです。Analisis_Impacto_[コード].docxとPlan_Implementacion_[コード].docxは自動的にはファイル生成されません — その内容（目的、スコープ、ビジネスルール、矛盾、既存との比較、未解決の質問、棚卸、計画フェーズ）は同様に展開され、会話内で利用可能な状態を保ち、ユーザーが明示的に要求した時点（例：「インパクト分析を生成して」「Wordに出力して」）で文書化できるように準備されます。 Estimacion_tiempos_[コード].xlsxは既存のテンプレートから作成すること（要件フォルダに既にテンプレートがあればそれをコピーし、テーブルをゼロから再作成しない；プロジェクトにまだテンプレートが存在しない場合、形式を独自に作る前にユーザーに標準テンプレートがあるか確認する）。ユーザーが別途指定しない限りの期待形式：タイトルバンド + No. | アクティビティ | 時間(h) | 日数 の列を持つテーブル（アクティビティ列は広め、アクティビティごとに1行、最後に合計行（SUM式）と日数 = 時間/8）。追加の列（種類、メモ、分析／開発／テストの個別内訳など）を作成しない — 種類（新規／変更）やメモを詳細に記載したい場合は、「アクティビティ」セルのテキスト内に含めること。- 現実的な工数： 手順2で確認した再利用を考慮する（すべてが新規であるかのように見積もらない）、すべてのタスクに一律のヒューリスティックを使用しない、時間を日付に変換する必要がある場合はチームの実際のキャパシティを確認する。
6. ステータスとブロッカー
最後に、確定事項、未解決事項、構築開始を妨げるもの（不足しているドキュメント、未回答のクライアント／ビジネスからの回答、未承認など）を要約する。