mcpField
A
analyze

analyze

github.com/bntvllnt生産性1762 回インストール26 週間前に更新
リポジトリ

analyze について

Universal Analyzer は、テーマ、ファイル、アイデア、意思決定を複数の視点から分析するスキルです。要点やリスクの把握、実行可能な計画を求める人向けに、簡易・標準・詳細モードを備えています。

主な機能

  1. 01簡易・標準・詳細の分析モード
  2. 02分野に応じた複数の視点選択
  3. 03サブエージェントの並列実行
  4. 04ファイルとフォルダーの読み取り
  5. 05任意の TypeScript 構造分析

活用シーン

  1. 01文書やテーマの重要点の抽出
  2. 02複数の視点による意思決定のリスクと不足の評価
  3. 03ソフトウェアの改善ロードマップ作成
  4. 04第一原理による前提の検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/bntvllnt/agent-skills --skill analyze

インストール後、Claude Code で/analyzeを入力して読み込まれたか確認します。

同梱ファイルEXAMPLE.mdREADME.md

詳細

ユニバーサルアナライザー

あらゆるトピック、ファイル、アイデア、意思決定を多角的に分析する、単体で動作するスキルです。

次の場合に使用します:

  • あらゆる対象から重要なポイントを抽出したい
  • 複数の視点からギャップやリスクを分析したい(4~10人の専門家)
  • 実行可能な計画を伴う改善の機会が必要
  • 簡易要約または詳細分析モードを使いたい
  • 前提に異議を唱える、第一原理に基づいたブリーフが必要

トリガー:「分析して」、「重要なポイント」、「何が重要か」、「これを改善して」、「レビュー」、「調べて」、「評価して」、「分析」、「詳細分析」、「詳細分析を実行」、「ブリーフ」、「前提に異議を唱える」、「第一原理」

エージェントの機能

機能用途必須フォールバック
ファイル読み取り対象のファイル/フォルダーを読み込むはい—
サブエージェントのディスパッチ複数の視点から並行して分析する推奨メインスレッドで順次実行
コードベースインテリジェンス(npx codebase-intelligence)TS/TSX ソフトウェア領域の構造分析いいえファイル内容からの純粋な推論

このスキルは CLI ツールがなくても完全に機能します。コードベースインテリジェンスは、ソフトウェア領域でのみ利用できるオプションの拡張機能です。


目次

  1. クイックスタート
  2. 分析モード
  3. 実行フロー
  4. 出力形式
  5. 視点ライブラリ
  6. 思考フレームワーク
  7. 第一原理分析
  8. 例

クイックスタート

# Quick analysis (fast key points)
analyze quick "our pricing strategy"
analyze brief src/api/auth.ts

# Standard analysis (default)
analyze "SaaS product for developers"
analyze "should I accept this job offer"
analyze package.json

# Deep analysis (comprehensive)
analyze deep "company rebrand strategy"
analyze thorough "migration to microservices"

分析モード

モードトリガーエージェント所要時間出力
クイック「quick」、「fast」、「brief」、「summary」0~130~60秒重要なポイント+アクション
標準(デフォルト)4~62~4分多角的な分析+ロードマップ
詳細「deep」、「thorough」、「comprehensive」6~105~8分全体の統合+詳細な計画

実行フロー

フェーズ 0:検出
  1. モード:キーワード(quick/standard/deep)から検出します
  2. 領域:内容やキーワードから自動検出します
  3. 対象:パスが指定されている場合、ファイル/フォルダーの内容を読み込みます
  4. TypeScript の検出:対象がコードパスで、tsconfig.json が存在する場合:
    • 検出条件:tsconfig.json が存在し、npx codebase-intelligence --help が成功すること
    • CLI の完全なリファレンスを確認するには、https://raw.githubusercontent.com/bntvllnt/codebase-intelligence/main/llms.txt を取得します
    • 利用可能な場合:フェーズ 1 で構造データを収集します
    • 利用できない場合:ファイルの読み取りのみでコンテキストを収集します
