This skill should be used when the user asks to "最小再現環境を作って", "再現環境を構築して", "問題を切り分けたい", "パッケージの不具合か確認したい", "create a minimal reproduction", "isolate the issue", "build a repro environment", "reproduce this bug", "narrow down the cause", "is this a package bug or my code", "このPRの問題を再現して", "this commit broke something", or wants to determine whether a bug is caused by a package, the environment, or application code. Accepts PR URLs, commit hashes, or branch names as input.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
パッケージ・環境・アプリコードのどこに原因があるか切り分けるため、最小再現環境を複数パターン一括生成するスキル。
$ARGUMENTS に問題の説明が含まれる場合はそれを使用する。
含まれない場合は以下を確認する:
$ARGUMENTS に PR URL（https://github.com/.../pull/123）や #123 が含まれる場合、gh pr view で PR の説明・変更ファイル一覧を取得する。
コミットハッシュやブランチ名が含まれる場合、git log / git show で変更内容を取得する。
これらから以下を抽出する:
package.json の diff）問題が起きたプロジェクトから以下を収集する:
package.json を読み、関連パッケージとバージョンを特定するtsconfig.json があれば TypeScript 設定を確認するnode -v）を記録する以下の基本パターンから、問題に適したものを選択する。詳細は references/patterns.md を参照。
| パターン | 目的 | いつ使うか |
|---|---|---|
| baseline | 現環境の最小再現 | 常に作成（必須） |
| version-matrix | パッケージバージョン違い | パッケージ起因を疑う場合 |
| isolation | 特定パッケージを除外/置換 | 依存の組み合わせを疑う場合 |
| code-variant | コードの書き方を変える | アプリコード起因を疑う場合 |
パターン選定後、ユーザーに以下を確認する（ユーザーの指示から明確にパターンが決まる場合は確認を省略してよい）:
デフォルトの親ディレクトリはカレントディレクトリと同階層（../<repro-問題名>/）に作成する。
ユーザーの指定がある場合はそのパスを使用する。
repro-<issue-name>/
├── REPORT.md # 内部レポート（ユーザー向け・随時更新）
├── REPORT-EXTERNAL.md # 外部レポート（パッケージ作者・コミュニティ向け）
├── baseline/ # 現環境の最小再現
│ ├── package.json
│ ├── tsconfig.json # (必要な場合)
│ ├── repro.ts # 最小再現コード
│ └── README.md # 再現手順
├── pattern-a/ # バージョン違い等
│ ├── package.json
│ ├── repro.ts
│ └── README.md
└── pattern-b/ # 別パターン
├── ...
└── README.md
scripts/init-repro.sh を使って雛形を一括生成する:
bash <skill-dir>/scripts/init-repro.sh <parent-dir> baseline pattern-a pattern-b
その後、各パターンの内容をカスタマイズする:
package.json のバージョンやコードを目的に合わせて変更するREADME.md を テンプレートのまま残さず、必ず具体的な内容で埋める（英語で記述する）:
.js で十分各パターンディレクトリで以下を実行する:
cd <pattern-dir> && pnpm install && pnpm run repro
README.md の "Actual Behavior" セクションに実際の結果（エラーメッセージや出力）を記入する。テンプレートのコメントを残さず、具体的な内容で置き換える親ディレクトリに 2種類のレポート を出力する。テンプレートは references/report-template.md を参照。
REPORT.md）ユーザー自身が読むためのレポート。元プロジェクトの文脈（リポジトリ URL、PR、ブランチ名、ファイルパス等）をそのまま含めてよい。
含める内容:
REPORT-EXTERNAL.md）パッケージ作者やそのパッケージを使う開発者が読むためのレポート。問題を一般化し、特定プロジェクトの文脈に依存しない形で記述する。Issue 報告や知見共有にそのまま使える品質にする。
内部レポートとの違い:
package.json と再現コードの全文を含める）含める内容:
package-x v3.0.0 で ESM 環境から functionY を呼ぶとエラーになる"）package.json と再現コードの全文を含む、コピー&ペーストで再現可能な手順外部レポート作成時に、関連パッケージの GitHub リポジトリで既存の Issue を検索する。
調査手順:
gh search issues "<エラーメッセージやキーワード>" --repo <package-owner>/<package-repo> で検索する--state all）外部レポートの「既知の Issue・関連情報」セクションに結果を記載する:
両レポートは作業の進行に合わせて常に最新の状態を保つ:
結果を踏まえて追加の切り分けが必要な場合、既存パターンを基に新しいパターンを作成する。
scripts/init-repro.sh の --from オプションで既存パターンをコピーして派生を作る:
# baseline を基に新パターンを作成（ファイルをコピーし、差分だけ変更する）
bash <skill-dir>/scripts/init-repro.sh <parent-dir> --from baseline new-pattern-name
# 単純コピー（--copy: node_modules もコピーし pnpm install を省略できる）
bash <skill-dir>/scripts/init-repro.sh <parent-dir> --copy baseline exact-copy-name
--from: package.json, repro.ts, tsconfig.json 等のソースファイルをコピーする。node_modules と pnpm-lock.yaml はコピーしない（依存を変更する前提のため）--copy: ディレクトリを丸ごとコピーする（node_modules 含む）。同一構成で別条件（環境変数違い等）を試す場合に使う派生後、目的に合わせて package.json やコードを編集し、Step 5 の手順で動作確認する。
あるパターンにテストやファイルを追加した場合、scripts/sync-repro.sh で他のパターンにも同じ変更を横展開する。
# baseline に追加した test.ts と vitest.config.ts を全パターンに横展開
bash <skill-dir>/scripts/sync-repro.sh <parent-dir> baseline test.ts vitest.config.ts
# 特定のパターンだけに横展開
bash <skill-dir>/scripts/sync-repro.sh <parent-dir> baseline test.ts -- version-a version-b
# baseline にあって他のパターンにないファイルを自動検出して横展開
bash <skill-dir>/scripts/sync-repro.sh <parent-dir> --new baseline
package.json と pnpm-lock.yaml はデフォルトで横展開対象外（各パターンで依存が異なるため）。--force で上書き可能pnpm install を再実行する調査が完了したら、再現環境を GitHub リポジトリとして公開する。外部レポートや Issue 報告から参照できるようにする。
デフォルトでは 1つのリポジトリに全パターンを含める（モノレポ構成）。 ただし、以下のケースではモノレポが再現のハードルになるため、ユーザーに提示してシングルリポ（パターンごとに別リポジトリ）への切り替えを検討する:
.node-version や engines が競合する場合pnpm-workspace.yaml の有無が結論に影響する場合（workspace 環境でのみ再現するバグ等）pnpm install に干渉する場合（ホイスティングの問題等）これらに該当しない限り、モノレポで進める。
.gitignore を作成する。レポートファイルはリポジトリに含めない（REPORT.md はプロジェクト内部情報を含むため、REPORT-EXTERNAL.md は日本語の作業用ドキュメントであり英語の README.md が公開用を兼ねるため）:
node_modules/
REPORT.md
REPORT-EXTERNAL.md
REPORT-EXTERNAL.md）の内容をベースにリポジトリのルートに README.md を 英語で 作成する。再現手順は各パターンディレクトリへの相対リンクで参照する。これが再現リポジトリの公開用ドキュメントとなるREADME.md が「目的・再現手順・期待と実際の挙動」を含んでいることを確認するgh コマンドでリポジトリを作成し push する:
cd <parent-dir>
git init
git add .
git commit -m "Minimal reproduction for <問題の概要>"
gh repo create <repo-name> --public --source=. --push
リポジトリ名は repro-<パッケージ名>-<問題の要約> のような命名にする（例: repro-vite-esm-build-error）。
公開範囲（--public / --private）はユーザーに確認する。
リポジトリ作成後、両レポートにリポジトリ URL を追記する:
.env や認証情報は再現環境にコピーしないpnpm-workspace.yaml がある場合、workspace 外に配置するか pnpm-workspace.yaml を空で置くREADME.md、各パターンの README.md、コード内コメント、コミットメッセージ）。再現リポジトリは公開を前提とし、パッケージ作者や国際的なコミュニティが読めるようにするREPORT.md（内部レポート）と REPORT-EXTERNAL.md（外部レポート）は日本語で書く。これらは gitignore されリポジトリには含まれないREPORT.md はプロジェクト内部情報を含むため絶対にコミットしない。REPORT-EXTERNAL.md も日本語の作業用ドキュメントであり、英語の README.md が公開用を兼ねるためコミットしない。.gitignore で必ず除外するreferences/patterns.md — 切り分けパターンの詳細と判断フローチャートreferences/report-template.md — REPORT.md のテンプレートと記述ガイドscripts/init-repro.sh — パターンディレクトリの一括生成・派生・コピーscripts/sync-repro.sh — あるパターンの変更を他のパターンに横展開まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
This skill should be used when the user asks to "プロジェクトを解析して", "コードベースを調べてドキュメント化して", "移行作業の準備をして", "新機能実装の前にプロジェクトを整理して", "analyze this codebase", "document the project structure", "既存プロジェクトのCLAUDE.mdを作って", or wants to prepare CLAUDE.md and architecture docs before a migration, feature development, or onboarding.
This skill should be used when the user asks to "このエラーを直して", "help me debug this", "fix this stack trace", "なぜこのエラーが出るの", "CI が落ちた", or pastes an error message or stack trace and wants help diagnosing it. Classifies the error type, identifies related files, and proposes up to three root-cause hypotheses with concrete fix plans.
This skill should be used when the user asks to "ドキュメントを更新して", "sync the docs", "update CLAUDE.md after this change", "実装に合わせてドキュメントを直して", or notices that docs have drifted from the codebase. Diffs git history to identify what changed, proposes targeted updates to CLAUDE.md, docs/architecture.md, docs/requirements.md, and README.md, then applies only approved changes.
Explain selected code or a specified file/function in plain language, including what it does, why it exists, and potential pitfalls
日本語の概要は準備中です。原文の説明を表示しています。
This skill should be used when the user asks to "このファイルを変えたら何が壊れる？", "what depends on this function", "影響範囲を調べて", "show me what imports this module", or wants to understand the blast radius before modifying a shared utility, exported type, or public API. Traces import/require references up to two levels deep and lists affected test files.
This skill should be used when the user asks to "このIssueを実装して", "implement this issue", "fix this bug", "このタスクをやって", "Issue