ワンクリックでManusで任意のスキルを実行

gap-analysis

スター0

フォーク0

更新日2026年3月5日 08:34

This skill should be used when the user asks to "analyze implementation gap", "evaluate feasibility", "assess codebase compatibility", "compare requirements with existing code", or "plan implementation approach". Analyzes gaps between requirements and existing codebase to inform implementation strategy.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

sizukutamago

sizukutamago/blueprint-plugin

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Gap Analysis Skill

要件と既存コードベースのギャップを分析し、実装戦略を策定するスキル。既存プロジェクトへの機能追加、リファクタリング計画策定に使用する。

前提条件

条件	必須	説明
docs/requirements/user-stories.md	○	分析対象の要件
既存ソースコード	○	ギャップ分析対象

出力ファイル

ファイル	テンプレート	説明
docs/00_analysis/gap_analysis.md	{baseDir}/references/gap_analysis.md	ギャップ分析結果

ワークフロー

1. 要件ドキュメント読み込み
2. 現状調査（Current State Investigation）
   - ディレクトリ構造・主要モジュール分析
   - 再利用可能なコンポーネント特定
   - アーキテクチャパターン・制約把握
   - 統合ポイント（データモデル、API、認証）特定
3. 要件実現可能性分析（Requirements Feasibility Analysis）
   - 技術要件の抽出（データモデル、API、UI、ビジネスルール）
   - ギャップ・制約の特定
   - 複雑性シグナルの評価
4. 実装アプローチ検討（Implementation Approach Options）
   - Option A: 既存コンポーネント拡張
   - Option B: 新規コンポーネント作成
   - Option C: ハイブリッドアプローチ
5. 複雑性・リスク評価
6. 推奨事項まとめ

分析フレームワーク

現状調査項目

調査項目	内容
ドメイン関連資産	主要ファイル/モジュール、ディレクトリ構成
規約	命名規則、レイヤリング、依存方向
統合ポイント	データモデル/スキーマ、APIクライアント、認証機構

実装アプローチ評価

Option A: 既存コンポーネント拡張

評価項目	内容
対象ファイル	変更が必要なファイル特定
互換性	既存インターフェースとの整合性
複雑性	認知負荷、単一責任原則の維持

Trade-offs:

新規ファイル最小限、既存パターン活用
既存コンポーネント肥大化リスク

Option B: 新規コンポーネント作成

評価項目	内容
作成理由	責務分離、既存の複雑性、独立ライフサイクル
統合ポイント	既存システムとの接続方法
責務境界	新規コンポーネントの所有範囲

Trade-offs:

クリーンな責務分離、テスト容易性
ファイル増加、インターフェース設計必要

Option C: ハイブリッドアプローチ

評価項目	内容
組み合わせ戦略	拡張部分と新規部分の分担
フェーズ分け	段階的実装計画
リスク軽減	インクリメンタルロールアウト、Feature Flag

複雑性・リスク評価

工数（Effort）

レベル	目安	条件
S	1-3日	既存パターン、最小依存、単純統合
M	3-7日	新パターン/統合あり、中程度複雑性
L	1-2週	大きな機能、複数統合/ワークフロー
XL	2週以上	アーキテクチャ変更、未知技術、広範影響

リスク（Risk）

レベル	条件
High	未知技術、複雑な統合、アーキテクチャ変更、不明確なパフォーマンス/セキュリティ
Medium	ガイダンス付き新パターン、管理可能な統合、既知のパフォーマンス解決策
Low	確立パターンの拡張、馴染みの技術、明確なスコープ、最小統合

ツール

ツール	用途
Grep	コードベース内パターン検索
Glob	ファイル構造調査
Read	ファイル内容分析
WebSearch	外部依存調査（必要時）
WebFetch	ドキュメント参照（必要時）

原則

原則	説明
情報提供優先	決定ではなく分析とオプションを提供
複数オプション	実現可能な複数の選択肢を提示
明示的なギャップ	不明点と制約を明確にフラグ
コンテキスト考慮	既存パターンとアーキテクチャ制限に沿う
透明な見積り	工数とリスクを簡潔に根拠付け

エラーハンドリング

エラー	対応
要件不在	`/spec` で Contract を作成するよう案内（Contract が要件の代わりになる）
ソースコードなし	対象ディレクトリ確認を促す
複雑な統合が不明確	"Research Needed" としてフラグ、設計フェーズで詳細調査

