seika139/discover

<!-- codex-profile-generated-from-prompt: prompts/discover.md -->

discover

この skill は Claude command /discover から変換した Codex 用 command skill です。

Codex での呼び出し

Codex CLI では /discover ではなく、$discover または /skills からこの skill を呼び出してください。 引数は $discover の後ろに自然文として続けます。

$discover <arguments>

元 prompt 内の $ARGUMENTS や slash command 表記は、$discover の後ろに書かれた引数として解釈してください。 Claude 専用の allowed-tools メタデータや ! command interpolation は Codex では自動適用されないため、必要な情報は通常の shell command で確認してください。

元 prompt

Discover

「なんか使いにくい」「パフォーマンスが悪い気がする」のような曖昧な課題意識を出発点に、 コードベースやスクリーンショットを分析して、具体的な改善 Issue の草案を生成する。

目的

人間が詳細を言語化する手間を省き、方向性だけで Issue を生み出す。 /solve-issue の前段として、Issue を「書く」のではなく「選ぶ」に変える。

引数のパースルール

/discover <改善したいこと> [--repo <owner/repo>] [--screenshot <path>]

• 第1引数: 改善したいことの自然言語記述（1行でも数行でも可）
• --repo: 対象リポジトリを指定（省略時はカレントリポジトリ）
• --screenshot: スクリーンショットのパス（UI/UX 分析時に使用）

例

/discover "UI/UX を改善したい"
→ フロントエンドのコードを分析し、UI/UX の問題点を列挙

/discover "パフォーマンスが遅い気がする" --repo org/repo
→ API のコードを分析し、パフォーマンスのボトルネック候補を列挙

/discover "フロントのデザインがダサい" --screenshot ~/screenshots/current-ui.png
→ スクリーンショットとコードの両方を分析

/discover "セキュリティ面で不安がある"
→ セキュリティ観点でコードを監査

---

Step 1: 課題の方向性を分類する

ユーザーの入力を以下のカテゴリに分類する。複数該当する場合は最も強いものを主軸とする。

| カテゴリ | キーワード例 | 分析の重点 | | :------------- | :--------------------------- | :------------------------------------------------ | | UI/UX | 使いにくい、デザイン、見た目 | コンポーネント構造、UX パターン、アクセシビリティ | | パフォーマンス | 遅い、重い、タイムアウト | N+1 クエリ、不要な再レンダリング、キャッシュ戦略 | | セキュリティ | 不安、脆弱性、認証 | OWASP Top 10、認証認可、入力バリデーション | | コード品質 | 読みにくい、複雑、技術的負債 | 循環的複雑度、重複コード、テストカバレッジ | | アーキテクチャ | 設計、構成、拡張性 | 結合度、責務分離、スケーラビリティ | | 機能 | 足りない、欲しい、改善 | 既存機能の分析、ギャップの特定 |

分類結果をユーザーに提示して確認する:

入力を「UI/UX の改善」として分析します。よろしいですか？
他に重点的に見てほしい観点があれば教えてください。

---

Step 2: コードベースの調査

2-1: リポジトリの全体構造を把握する

# ディレクトリ構造の把握
find . -type f -not -path './.git/*' -not -path './.venv/*' -not -path './node_modules/*' -not -path './.next/*' | head -200

# 設定ファイルの確認（技術スタック特定）
cat package.json 2>/dev/null || cat pyproject.toml 2>/dev/null
cat mise.toml 2>/dev/null

2-2: カテゴリ別の重点調査

UI/UX の場合

• コンポーネント一覧とその構造
• ルーティング設計
• 状態管理の方式
• エラーハンドリング（ユーザーへのフィードバック）
• ローディング状態の実装
• レスポンシブ対応
• スクリーンショットが提供されていれば視覚的に分析

パフォーマンスの場合

• DB クエリパターン（N+1、インデックス未使用）
• API レスポンスのデータ量
• キャッシュ戦略の有無
• 非同期処理の活用状況
• フロントエンドのバンドルサイズ

セキュリティの場合

• 認証・認可の実装
• 入力バリデーション
• SQL インジェクション、XSS の可能性
• シークレット管理
• CORS 設定
• 依存パッケージの脆弱性

コード品質の場合

• テストカバレッジ
• 重複コード
• 関数の長さ・複雑度
• エラーハンドリングの一貫性
• 命名規則の統一性

アーキテクチャの場合

• レイヤー構造（Controller / Service / Repository 等）
• 依存関係の方向
• 設定の外部化
• 環境ごとの分離

---

Step 3: 問題点の構造化

調査結果を以下の形式で整理する。最大 10 件程度に絞り込む（多すぎると選択が困難になるため）。

各問題点に以下の属性を付ける:

• 深刻度: Critical / High / Medium / Low
• 工数見積もり: S（数時間）/ M（1日）/ L（数日）/ XL（1週間以上）
• 影響範囲: 影響を受けるファイルやコンポーネント
• カテゴリ: Step 1 で分類したカテゴリのサブカテゴリ

---

Step 4: 問題点リストの提示

以下の形式でユーザーに提示する:

📋 コードベース分析結果: {カテゴリ}

対象: {リポジトリ名}
分析範囲: {調査したファイル数・ディレクトリ}

┌─────────────────────────────────────────────────
│ # | 深刻度   | 工数 | 問題点
├─────────────────────────────────────────────────
│ 1 | Critical | M    | {問題の要約}
│   |          |      | → {具体的な箇所と改善案の一行サマリ}
│ 2 | High     | S    | {問題の要約}
│   |          |      | → {具体的な箇所と改善案の一行サマリ}
│ ...
└─────────────────────────────────────────────────

Issue として起票するものを番号で選んでください（例: 1,3,5 または all）。
不要なものや追加の観点があれば教えてください。

---

Step 5: Issue 草案の生成

ユーザーが選択した問題点ごとに Issue の草案を生成する。

草案の形式

## 概要

{問題の詳細な説明}
{なぜこれが問題なのかの背景}

## 現状

{該当するコードの場所・現在の実装の説明}

## 完了条件

- [ ] {具体的な完了条件1}
- [ ] {具体的な完了条件2}
- [ ] {テストに関する条件}

## 技術的な補足

{実装のヒント・参考情報}

ユーザーへの確認

全ての草案を一括で提示し、修正の要望を受け付ける:

上記の Issue 草案でよろしいですか？
- 内容の修正が必要なものはありますか？
- まとめて起票しますか？それとも個別に確認しますか？

---

Step 6: Issue の起票

ユーザーの承認を得たら Issue を起票する。

gh issue create \
  --repo {repo} \
  --title "{タイトル}" \
  --label "{label}" \
  --body "$(cat <<'EOF'
{草案の内容}

---
*🔍 `/discover` による自動分析から起票*
EOF
)"

• ラベルは問題のカテゴリに応じて適切なものを選択する（既存ラベルを gh label list で確認）
• 適切なラベルが存在しない場合はラベルなしで起票する（勝手にラベルを作成しない）

---

Step 7: 報告

📋 /discover 完了

分析対象: {リポジトリ名}
課題カテゴリ: {カテゴリ}
検出した問題: {総数}件
起票した Issue: {起票数}件

{各 Issue の番号・タイトル・URL の一覧}