القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/shinpr/ai-coding-project-boilerplate --skill implementation-approachيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى 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.
عرض 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で止まり、継続に必要なリポジトリ内の根拠またはユーザー判断を具体的に報告する。