このリポジトリの他の Skills

同じリポジトリ

orchestrator

sizukutamago/blueprint-plugin

Run the full workflow pipeline. Use when the user wants to "run blueprint workflow", "automate spec to docs", "orchestrate pipeline", "run the full pipeline", "execute blueprint", "start blueprint", "run complete design-to-code pipeline", "spec to implementation", "end to end development", "resume pipeline", "continue from where I left off", "force rerun all stages", "build full-stack app from scratch", "design and implement screens with API", or "create full-stack app with UI". Also use when the user says "パイプラインを実行", "仕様から実装まで", "一気通貫で開発", "設計から実装を自動化", or "フルスタックアプリを作る". Automates /requirements → /spec → /test-from-contract → /implement → /generate-docs with Review Gates (Requirements / Contract / Test / Code / Doc) between each stage. Supports --resume (continue from checkpoint) and --force (rerun all stages).

2026-03-140

requirements

sizukutamago/blueprint-plugin

Define requirements through structured user interviews using Double Diamond pattern and EARS-inspired notation. This skill should be used BEFORE /spec — use /spec when you already know what to build and need I/O boundary contracts, use /requirements when you need to figure out WHAT to build first. Use when the user wants to "define requirements", "gather requirements", "create user stories", "interview for requirements", "identify personas", "define MVP scope", "create acceptance criteria", "structure requirements", "start a new project", "plan a new app", "figure out what to build", or "scope out a product". Also use when the user says "要件定義", "ユーザーストーリー", "要件をまとめる", "ヒアリング", "ペルソナを定義", "MVPを決める", "受け入れ基準", "何を作るか整理", "新しいプロジェクトを始めたい", "アプリのアイデアがある", "何を作るか決めたい", "プロダクトの要件を整理", or "機能を洗い出したい". Make sure to use this skill proactively when the user describes an app idea or project concept without existing contracts or specs.

2026-03-140

self-improve

sizukutamago/blueprint-plugin

Analyze accumulated blueprint usage logs and generate improvement PRs for the plugin itself. Use when the user wants to "improve blueprint plugin", "analyze blueprint logs", "self-improve", "check improvement opportunities", "generate improvement PR", "review plugin usage patterns", "blueprint-improve", or "show blueprint stats". Also use when the user says "blueprint改善", "ログ分析", "自己改善", "改善PRを出す", "プラグインを改善する", "使用パターンを分析", or "ログの統計を見せて". This skill reads usage logs from ~/.claude/blueprint-logs/ and identifies recurring patterns, common errors, and user correction frequencies to propose concrete improvements to the blueprint-plugin's core specs, skills, and templates.

2026-03-140

spec

sizukutamago/blueprint-plugin

Create I/O boundary contracts through brainstorming. Use when the user wants to "create contract", "define spec", "brainstorm API design", "design I/O boundary", "define external integration", "specify file format", "design screen", "create UI spec", "define form contract", "screen contract", "design page layout", or "define frontend spec". Also use when the user asks to start a new feature, create .blueprint directory, or brainstorm a new service. Also use when the user says "仕様を作る", "APIを設計する", "コントラクト作成", "画面を設計する", "I/O境界を定義する", "ブレインストーミング", or "新機能の仕様を決める". Combines interactive brainstorming with structured contract YAML generation for all types: api, external, file, internal, and screen.

2026-03-140

implement

sizukutamago/blueprint-plugin

Implement code from Contract YAML and RED tests. Use when the user wants to "implement contracts", "generate implementation", "make tests green", "create implementation", "write code from spec", "build feature from contract", "implement feature", "implement screen", "create page components", "implement UI from contract", or "implement Stage 3". Also use when the user says "実装する", "コードを書く", "テストをグリーンにする", "機能を実装する", "画面を実装する", or "コントラクトを実装". Orchestrates Implementers, Integrator, and Refactorer agents to produce working code for all contract types including screen/UI.

2026-03-050

generate-docs

sizukutamago/blueprint-plugin

Generate design documents from existing code. Use when the user wants to "generate design docs", "create documentation from code", "reverse engineer architecture", "extract design documents", "document existing system", "create docs from implementation", "generate screen design docs", "document UI components", or "create frontend design specs". Also use when the user says "設計書を生成する", "ドキュメントを作る", "コードから仕様書を作成", "画面設計書を生成", or "アーキテクチャドキュメントを書く". Analyzes source code and generates design documentation.

