Back to Details

check-existing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Check Existing Solutions

Check Existing Solutions

実装予定の機能に対して、まず要件を明確化し、その上で既存のライブラリ・ツール・ プロジェクトのローカルパッケージ/モノレポ構成があればそこですでに解決できないかを徹底調査する。 車輪の再発明を避け、独自実装の範囲を最小化することが目的。
For the feature to be implemented, first clarify the requirements, then thoroughly investigate whether existing libraries, tools, local packages within the project, or monorepo components can already solve the problem. The goal is to avoid reinventing the wheel and minimize the scope of custom implementations.

When to Use

When to Use

  • 新機能の着手前（Plan Mode に入る前段の調査として）
  • 「自前で書くか既存を使うか」の判断が必要なとき
  • 曖昧な要望（例: 「画像処理の何か」）から的確な既存解を見つけたいとき
要件が完全に固まっていなくても起動してよい。ヒアリングで具体化する。
  • Before starting work on a new feature (as preliminary research before entering Plan Mode)
  • When you need to decide whether to build from scratch or use existing solutions
  • When you want to find the right existing solution from vague requests (e.g., "something for image processing")
You can start this process even if requirements aren't fully finalized; refine them through interviews.

Workflow

Workflow

Phase 1: 過去知識の確認

Phase 1: Review Past Knowledge

着手前に既存の判断・教訓を確認して二度手間を避ける:
  • docs/decisions/
    の ADR インデックス（
    docs/decisions/README.md
    ）
  • docs/lessons-learned.md
    の関連ドメイン
Avoid redundant work by checking existing decisions and lessons learned before starting:
  • ADR index in 
    docs/decisions/
    (see 
    docs/decisions/README.md
    )
  • Relevant domains in 
    docs/lessons-learned.md

Phase 2: 要件明確化ヒアリング（1問ずつ）

Phase 2: Requirement Clarification Interviews (One Question at a Time)

仮定を避け、具体的に問う。多肢選択を優先。
  • 意図: この機能で解決したい具体的な問題は? 現状の不満は?
  • 技術詳細: 処理対象のデータ量は? バッチ/リアルタイム? プロジェクトのどのワークフローに組み込む? 操作は GUI/自動/設定?
  • 制約と優先度: Must-have / Nice-to-have は? パフォーマンス要件(速度・メモリ・精度)は? シンプルさ優先か?
  • 検索語: 英語で言うと? 業界用語は? 知っている類似ツールは? PyPI/GitHub で何で検索する?
Avoid assumptions and ask specific questions; prioritize multiple-choice formats.
  • Intent: What specific problem does this feature aim to solve? What are the current pain points?
  • Technical Details: What is the volume of data to process? Batch or real-time? Which workflow in the project will it be integrated into? Will the operation be GUI-based, automated, or configuration-driven?
  • Constraints and Priorities: What are the must-have vs. nice-to-have features? What are the performance requirements (speed, memory, accuracy)? Is simplicity a priority?
  • Search Terms: What is this called in English? Are there any industry terms? Are there any similar tools you know of? What would you search for on PyPI/GitHub?

Phase 3: 要件定義の整理

Phase 3: Organize Requirement Definitions

markdown
undefined
markdown
undefined

明確化された要件

Clarified Requirements

核心機能

Core Functions

  • メイン処理 / 入力形式 / 出力形式
  • Main processing / Input format / Output format

技術的要件

Technical Requirements

  • 統合箇所(プロジェクト内のどこ) / パフォーマンス / 既存依存との関係
  • Integration location (where in the project) / Performance / Relationship with existing dependencies

機能的要件

Functional Requirements

  • Must-have / Nice-to-have / 制約・除外
  • Must-have / Nice-to-have / Constraints & Exclusions

検索キーワード候補

Candidate Search Keywords

  • メイン / 技術 / ドメイン
undefined
  • Main / Technical / Domain
undefined

Phase 4: 既存解の調査

Phase 4: Research Existing Solutions

