Menü
実装戦略（垂直スライス、水平、ハイブリッド）をリスク評価で選択。機能の実装計画時に使用。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
PRD、ADR、Design Doc、UI Spec、作業計画書の作成を支援。技術ドキュメントの作成・レビュー時、または「UI Spec/画面設計/コンポーネント分解」が言及された時に使用。
入力・出力・成功基準・決定事項・未解決条件を明確化し、下流エージェントが推測せず実行できるようにする。LLM向けのプロンプト・ハンドオフ・計画成果物・レビュー・レポート・生成指示を記述または改訂する時に使用。
タスクの本質を分析し適切なスキルを選択。規模見積もりとメタデータを返却。タスク開始時、スキル選択時に使用。
Guides PRD, ADR, Design Doc, UI Spec, and Work Plan creation. Use when creating or reviewing technical documents, or when "UI spec/screen design/component decomposition" is mentioned.
Clarifies inputs, outputs, success criteria, decisions, and unresolved conditions so downstream agents can execute without guessing. Use when writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions.
Analyzes task essence and selects appropriate skills. Returns scale estimates and metadata. Use when starting tasks or selecting skills.
| name | implementation-approach |
| description | 実装戦略（垂直スライス、水平、ハイブリッド）をリスク評価で選択。機能の実装計画時に使用。 |
核心質問: 「既存の実装はどうなっているのか？」
アーキテクチャ分析: 責務分離、データフロー、依存関係、技術的負債
実装品質評価: コード品質、テストカバレッジ、パフォーマンス、セキュリティ
歴史的文脈理解: 現在の形の理由、過去判断の妥当性、制約の変化、要求の進化
核心質問: 「before → after を判断する時に、参考にすべき実装パターンや戦略は何なのか？」
調査・探索: 技術スタック事例（WebSearch活用）、同種プロジェクト、OSS実装、文献・ブログ
創造的思考: 戦略組み合わせ、制約前提設計、フェーズ分け、拡張ポイント設計
レガシー対応戦略:
新規開発戦略:
統合・移行戦略:
重要: 最適解は各プロジェクトの文脈に応じた創造的思考により発見される。
核心質問: 「既存の実装にそれを当てはめた時にどういうリスクが発生し、それをどうコントロールするのが最良なのか？」
技術的リスク: 既存システム影響、データ整合性、パフォーマンス劣化、統合複雑性
運用リスク: サービス可用性、デプロイダウンタイム、運用プロセス変更、切り戻し手順
プロジェクトリスク: スケジュール遅延、技術習得コスト、品質達成度、チーム連携
予防的対策: 段階的移行、並行動作検証、統合・回帰テスト追加、監視設定
発生時対応: 切り戻し手順、ログ・メトリクス準備、連絡体制定義、サービス継続手順
核心質問: 「このプロジェクトの制約は何か？」
技術的制約: ライブラリ互換性、リソース容量、義務要件、数値目標
時間的制約: 期限・優先度、依存関係、マイルストーン、学習期間
リソース制約: チーム・スキル、作業時間・体制、予算、外部契約
ビジネス制約: 市場投入時期、顧客影響、法規制・標準
基本的な実装アプローチから最適解を選択（創造的組み合わせも推奨）：
特徴: 機能単位で全層を縦断実装 適用条件: 機能間の依存が少ない、ユーザーが利用可能な形で出力、アーキテクチャ全層への変更が必要 確認方法: 各機能完成時のエンドユーザー価値提供
特徴: アーキテクチャ層別の段階的構築 適用条件: 基盤システムの安定性が重要、複数機能が共通基盤に依存、層別の段階的確認が有効 確認方法: 全基盤層完成時の統合動作確認
特徴: プロジェクト特性に応じた柔軟な組み合わせ 適用条件: 要件が明確でない、フェーズごとにアプローチ変更が必要、プロトタイピングから本格実装への移行 確認方法: 各フェーズの目標に応じてL1/L2/L3の適切なレベルで確認
Design Docでの記載：実装戦略の選択理由と根拠を明記する。
各タスクの完了確認における優先順位：
優先順位: L1 > L2 > L3 の順で確認可能性を重視
選択した戦略に応じて統合ポイントを定義：