2026-03-050

name	gap-analysis
description	This skill should be used when the user asks to "analyze implementation gap", "evaluate feasibility", "assess codebase compatibility", "compare requirements with existing code", or "plan implementation approach". Analyzes gaps between requirements and existing codebase to inform implementation strategy.
version	1.0.0

Gap Analysis Skill

前提条件

条件	必須	説明
docs/requirements/user-stories.md	○	分析対象の要件
既存ソースコード	○	ギャップ分析対象

出力ファイル

ファイル	テンプレート	説明
docs/00_analysis/gap_analysis.md	{baseDir}/references/gap_analysis.md	ギャップ分析結果

ワークフロー

1. 要件ドキュメント読み込み
2. 現状調査（Current State Investigation）
   - ディレクトリ構造・主要モジュール分析
   - 再利用可能なコンポーネント特定
   - アーキテクチャパターン・制約把握
   - 統合ポイント（データモデル、API、認証）特定
3. 要件実現可能性分析（Requirements Feasibility Analysis）
   - 技術要件の抽出（データモデル、API、UI、ビジネスルール）
   - ギャップ・制約の特定
   - 複雑性シグナルの評価
4. 実装アプローチ検討（Implementation Approach Options）
   - Option A: 既存コンポーネント拡張
   - Option B: 新規コンポーネント作成
   - Option C: ハイブリッドアプローチ
5. 複雑性・リスク評価
6. 推奨事項まとめ

分析フレームワーク

現状調査項目

調査項目	内容
ドメイン関連資産	主要ファイル/モジュール、ディレクトリ構成
規約	命名規則、レイヤリング、依存方向
統合ポイント	データモデル/スキーマ、APIクライアント、認証機構

実装アプローチ評価

Option A: 既存コンポーネント拡張

評価項目	内容
対象ファイル	変更が必要なファイル特定
互換性	既存インターフェースとの整合性
複雑性	認知負荷、単一責任原則の維持

Trade-offs:

新規ファイル最小限、既存パターン活用
既存コンポーネント肥大化リスク

Option B: 新規コンポーネント作成

評価項目	内容
作成理由	責務分離、既存の複雑性、独立ライフサイクル
統合ポイント	既存システムとの接続方法
責務境界	新規コンポーネントの所有範囲

Trade-offs:

クリーンな責務分離、テスト容易性
ファイル増加、インターフェース設計必要

Option C: ハイブリッドアプローチ

評価項目	内容
組み合わせ戦略	拡張部分と新規部分の分担
フェーズ分け	段階的実装計画
リスク軽減	インクリメンタルロールアウト、Feature Flag

複雑性・リスク評価

工数（Effort）

レベル	目安	条件
S	1-3日	既存パターン、最小依存、単純統合
M	3-7日	新パターン/統合あり、中程度複雑性
L	1-2週	大きな機能、複数統合/ワークフロー
XL	2週以上	アーキテクチャ変更、未知技術、広範影響

リスク（Risk）

レベル	条件
High	未知技術、複雑な統合、アーキテクチャ変更、不明確なパフォーマンス/セキュリティ
Medium	ガイダンス付き新パターン、管理可能な統合、既知のパフォーマンス解決策
Low	確立パターンの拡張、馴染みの技術、明確なスコープ、最小統合

ツール

ツール	用途
Grep	コードベース内パターン検索
Glob	ファイル構造調査
Read	ファイル内容分析
WebSearch	外部依存調査（必要時）
WebFetch	ドキュメント参照（必要時）

原則

原則	説明
情報提供優先	決定ではなく分析とオプションを提供
複数オプション	実現可能な複数の選択肢を提示
明示的なギャップ	不明点と制約を明確にフラグ
コンテキスト考慮	既存パターンとアーキテクチャ制限に沿う
透明な見積り	工数とリスクを簡潔に根拠付け

エラーハンドリング

エラー	対応
要件不在	`/spec` で Contract を作成するよう案内（Contract が要件の代わりになる）
ソースコードなし	対象ディレクトリ確認を促す
複雑な統合が不明確	"Research Needed" としてフラグ、設計フェーズで詳細調査