プロジェクト内を先に、次に外部 OSS を段階検索する。
  1. プロジェクト内の代替を確認（最優先） 
    • investigation
      agent で既存実装・類似機能を調査
    • プロジェクトのローカルパッケージ/モノレポ構成があれば、そこで代替可能性を確認
    • Bash uv tree
      / 
      Grep
      で既存依存・統合箇所を確認
  2. 外部 OSS を段階検索
    • 第1段: PyPI / GitHub Topics / 標準ライブラリ（
      WebSearch
      ）
    • 第2段: 実装例・比較記事・Stack Overflow（
      WebSearch
      / 
      WebFetch
      ）
    • 第3段: 最新動向・トレンド（
      WebSearch
      、現在年を明示）
    • ライブラリの一次ドキュメントは Context7 MCP (利用可能なら) または公式ドキュメントの 
      WebFetch
      で取得
  3. 候補の評価 
    • solutions
      agent で複数候補を生成・比較（適合度・実装コスト・リスク）
Search within the project first, then search external open-source software (OSS) in stages.
  1. Check for alternatives within the project (highest priority)
    • Use the 
      investigation
      agent to research existing implementations and similar features
    • If the project has local packages or a monorepo structure, check for potential alternatives there
    • Use 
      Bash uv tree
      / 
      Grep
      to check existing dependencies and integration points
  2. Stage-wise search for external OSS
    • Stage 1: PyPI / GitHub Topics / Standard libraries (using 
      WebSearch
      )
    • Stage 2: Implementation examples, comparison articles, Stack Overflow (using 
      WebSearch
      / 
      WebFetch
      )
    • Stage 3: Latest trends and developments (using 
      WebSearch
      , specify the current year)
    • Retrieve primary library documentation via Context7 MCP (if available) or 
      WebFetch
      from official documentation
  3. Evaluate candidates
    • Use the 
      solutions
      agent to generate and compare multiple candidates (fit, implementation cost, risk)

Phase 5: 評価・記録・推奨

Phase 5: Evaluate, Document, and Recommend

markdown
undefined
markdown
undefined

既存解調査結果

Existing Solutions Research Results

要件（Phase 3 の整理）

Requirements (from Phase 3 organization)

調査プロセス

Research Process

  • 検索キーワード / 調査ソース / 発見候補数
  • Search keywords / Research sources / Number of discovered candidates

発見された既存解

Discovered Existing Solutions

🎯 完全代替可能（適合度 90%+）

🎯 Fully Replaceable (Fit Score 90%+)

  • ライブラリ名 / 統合方法 / 推奨度
  • Library name / Integration method / Recommendation level

🔧 組み合わせ利用（60-89%）

🔧 Combined Usage (Fit Score 60-89%)

  • 主ライブラリ / 補完方法 / 実装工数
  • Main library / Complementation method / Implementation effort

📚 参考実装（30-59%）

📚 Reference Implementation (Fit Score 30-59%)

  • 参考価値 / 独自実装が要る範囲
  • Reference value / Scope requiring custom implementation

最終推奨

Final Recommendation

✅ 採用推奨

✅ Recommended for Adoption

  • 選択理由 / 統合手順 / 注意点
  • Reason for selection / Integration steps / Notes

⚠️ 独自実装が必要な場合

⚠️ When Custom Implementation is Required

  • 既存解の限界 / 最小実装範囲 / 部分的に使える既存機能

調査結論のうち再利用価値のあるもの（ライブラリ評価、build-vs-reuse の判断根拠）は
ADR (`docs/decisions/`) などプロジェクトの記録先へ残すことを推奨に含める。
  • Limitations of existing solutions / Minimum implementation scope / Existing features that can be partially used

Include in your recommendation to document reusable research conclusions (such as library evaluations and build-vs-reuse decision rationale) in project records like ADRs (`docs/decisions/`).

Next Step

Next Step

要件が固まり既存解が出そろったら、ネイティブ Plan Mode（
/plan
）または superpowers 
brainstorming
→ 
writing-plans
へ引き継ぐ。本 skill は調査までを担い、設計・実装はしない。
Once requirements are finalized and existing solutions are identified, hand over to native Plan Mode (
/plan
) or superpowers 
brainstorming
→ 
writing-plans
. This skill only handles research; it does not cover design or implementation.