フェーズ 1:コンテキストの収集
  • ファイル/フォルダーのパス → ファイルを読み込みます
  • ソフトウェア領域+TypeScript+CI が利用可能 → ファイルの読み取りに以下を追加します:
    • npx codebase-intelligence overview --json <path> → プロジェクト構造のスナップショット
    • npx codebase-intelligence modules --json <path> → モジュールの境界と相互依存関係
    • npx codebase-intelligence groups --json <path> → ディレクトリレベルの集計情報 ファイル内容とともに、構造化されたコンテキストとして含めます。CI が利用できない場合は、ファイルのみを読み込みます。
  • トピック/アイデア → 提供されたコンテキストを使用します
  • 不慣れな領域 → 必要に応じてウェブ検索を行います
フェーズ 2:分析
クイックモード

サブエージェントを使わず、メインエージェントが直接分析します

標準モード
  1. 領域に応じて4~6の視点を選択します
  2. すべての視点を並行して起動します(単一のメッセージブロック)
  3. 各エージェントが7つの中核的な質問に回答します
詳細モード
  1. 領域に応じて6~10の視点を選択します
  2. すべての視点を並行して起動します(単一のメッセージブロック)
  3. 各エージェントが12の質問(中核的な質問7つ+詳細な質問5つ)に回答します
ソフトウェアドメインの拡張(TypeScript + CI が利用可能な場合)

ソフトウェアドメインのエージェントプロンプトに、事前計算された構造データを含めます。

  • npx codebase-intelligence hotspots --json --metric complexity --limit 20 → 複雑度/変更頻度のホットスポット
  • npx codebase-intelligence forces --json → モジュールごとの凝集性/結合性の緊張関係
  • npx codebase-intelligence dead-exports --json --limit 20 → 未使用エクスポートの分析
  • npx codebase-intelligence clusters --json → 依存関係のコミュニティクラスター

エージェントには、対象コンテンツと併せて構造化コンテキストとしてこれを渡します。分析を補完するものであり、独立した推論に取って代わるものではありません。CI を利用できない場合、エージェントはファイルの内容のみから分析します。

Phase 3: 統合

すべてのエージェントが完了した後:

  1. 失敗の仮説を集約 → Critical→High→Med→Low の順に優先順位を付ける
  2. 重要なポイントを上位 10 件抽出 → 合意度順に並べる
  3. ギャップを特定 → Critical/High/Medium/Low
  4. 依存関係を含む実行可能なロードマップを作成

出力形式

クイックモード
# Quick Analysis: [Target]

**Mode**: Quick | **Domain**: [Domain] | **Date**: [Date]

## The Essence
[1-2 sentences: What this ACTUALLY is at its core, stripped of complexity]

## Verified Facts
- [Fact 1] — evidence: `path/file:line` or [source]
- [Fact 2] — evidence: ...
- [Fact 3] — evidence: ...

## Key Points (Top 5-10)
1. **[Most Important]**: [Explanation]
2. **[Second]**: [Explanation]
...

## Assumptions to Challenge

| Assumption | Evidence For | Evidence Against | Verdict |
|------------|-------------|------------------|---------|
| [Assumed thing] | [If any] | [If any] | Validate/Keep/Discard |

## What You Haven't Considered

1. **[Critical Item]**: [Why this matters, what to do about it]
2. **[Hidden Risk/Opportunity]**: [Explanation]
3. **[Simpler Alternative?]**: [If exists, describe it]

## The Real Question
[Reframe what the user should actually be asking about this]

## Quick Actions (Top 3-5)
- [ ] [Action 1] - [Why/Impact]
- [ ] [Action 2] - [Why/Impact]
- [ ] [Action 3] - [Why/Impact]

## Critical Risk to Watch
[The one thing that could derail this]
標準モード
# Analysis: [Target]

**Mode**: Standard | **Domain**: [Domain] | **Perspectives**: [Count]
**Date**: [Date] | **Hypotheses**: [Count] total

## The Essence
[1-2 sentences: What this ACTUALLY is at its core, stripped of complexity]

## Executive Summary
[2-3 sentences capturing most critical findings]

## First-Principles Analysis

