check-existing

Check Existing Solutions

For the features planned for implementation, first clarify the requirements, and then thoroughly investigate whether they can already be solved by existing libraries, tools, or the project's local packages/monorepo structure, if any. Avoid reinventing the wheel and minimize the scope of custom implementationis the purpose.

When to Use

• Before starting a new feature (as a preliminary investigation before entering Plan Mode)
• When a decision is needed on "whether to write it ourselves or use an existing solution"
• When you want to find an accurate existing solution from a vague request (e.g., "something for image processing")

It is fine to start even if the requirements are not fully settled. Clarify them through interviews.

Workflow

Phase 1: Confirming past knowledge

Before starting, confirm existing decisions and lessons learned to avoid duplicated effort:

• docs/decisions/ ADR index (docs/decisions/README.md）
• docs/lessons-learned.md related domains

Phase 2: Requirements clarification interviews (one question at a time)

Avoid assumptions and ask concretely. Prefer multiple choice.

• Intent: What specific problem do you want to solve with this feature? What are the current frustrations?
• Technical details: What is the volume of data to be processed? Batch or real-time? Which workflow in the project will it be integrated into? Is the operation GUI/automated/configured?
• Constraints and priorities: What are the Must-haves / Nice-to-haves? What are the performance requirements (speed, memory, accuracy)? Is simplicity the priority?
• Search terms: How would you say it in English? What is the industry terminology? What similar tools do you know? What would you search for on PyPI/GitHub?

Phase 3: Organizing the requirements definition

## 明確化された要件
### 核心機能
- メイン処理 / 入力形式 / 出力形式
### 技術的要件
- 統合箇所(プロジェクト内のどこ) / パフォーマンス / 既存依存との関係
### 機能的要件
- Must-have / Nice-to-have / 制約・除外
### 検索キーワード候補
- メイン / 技術 / ドメイン

Phase 4: Investigating existing solutions

Search within the project first, then search external OSS in stages.

1. Check for alternatives within the project(highest priority)
   • investigation investigate existing implementations and similar features with the agent
   • If the project has local packages/monorepo structure, check the possibility of alternatives there
   • Bash uv tree / Grep check existing dependencies and integration points with
2. Search external OSS in stages
   • Stage 1: PyPI / GitHub Topics / standard library (WebSearch）
   • Stage 2: Implementation examples, comparison articles, Stack Overflow (WebSearch / WebFetch）
   • Stage 3: Latest developments and trends (WebSearch, specify the current year)
   • Obtain the primary documentation for libraries via Context7 MCP (if available) or the official documentation's WebFetch with
3. Evaluation of candidates
   • solutions generate and compare multiple candidates with the agent (fit, implementation cost, risk)

Phase 5: Evaluation, recording, and recommendation

# 既存解調査結果

## 要件（Phase 3 の整理）

## 調査プロセス
- 検索キーワード / 調査ソース / 発見候補数

## 発見された既存解
### 🎯 完全代替可能（適合度 90%+）
- ライブラリ名 / 統合方法 / 推奨度
### 🔧 組み合わせ利用（60-89%）
- 主ライブラリ / 補完方法 / 実装工数
### 📚 参考実装（30-59%）
- 参考価値 / 独自実装が要る範囲

## 最終推奨
### ✅ 採用推奨
- 選択理由 / 統合手順 / 注意点
### ⚠️ 独自実装が必要な場合
- 既存解の限界 / 最小実装範囲 / 部分的に使える既存機能

Among the investigation conclusions, include in the recommendation that those with reuse value (library evaluations, the rationale for build-vs-reuse decisions) should be recorded in the project's record location such as an ADR (docs/decisions/).

Next Step

Once the requirements are settled and existing solutions are identified, hand off to native Plan Mode (/plan) or superpowers brainstorming → writing-plans . This skill handles only the investigation and does not do design or implementation.