Menu
Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.
Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
npx skills add https://github.com/shinpr/ai-coding-project-boilerplate --skill implementation-approachO comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.
Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.
Detects code smells, anti-patterns, and readability issues. Use when implementing features, reviewing code, or refactoring.
Determines which PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires and where each is stored. Use when deciding documentation scope or creating or reviewing a technical document.
Selects implementation strategy (vertical slice, horizontal, or hybrid) with risk assessment. Use when planning feature implementation.
Exibindo SKILL.md
| name | implementation-approach |
| description | 実装戦略（垂直スライス、水平、ハイブリッド）をリスク評価で選択。機能の実装計画時に使用。 |
核心質問: 「既存の実装はどうなっているのか？」
アーキテクチャ分析: 責務分離、データフロー、依存関係、技術的負債
実装品質評価: コード品質、テストカバレッジ、パフォーマンス、セキュリティ
歴史的文脈理解: 現在の形の理由、過去判断の妥当性、制約の変化、要求の進化
現状に関する事実をこれ以上集めても、責務、再利用、選択肢の成立性、総合的な複雑性、契約、検証のいずれも変わらない時点で調査を止める。
完了証跡: 確認したパス、観測したアーキテクチャ・データフローの事実、既知の制約、推測と明記した歴史的背景、不明点のうち戦略選択を変え得るもの。
移行条件: 戦略に関係するすべての主張が、観測済み、根拠付きの推測、または不明として明記されている場合に次へ進む。
核心質問: 「現行の必要な成果を届ける最小の設計は何か。そこから先の追加は、どの根拠が要求しているのか？」
実装戦略の探索に入る前に、以下を順に完了させる：
候補となる経路と不採用の追加は設計時に比較し、永続的な出力には Selected Design だけを残す。選択した経路全体に加えて、追加した設計サーフェスごとの根拠と、それを取り除くと満たせなくなる条件を記録する。選択肢を判断の履歴として残せるのは、承認済みADRが扱う場合だけである。実装者は別の成果物を作らず、同じ収束チェックを適用する。
完了証跡: 完全なSelected Designが1つあること。追加した各設計サーフェスに、現在の根拠、より小さいサーフェスでは不十分な理由、減算チェックの結果が示されていること。
移行条件: 裏付けとなるすべての主張が、観測済み、根拠付きの推測、または不明として明記されている場合に次へ進む。不明点がステップの続行を妨げる場合は、そのステップで止まり、必要な根拠またはユーザー判断を具体的に示す。
核心質問: 「before → after を判断する時に、参考にすべき実装パターンや戦略は何なのか？」
調査・探索: リポジトリ内のパターンを最初に確認し、次に特定した依存バージョンの公式ドキュメント、保守されているOSS実装の順に調査する。文献・ブログは代替案を補足する場合にのみ使用し、非公式な情報源と明記する
創造的思考: 戦略組み合わせ、制約前提設計、フェーズ分け、拡張ポイント設計
レガシー対応戦略:
新規開発戦略:
統合・移行戦略:
完了証跡: 判断が自明でない場合は、実行可能な候補を2つ以上示し、それぞれが満たす観測済みの制約と未解決の制約を対応づける。
移行条件: 同じ制約集合に対して候補を比較できる場合に次へ進む。
核心質問: 「既存の実装に適用するとどのようなリスクが発生し、検証可能性と切り戻し可能性を保ちながら、その発生確率または影響を計測可能な形で下げられる制御は何か？」
技術的リスク: 既存システム影響、データ整合性、パフォーマンス劣化、統合複雑性
運用リスク: サービス可用性、デプロイダウンタイム、運用プロセス変更、切り戻し手順
プロジェクトリスク: スケジュール遅延、技術習得コスト、品質達成度、チーム連携
予防的対策: 段階的移行、並行動作検証、統合・回帰テスト追加、監視設定
発生時対応: 切り戻し手順、ログ・メトリクス準備、連絡体制定義、サービス継続手順
完了証跡: 重要なリスクごとに、発生確率・影響の根拠、予防または封じ込めの制御、検証点を1つずつ示す。
移行条件: 影響が大きいすべてのリスクに制御または作業を止めるエスカレーションが設定されている場合に次へ進む。
核心質問: 「このプロジェクトの制約は何か？」
技術的制約: ライブラリ互換性、リソース容量、義務要件、数値目標
時間的制約: 期限・優先度、依存関係、マイルストーン、学習期間
リソース制約: チーム・スキル、作業時間・体制、予算、外部契約
ビジネス制約: 市場投入時期、顧客影響、法規制・標準
完了証跡: 各制約を観測済み、推測、不明のいずれかに分類する。候補を無効にし得る不明点ごとに、必要な根拠またはユーザー判断を示す。
移行条件: 残る不明点によって有効な候補集合が変わらない場合、またはユーザーが解決した場合に次へ進む。
すべての必須制約と現行要件を満たし、移行リスクが最も低く、検証までの遅延が最も小さいアプローチを選択する。要件の充足、互換性、リスク制御が同等の場合にのみ、ライフサイクルコストと実装工数をタイブレーカーとして使用する。
特徴: 機能単位で全層を縦断実装 適用条件: 機能間の依存が少ない、ユーザーが利用可能な形で出力、アーキテクチャ全層への変更が必要 確認方法: 各機能完成時のエンドユーザー価値提供
特徴: アーキテクチャ層別の段階的構築 適用条件: 基盤システムの安定性が重要、複数機能が共通基盤に依存、層別の段階的確認が有効 確認方法: 全基盤層完成時の統合動作確認
特徴: プロジェクト特性に応じた柔軟な組み合わせ 適用条件: 要件が明確でない、フェーズごとにアプローチ変更が必要、プロトタイピングから本格実装への移行 確認方法: エンドユーザーが操作可能な振る舞いを生むPhaseにはL1、テスト可能な内部の振る舞いまたは契約を生むPhaseにはL2、実行可能な振る舞いをまだ持たないビルド時の構造だけを生むPhaseにはL3を割り当てる
ハイブリッドでは、すべてのPhaseにL1/L2/L3のいずれか1つと、観測可能な完了結果を明示する。
完了証跡: 選択したアプローチ1つ、そのPhase境界、統合点、各Phaseの検証結果。
移行条件: 選択したアプローチがすべての必須制約を満たし、リスクに制御が設定されている場合は文書化へ進む。それ以外は候補探索（Phase 3）へ戻る。Phase 4〜5の結果がSelected Designまたはその根拠を変える場合は Design Convergence（Phase 2）へ戻る。
Design Docまたは計画のハンドオフに、以下の構造で記載する：
implementationApproachDecision:
observedConstraints: [<制約 + 根拠>]
inferredConstraints: [<制約 + 根拠と推測>]
unknowns: [<不明点 + 必要な根拠または判断>]
selectedApproach: <vertical | horizontal | hybridの説明>
selectionRationale: <必須制約の充足、互換性、リスク制御、総合的な複雑性の根拠>
addedDesignSurface: [<追加 + 現在の根拠 + より小さいサーフェスでは不十分な理由 + 減算チェックの結果>]
phaseVerification: [<Phase + L1/L2/L3 + 観測可能な完了証跡>]
永続的な成果物に残すのは選択したアプローチだけとする。承認済みADRが判断の履歴として扱う場合は、比較した選択肢も残せる。
完了証跡: 選択したアプローチと追加した各設計サーフェスが、観測済みの制約、受け入れた推測、または解決済みのユーザー判断まで追跡できること。
各タスクの完了確認における優先順位：
優先順位: L1 > L2 > L3 の順で確認可能性を重視
選択した戦略に応じて統合ポイントを定義：
チェック項目に必要な根拠が不明な場合は、そのPhaseで止まり、継続に必要なリポジトリ内の根拠またはユーザー判断を具体的に報告する。