### Verified Facts
- [Fact 1] — evidence: `path/file:line` or [source] — confidence: High/Medium/Low
- [Fact 2] — evidence: ... — confidence: ...

### Assumptions to Challenge

| Assumption | Evidence For | Evidence Against | Verdict |
|------------|-------------|------------------|---------|
| [Assumed thing] | [If any] | [If any] | Validate/Keep/Discard |

### What You Haven't Considered

1. **[Critical Item]**: [Why this matters, what to do about it]
2. **[Hidden Risk/Opportunity]**: [Explanation]
3. **[Simpler Alternative?]**: [If exists, describe it]
4. **[Downstream Impact]**: [What this affects that wasn't mentioned]

### The Real Question
[Reframe what the user should actually be asking about this]

## Failure Hypotheses (Aggregated)

| ID | Type | IF (Trigger) | THEN (Failure) | BECAUSE | Sev | Mitigation |
|----|------|--------------|----------------|---------|-----|------------|
| S001 | Security | ... | ... | ... | Crit | ... |
| M001 | Misuse | ... | ... | ... | High | ... |

### Critical Mitigations Required
- [ ] {mitigation} ← Addresses: S001, M001

## Key Points (Ranked by Importance)

### Consensus Points (Flagged by 3+ perspectives)
1. **[Point]** - [Why important] (Flagged by: [Perspectives])

### Important Points
2. **[Point]** - [Explanation]

### Divergent Views
- **[Topic]**: [Perspective A] sees X, [Perspective B] sees Y
  - *Implication*: [What this tension means]

## Gap Analysis

### Critical Gaps (Action Required)
| Gap | Flagged By | Impact | Suggested Action |
|-----|------------|--------|------------------|
| ... | ... | High | ... |

### High Priority Gaps
[Grouped by theme]

## Improvement Opportunities

### Top 5 Improvements
1. **[Improvement]**: [Details] - Expected Impact: [High/Medium/Low]

## Action Plan & Roadmap

### Immediate Actions (This Week)
| Action | Owner | Dependencies | Success Criteria |
|--------|-------|--------------|------------------|
| ... | [TBD] | None | ... |

### Short-term (1-2 Weeks)
| Action | Dependencies | Resources Needed | Outcome |
|--------|--------------|------------------|---------|
| ... | Immediate #1 | ... | ... |

## Cross-cutting Concerns
[Issues flagged by 3+ perspectives]
ディープモード

ディープモードでは、標準形式を次の内容で拡張します。

  • エージェントごとに質問を 5 件追加(合計 12 件)
  • 中期(1 か月)および長期(3 か月以上)のロードマップセクション
  • 依存関係マップの可視化
  • リスク軽減テーブル
  • より詳細な失敗の仮説

視点ライブラリ

ドメイン検出

コンテンツ/キーワードを分析し、ドメインを自動検出します。

ドメイン判定キーワード対象の例
businessstartup, business, market, revenue"coffee subscription", business-plan.md
productproduct, feature, user, MVP"habit tracking app", roadmap.md
softwareAPI, code, function, class, techsrc/auth, package.json
processworkflow, process, SOP, operations"hiring workflow", "incident response"
documentdoc, article, proposal, report"resume", proposal.docx
researchresearch, study, hypothesis, data"hypothesis: remote work"
creativedesign, art, brand, visual"rebrand", logo-designs/
personaldecision, "should I", career, life"moving to Austin", "career change"
legalcontract, legal, policy, terms"employment contract"
financialbudget, investment, cost, ROI"Q4 budget", "pricing strategy"
marketingcampaign, marketing, sales, brand"email campaign", "launch strategy"
eventevent, conference, launch"product launch", "conference plan"
educationcourse, curriculum, teaching"bootcamp curriculum"
general(該当するドメインがない場合のフォールバック)あらゆる一般的なトピック
ドメイン別の視点と役割
ビジネスドメイン
  1. スタートアップ創業者 - 事業の実現可能性、成長、拡張性
  2. 投資家 - ROI、リスク、市場規模
  3. CFO - ユニットエコノミクス、バーンレート、利益率
  4. 顧客 - 価値提案、支払い意欲
  5. 競合他社 - 差別化、競争上の優位性
  6. 市場アナリスト - TAM、トレンド、タイミング
プロダクトドメイン
  1. プロダクトマネージャー - ユーザーニーズ、ロードマップ、優先順位付け
  2. デザイナー(UX) - ユーザビリティ、ユーザーフロー、アクセシビリティ
  3. 顧客 - 実際のユースケース、ペインポイント
  4. QA エンジニア - エッジケース、エラー状態
  5. データアナリスト - 指標、成功基準
  6. サポートリード - 保守の負担、ユーザーの混乱
ソフトウェアドメイン
  1. セキュリティエンジニア - 脆弱性、攻撃ベクトル
  2. DevOps - デプロイ、モニタリング、信頼性
  3. アーキテクト - デザインパターン、拡張性、技術的負債
  4. QA エンジニア - テストカバレッジ、エッジケース
  5. パフォーマンスエンジニア - ボトルネック、リソース使用量
  6. テックリード - 保守性、チームの開発速度
プロセスドメイン
  1. オペレーター - 日々の実行、摩擦点
  2. マネージャー - 効率性、ボトルネック、指標
  3. 従業員 - 体験、明確さ、ペインポイント
  4. 監査人 - コンプライアンス、ドキュメント、リスク
  5. 改善スペシャリスト - 無駄、最適化
個人領域
  1. 1年後の自分 - 長期的な影響
  2. 5年後の自分 - キャリアの軌跡
  3. 懐疑論者 - リスク、デメリット、失敗モード
  4. 支援者 - 強み、機会
  5. ファイナンシャルアドバイザー - 金銭面への影響
  6. ライフコーチ - 価値観との一致、充実感
一般領域(フォールバック)
  1. アナリスト - 事実、データ、パターン
  2. 批評家 - 弱点、リスク、ギャップ
  3. 提唱者 - 強み、機会
  4. プラグマティスト - 実現可能性、リソース、スケジュール
  5. ストラテジスト - 長期的な影響、代替案
  6. デビルズ・アドボケイト - 考慮されていないデメリット
エージェントごとのプロンプトテンプレート

標準モード(7つの質問):

You are a [Role]. Analyze:
TARGET: [content]

Answer these 7 questions:
1. KEY POINTS: 3-5 most important elements?
2. CORE INSIGHT: Single most critical thing?
3. GAPS: What's missing or incomplete?
4. RISKS: What could go wrong?
5. ASSUMPTIONS: What needs validation?
6. IMPROVEMENTS: Top 3 ways to improve?
7. BLIND SPOTS: What isn't being considered?

FAILURE HYPOTHESES: For each risk/gap:
| ID | IF (Trigger) | THEN (Failure) | BECAUSE | Severity | Mitigation |

Include MISUSE + ADVERSARIAL hypotheses.
Rate findings: Critical/High/Medium/Low

詳細モード(12個の質問=中核となる7つ+追加の5つ):

  1. 依存関係:成功は何に依存しますか?
  2. 代替案:他に検討すべきアプローチはありますか?
  3. スケジュール上のリスク:遅延や失敗の原因となるものは何ですか?
  4. リソースの不足:適切に実行するために不足しているものは何ですか?
  5. 成功指標:成功をどのように測定しますか?

思考フレームワーク

UltraThink のループ
THINK → CHECKLIST → PLAN → EXECUTE → VALIDATE → LEARN
フェーズ 0:思考

タスクの種類に応じて思考モデルを選択します:

モデル使用する場面パターン
CoT(思考の連鎖)直線的で順序立ったタスクステップごとの推論
ToT(思考の木)複数の有効な経路、意思決定分岐を評価し、最善のものを選択
Reflexion失敗からの学習、再試行ロジックエラーを分析 → 調整 → 再試行
分解複雑なタスク、並列作業サブ問題に分割

分析の場合: 標準/詳細モードではToT(複数の視点から評価)、クイックモードではCoTを使用します。

フェーズ 1:チェックリスト
  • モードを検出済み(quick/standard/deep)[blocking]
  • 領域を特定済み [blocking]
  • 対象コンテンツにアクセス可能 [blocking]
  • 視点を選択済み [blocking]
  • エージェントを並列でディスパッチ済み [blocking]
  • すべてのエージェントが完了 [blocking]
  • 統合が完了 [advisory]
フェーズ 2:計画

標準/詳細モードの場合:

1. Detect mode from keywords
2. Detect domain from content
3. Select N perspectives (4-6 for standard, 6-10 for deep)
4. Launch all agents in ONE message block
5. Wait for completion
6. Synthesize findings
7. Generate output
フェーズ 3:実行

進捗を追跡しながら計画を実行します。失敗した場合 → Reflexion を起動します(最大2回再試行)。

フェーズ 4:検証
  • すべてのエージェントが調査結果を返しましたか? ✓
  • 分野横断的な懸念事項を特定しましたか? ✓
  • 実行可能なロードマップを作成しましたか? ✓
フェーズ 5:学習

継続的な改善のためにパターンを記録します。

自己修正ガイド
問題確認事項修正次の場合はエスカレーション
分析が浅い領域を自動検出しましたか?具体的な視点を追加2回再試行しても浅いまま
モードの不一致ユーザーのキーワードは?明確化を求めるエージェント数が一致しない
統合が弱いすべてのエージェントが完了しましたか?失敗したエージェントを再実行有用な視点が3つ未満
領域が間違っているキーワードが曖昧ですか?ユーザーに明示的に尋ねる複数の領域が同程度に妥当

最大反復回数:2 | エスカレーション:ユーザーに領域/視点の指定を求める


第一原理分析

考え方:単に要約するのではなく、基本原理まで分解し、実際に真実であることと仮定されていることを明らかにして、ユーザーが考慮していない点を提起します。ユーザーが自分で判断できるよう、必ずデータを提供します。

A. 検証済みの事実(仮定と分ける)
  • 証拠を使って検証できることのみを報告する
  • 情報源を含める:path/file:line または [URL]
  • 確信度を示す:高(検証済み)/中(推定)/低(述べられているが未検証)
B. 第一原理による分解

見つかったすべてのものに、次の質問を適用します:

1. 仮定を問い直す
  • 検証されていないまま、何が仮定されていますか?
  • この制約は本当に存在するものですか、それとも過去の判断を引き継いだものですか?
  • [仮定]が誤りだった場合、何が変わりますか?
2. 基本原理まで分解する
  • これが機能するために、必ず成り立たなければならないことは何ですか?
  • 実際の依存関係は何ですか(単に述べられているものではなく)?
  • これ以上分解できない中核は何ですか?
3. システム思考
  • 他に何へ影響しますか?(上流/下流)
  • これが失敗した場合、影響範囲はどこまで及びますか?
  • 同じリソースを取り合っているものは何ですか?
4. 根本原因と症状
  • 現状は根本原因に対処していますか。それとも症状を隠していますか。
  • なぜ現在の形で存在しているのでしょうか。
  • これはもともと、どのような問題を解決するものでしたか。
C. 検証すべき前提(必須)

すべての分析で、必ず以下の表を含めてください。

前提裏付けとなる証拠反証となる証拠判定
[想定される事柄][あれば記載][あれば記載]検証する/維持する/破棄する
D. 検討されていない点(必須:2~4項目)

ユーザーが見落としている可能性が高い項目を提示してください。

カテゴリ確認する内容
未検証の前提証拠がないまま真実として扱われている事柄
隠れた依存関係依存していることが分かりにくい要素
下流への影響これを変更すると、何が壊れるか
よりシンプルな代替案10倍シンプルな方法はないか
エッジケースどのような入力や状態で問題が起きるか
技術的負債後々コストにつながる近道
不足している要素明らかに欠けているもの
E. 真に問うべきこと

ユーザーが実際に問うべき内容に問いを再構成してください。多くの場合、ユーザーが提示した質問は適切な問いではありません。


例

例 1:クイックモード
Input: analyze quick "our pricing strategy"

Output:
# Quick Analysis: Pricing Strategy

**Mode**: Quick | **Domain**: Business | **Date**: 2026-01-28

## The Essence
A business decision about how to extract value from customers, constrained by market dynamics and competitive positioning.

## Verified Facts
- (Would include actual facts from provided content)

## Key Points
1. **Pricing = value capture, not cost recovery**: Price based on customer willingness to pay, not internal costs
2. **Anchor matters**: First price seen shapes all subsequent evaluations
...

## Assumptions to Challenge
| Assumption | Evidence For | Evidence Against | Verdict |
|------------|-------------|------------------|---------|
| "Customers will pay more if we add features" | Common belief | Often false - bloat reduces WTP | Validate with tests |

## What You Haven't Considered
1. **Price as a signal**: Low price may signal low quality, harming conversion
2. **Competitive response**: Price changes trigger competitor reactions
3. **Simplicity premium**: Simpler pricing often outperforms complex tiers

## The Real Question
Not "what price should we charge" but "what's the maximum value customers perceive, and how do we capture 30-50% of it?"

## Quick Actions
- [ ] Survey 20 target customers on WTP before changing price
- [ ] A/B test 2-3 price points on landing page
- [ ] Model competitor response scenarios

## Critical Risk to Watch
Pricing too low initially makes raising prices later extremely difficult (customer backlash + anchoring effect)
例 2:標準モード
Input: analyze "SaaS product for developers"

Flow:
1. Detect mode: standard (no quick/deep keywords)
2. Detect domain: product + software
3. Select 6 perspectives:
   - Product Manager
   - Developer (user persona)
   - Security Engineer
   - DevOps
   - Support Lead
   - Investor
4. Launch all 6 agents in parallel
5. Synthesize findings into standard format
6. Generate actionable roadmap

Output: [Standard format with all sections filled]
例 3:ディープモード
Input: analyze deep "migration to microservices"

Flow:
1. Detect mode: deep
2. Detect domain: software
3. Select 10 perspectives:
   - Architect
   - DevOps
   - Security Engineer
   - Database Engineer
   - Frontend Developer
   - QA Engineer
   - Performance Engineer
   - SRE
   - Tech Lead
   - CTO
4. Launch all 10 agents in parallel
5. Each answers 12 questions (7 core + 5 deep)
6. Synthesize into deep format with dependency map
7. Generate comprehensive roadmap (immediate/short/medium/long)

Output: [Deep format with extended sections]

よくある失敗パターン

失敗根本原因Reflexion での対応
ドメインの判定を誤るキーワードが曖昧ユーザーに明示的に確認するか、General ドメインを使用する
視点が少なすぎる複雑なトピックにクイックモードを使用標準モードに切り替える
統合が不十分エージェントの出力に一貫性がない明示的な制約を指定して再実行する
見落としがあるありきたりな視点を選択デビルズ・アドボケートの視点を追加する
ロードマップを実行に移せないアクションが曖昧すぎる各アクションを担当者、期限、指標の単位に分解する
分析に2分以上かかるエージェントが多すぎる(ディープモードの過剰使用)標準モードに切り替える

統合に関する注意事項

このスキルはスタンドアロンで、必要なフレームワークをすべて備えています。

  • UltraThink 認知フレームワーク(組み込み)
  • 第一原理分析(組み込み)
  • 視点ライブラリ(組み込み)
  • 出力形式(組み込み)

外部依存関係は不要です。

任意の拡張: TypeScript コードベースのソフトウェアドメイン分析には、codebase-intelligence CLI(npx codebase-intelligence --json)で構造データ(ホットスポット、結合度、未使用のエクスポート、モジュール境界、変更影響範囲)を取得できます。検出条件:tsconfig.json が存在すること。CLI の全リファレンスを取得するには、https://raw.githubusercontent.com/bntvllnt/codebase-intelligence/main/llms-full.txt を取得してください。このスキルはこれがなくても同様に動作します。データは視点エージェントが利用する補足コンテキストです。


ライセンス

MIT License - 自由に使用、改変、配布できます。


バージョン

v1.0.0 - 2026-01-28 - bntvllnt による初回公開リリース

コメント