Skill.md検索

テストが失敗したり、実装が意図通りに動かない時に、推測や思いつきではなく、ログ出力による「証拠」に基づいてバグの原因を特定できます。 考えられる原因を5～7個列挙し、最も可能性の高いものに絞って検証するため、闇雲なデバッグの時間を大幅に削減できます。 修正後も、デバッグログをすべて削除し、プロジェクト全体の一貫性を保った状態でコミットできます。 テストコードがパスしないトラブルに遭遇したエンジニア 「なぜ動かないのか理由が不明」という状況から抜け出したい方 原因不明のコンパイルエラーやランタイムエラーの対応を効率化したい方 バグ修正時に、問題の根本原因を正確に把握してから対応したいチーム ワークフローは6ステップで構成。Step 1：症状の正確な把握。エラーメッセージ・スタックトレース全文確認、期待値と実際値の差分明確化、再現条件の特定を「期待/実際/エラー/再現」テンプレートで記録。Step 2：仮説の列挙（5～7個）。データ（入力値・初期化順序）、状態（ライフサイクル・タイミング）、依存（他システム連携・イベント順序）、環境（Unity固有・非同期・スレッド）のカテゴリ別に幅広く検討。Step 3：絞り込み（1～2個）。エラーメッセージとの整合性、変更履歴との関連、再現パターンの一致、過去類似バグ経験を判断基準に。Step 4：ログによる仮説検証。問題メソッドの入口・出口、条件分岐直前、データ変換前後に Debug.Log で値を出力。Step 5：検証と修正。ログ結果から原因特定し最小限修正、外れたら新仮説を追加検証。Step 6：クリーンアップ。デバッグログ全削除、プロジェクト一貫性確認。アンチパターンは推測修正・一度に大量変更・ログ残し。

Playwright MCP 経由で起動中の Electron アプリ（CDP ポート 9222）のスクリーンショットを撮影できます。 UI 要素をクリック・入力などで操作し、ボタン押下やモーダル表示、言語切り替えなどの動作検証ができます。 JavaScript を実行して DOM 要素の状態を確認し、アプリの内部状態をデバッグできます。 コンソール出力やエラーメッセージを取得し、アプリ側のバグ診断ができます。 アコーディオン展開や Settings モーダル表示など、複雑な UI 操作をシーケンスで自動実行できます。 Electron アプリの開発者で、自動テストを書いて UI 動作を検証したい人 ブラウザの DevTools コンソール操作より、スクリプトで自動化して効率化したい人 UI コンポーネント（モーダル・アコーディオン・セレクタなど）が正しく動作するか確認したい人 アプリのスクリーンショットやコンソールログを集めて、バグレポートを作りたい人 このスキルは yarn start（CDP ポート 9222）で起動した Electron アプリを Playwright MCP で操作します。禁止事項：(1) browser_navigate を使うと Electron アプリページを離脱してしまう、(2) browser_snapshot で DOM 全体出力すると数万トークン消費するため browser_evaluate・browser_run_code で必要部分のみ取得、(3) page.goto('about:blank') で離脱禁止（誤操作時は page.goBack() で戻す）、(4) strict mode violation（要素 2 個以上マッチ）を避けるため .first() や data 属性で絞り込み。推奨パターン：スクリーンショットは browser_take_screenshot、クリックはセレクタ + { hasText } + .first() または data-state で絞り込み、アコーディオン開閉は data-state="closed" で検出、DOM 状態確認は .textContent()・.count()・.isVisible() で必要部分のみ取得、言語切り替えは Settings ボタン→Language セレクタで実装。

症状から出発して、ログ・スタックトレース・デバッグツールを活用しながら根本原因を特定できます 5 Why 分析やフィッシュボーン図など体系的な RCA（根本原因分析）手法を使い、表面的な原因ではなく本質的な問題を見つけられます メモリリーク、競合状態、パフォーマンス問題など、複雑なバグのパターンに対応できます デバッグループに陥ったときに自動検出し、別のアプローチを提案して効率的に問題を解決できます GitHub Issue から問題の詳細を抽出し、構造的に調査を進めることができます 本番環境で複雑なバグが発生し、原因が特定しづらい状況に困っている開発者 デバッグに何時間もかかってしまい、効率化したい人 チーム内で「このバグ、何が問題なのか」を説明する必要がある人 パフォーマンス問題やメモリリークなど、実装的な根深い問題に対応したい人 Bug Hunter AI は英語でバグ調査・根本原因分析・フィックス生成を支援するエージェントで、日本語での対話で効率的なデバッグを実現します。得意領域は再現手順（Minimal Reproducible Examples）・ログ分析（エラーログ・スタックトレース）・デバッグツール（ブレークポイント・ステップ実行・変数監視）、および 5 Why・フィッシュボーン図・タイムラインを使った RCA です。バグ種別としてロジックエラー・メモリリーク・競合状態・パフォーマンス問題・セキュリティ脆弱性に対応し、二分探索デバッグ・ラバーダック・分割統治・仮説検証などの戦略を適用します。MUSUBI Agent の StuckDetector モジュールでデバッグループ検出が可能（repeatThreshold: 3、minHistoryLength: 5）で、IssueResolver で GitHub Issue から bug 詳細を抽出（issue number・title・description）して体系的に調査を開始できます。

起動済みChromeから直接メール取得：プロジェクト内に既に起動しているChromeに自動接続し、OAuth設定不要でGmailのメール一覧を取得できます。 キーワード検索で該当メールを抽出：検索クエリを指定して、膨大なメールから必要な情報だけを素早く絞り込めます。 スレッド単位でメール本文を読込：特定のスレッドID を指定してメール本文と返信履歴を一括取得できます。 添付ファイルの自動ダウンロード：メールに含まれるファイルを指定フォルダに自動保存し、手作業を削減できます。 デバッグポート経由でセキュアに接続：既存Chromeセッションを再利用するため、ログイン情報の再入力が不要です。 メール内容を自動抽出して業務システムに連携させたい開発者 大量のメール添付ファイルを一括処理したい事務職・企画担当者 Gmail と連携したBot・自動化システムを構築したいエンジニア プロジェクト内で定期的にメール情報を自動収集・分析したい業務システム管理者 このスキルは、Chrome の既存セッションを利用して Gmail のメールを DOM スクレイピングで取得します。OAuth設定は不要です。このプロジェクトでは Chrome が起動済みのため、常に--no-launchモードで動作し、リモートデバッグプロトコル経由（デフォルトポート9222）で接続します。 実行コマンド：スクリプトディレクトリ（$CLAUDE_PROJECT_DIR/.claude/skills/gmail/scripts）でnpx tsx src/index.ts [command]を実行。①list：メール一覧取得（--no-launch --port 9222）、②search：メール検索（-q "検索クエリ"で指定）、③read：メール本文読取（--thread "スレッドID"）、④download：添付ファイルダウンロード（--output ./downloadsで保存先指定） オプション一覧：--label でラベル指定、--limit で取得件数上限（デフォルト50）、--format json|textで出力形式選択、--no-launchで既存Chrome接続（このプロジェクトでは常に指定必須）、--port でデバッグポート指定（デフォルト9222） 前提条件：Chrome が--remote-debugging-port=9222で起動済みであること、Gmail にログイン済みの Chrome セッションが必要なこと、DOM セレクタは Google の仕様更新で変わる可能性があることに留意してください。

whisper.cpp（OpenAI の Whisper の高速ローカル実装）を使って、マイクからの日本語音声をリアルタイムで文字起こしし、クラウド不要で低遅延を実現します 複数のマイク デバイス（DJI MIC MINI・Razer Seiren Mini・USB マイク）を自動検出・切り替えして、最適な入力ソースを選択できます 文字起こし結果を音声コマンドとして解釈し、VOICEVOX による音声応答や VacuumTube 操作を自動実行する「音声コマンドループ」を常駐運用できます small・medium モデルを切り替えて、精度と速度のトレードオフを実験・比較できます tmux による常駐管理、ログ確認、デバッグ機能で、安定的な音声待ち受け環境を構築・運用できます AI・音声インタフェース開発者：ローカル STT（音声テキスト変換）の実装・検証・チューニング スマートホーム・ロボット開発者：プライベートな音声コマンド操作を実現したい 音声 UX デザイナー：リアルタイム文字起こしと音声応答の体感速度・精度を検証したい Linux/マイク運用担当：PipeWire・PulseAudio 環境での音声入力デバイス管理・デバッグ このスキルは tmux + whisper-server + PipeWire + Python listener で常駐運用され、listen-only（発話検知・文字起こしのみ）と voice command loop（VOICEVOX 応答・VacuumTube 操作）の 2 段階運用を想定しています。前提は whisper.cpp ビルド済み、モデル（ggml-small.bin・ggml-medium.bin）配置済み、pactl・parec 利用可能、tmux・yuiclaw voice-command operator コマンド有効です。実運用デフォルト：ggml-small.bin モデル、言語 ja、VOICEVOX volumeScale=2.5・speedScale=1.25、ack_headstart_ms=120、notify-send 有効、マイク優先順（DJI MIC MINI > Razer Seiren Mini > USB マイク）。重要ルールは listener と agent を同時実行しない（マイク競合）、listen-only で精度・VAD 確認後に音声コマンド化、speed と精度トレードオフを明示、UX は手動確認必須。メインコマンド：start（listen-only 起動）、start-agent（音声コマンド待機）、status（確認）、logs-server/listener/agent（ログ確認）、re（再起動）。

単一・複数エージェントの構築から本番デプロイまで対応：Microsoft Agent Frameworkを使い、シンプルなチャットボットから複雑なマルチエージェントワークフローまで、幅広い規模のAIエージェントをPythonで実装できます。 複数のLLMサービスに対応：OpenAI・Azure OpenAI・Azure AI Foundryなど、組織のインフラに合わせてLLMを選択し、同じコードベースで動作させることが可能です。 Python関数をツール化し、エージェントから自動実行：データベース検索・API呼び出し・ファイル処理など、既存のPython関数をエージェントの「ツール」として登録することで、エージェントが自律的に必要な処理を実行できるようになります。 グラフベースのワークフロー設計で複雑な処理フロー化：順序実行・並列実行・条件分岐といった複雑なエージェント間の連携を、グラフ構造で視覚的に設計・実装・デバッグできます。 人間の承認・介入を組み込み、安全な運用：重要な判断や実行前の確認を人間が行う「Human-in-the-Loop」パターンを組み込むことで、AIの完全自動化ではなく、人間とAIの協働ワークフローを実現します。 AI・機械学習エンジニア：Semantic Kernel・AutoGenからのステップアップで、最新のAgent Frameworkを学びたい方 バックエンド開発者：社内システムにAI機能を統合し、既存コードをエージェントから活用したい方 データエンジニア：データ分析やレポート生成を自動化するAIエージェントを構築したい方 DevOps・インフラチーム：FastAPI・Durable Functions・OpenTelemetryなど、本番環境へのAIエージェントデプロイを推進したい方

chrome-devtools-mcp を使用する際に、Chrome に拡張機能を読み込んで有効にした状態でテスト・デバッグできるように設定します。 別プロセスで拡張機能対応の Chrome を起動し、MCP との通信と独立して拡張機能の動作検証ができます。 コード変更後に Chrome を再起動せず拡張機能だけリロードでき、開発サイクルを高速化できます。 Chrome 拡張機能の開発・テストを MCP 環境で行いたい開発者 拡張機能の動作確認をスクリプトで自動化したい方 Playwright などのブラウザ自動化ツールで拡張機能をテストしたい方 このスキルは4つのステップで構成されます。Step 1 では拡張機能つきの Chrome を別プロセスで起動します。コマンドラインは --remote-debugging-port=9223（MCP の 9222 と被らないようする）、--user-data-dir=/tmp/chrome-ext-test（一時ディレクトリで既存プロファイルと分離）、--load-extension=/path/to/dist（ビルド済みフォルダパス指定）、--no-first-run、--no-default-browser-check を含みます。Step 2 で curl http://localhost:9223/json/version で Chrome の起動確認。Step 3 では Playwright で chromium.connectOverCDP('http://localhost:9223') で接続し、chrome://extensions/ にアクセスして拡張機能ID を確認、chrome.developerPrivate API で拡張情報を取得します。Step 4 では chrome.storage.sync.set() で設定を書き込み、対象ページをリロードして拡張機能動作確認。コード変更後はビルド後に拡張機能だけリロードすれば Chrome 再起動は不要です。

複雑なタスクを自動実行するエージェントシステムを、ベストプラクティスに基づいて設計・改善できます。 単一の長いプロンプトでは解決困難なタスクを、計画・実行・評価の段階的なサイクルで管理可能なステップに分解できます。 プロンプト連鎖・ルーティング・パラレル処理・並列エージェント・マルチステップ検索など9つのワークフローパターンから、タスクに最適なパターンを選択して提案します。 既存の複雑なエージェントシステムを診断し、シンプル化・スケーラビリティ向上・デバッグ容易性を実現する改善案を提供します。 複数ステップを要するコード生成・データ分析・レポート作成タスクを自動化したい開発者 外部APIやツール連携（Slack、Notion、検索エンジン等）を組み合わせた自動化ワークフローを設計したいシステムエンジニア 複数のAIエージェントを並列運用し、処理時間短縮とスループット向上を実現したいデータサイエンティスト 既に構築したエージェントシステムが複雑化していて、保守性やデバッグ容易性を改善したいテックリード AI Agentは大規模言語モデル（LLM）を活用して自律的にタスク実行するシステムで、複雑なタスクを計画→実行→評価サイクルで達成します。特徴は自律性・ツール使用・状態管理・反復改善。価値は複雑タスク分解・スケーラビリティ・保守性・透明性。適用場面は複数ステップタスク・外部連携必要・反復改善必要・条件分岐・並列実行化。基本原則3つ：（1）シンプリシティ優先—常にシンプルから始め、実測改善時のみ複雑化追加。（2）透明性とデバッグ容易性—各ステップの入出力を記録し、動作追跡可能に。（3）モジュール性と再利用性—単一責任原則、共通機能抽出、疎結合維持。ワークフローパターンは優先順位順で9種類：プロンプト連鎖・ルーティング・パラレル処理・反復改善・並列エージェント・マルチステップ検索・HierarchicalReflection・Tool Choreography・自律型マルチエージェント。各パターンに概要・使用場面・例・利点・制約を記載。

変更内容を自動解析：git diffから何をどう変えたかを読み取り、わかりやすいコミットメッセージを日本語で自動生成します。 秘密情報の流出を自動防止：APIキーやトークンなど、流出してはいけない情報が差分に含まれていないか自動チェック。検出時はコミットを中断して警告します。 コミット分割を提案：異なる変更内容が混在している場合（テスト追加＋バグ修正など）、分割すべきコミットを提案して実行します。 アメンド提案：直前のコミットから5分以内で同じ種類の変更なら、新規コミットでなくコミットメッセージを上書きするamendを提案します。 毎回コミットメッセージの文面を考えるのが面倒な人 変更内容に見合った適切なコミットメッセージを書きたいが、ルール統一が難しい人 APIキーなどの秘密情報をうっかりコミットしてしまう心配がある人 チーム内でコミットメッセージの品質やフォーマットを統一したい人 手順は6ステップです。Step 1ではgit status、git diff（ステージ済み・未ステージ両方）、git log --oneline -10で状態確認。Step 2では秘密情報検出を必ず実行。検査対象はAPIキー・トークンパターン（sk-、ghp_、AKIA、32文字以上の英数字）、.env以外の秘密情報、conflict markerの残り、TODO/デバッグコードです。1つでも検出したらコミット中断。Step 3では異なるプレフィックスの変更（例：test:とfix:）が混在していれば分割提案。Step 4では条件をすべて満たす場合（直前コミットから5分以内、同じプレフィックス）にamend提案。Step 5では変更サマリを表示して確認。Step 6でユーザー承認後にコミット実行。 コミットメッセージは日本語で簡潔に、プレフィックス（feat:、fix:、docs:、refactor:、test:、chore:、ci:）は英語。形式は「: 」。変更が5ファイル以上または100行以上なら本文も追加。必ずユーザー確認後にコミット実行します。

ターミナルコマンドだけでUnity Editor を操作 — GUI操作なしにスクリプトコンパイル、テスト実行、シーン開閉、GameObject検索、ビルド実行が可能。複雑な手動操作を自動化できます。 C#コードを動的に実行して、Unity内の状態をリアルタイム検査 — unicli evalで任意のC#コードを評価し、ゲームの動作検証やデバッグが加速します。 EditMode・PlayModeテストを自動実行し、CI/CDパイプラインに統合 — テストランナーがターミナルから呼び出せるため、継続的インテグレーション環境での自動テストが実現できます。 複数のビルドオプション（Development、Profiler接続など）を組み合わせて実行 — Android・iOS・WebGL など異なるプラットフォームへのビルドを、引数指定だけで切り替えられます。 AIエージェントとの連携で、自動デバッグやプロトタイピングを高速化 — CLIベースのため、スクリプトやAIツールから直接Unityを制御でき、人間の手作業を最小化できます。 Unity開発でCI/CDパイプラインを構築したい開発者 — テスト自動実行やビルド自動化をターミナルから統制できるため、デプロイの信頼性と速度が向上します。 大規模プロジェクトで複数エンジニアが協働している場合 — スクリプト化されたコマンドで標準化でき、環境差異によるトラブルが減ります。 AIエージェント・自動化ツールと連携したい技術者 — CLIベースのため、スクリプトやMCP（Machine Control Protocol）経由での遠隔操作が容易です。 プロトタイピングやデバッグを高速化したい企画・技術者 — 手動でEditor画面を操作する時間が削減され、イテレーションサイクルが短縮されます。 UniCliはターミナルからUnity Editorを制御するCLIツール。基本コマンド構成：unicli check（接続確認）、unicli install（パッケージインストール）、unicli exec （Editor上でコマンド実行）、unicli eval ''（C#動的実行）、unicli commands（利用可能コマンド一覧）、unicli status（接続状態表示）。Assetsフォルダを持つディレクトリを自動検出し、プロジェクト内から実行。execコマンドはパラメータを--key value形式・JSON形式・booleanフラグ・配列で指定可能。共通オプション：--json（JSON出力）、--timeout（ミリ秒設定）、--no-focus（Editor非フォアグラウンド化）。よく使う例：Compile（--timeout 30000）、BuildPlayer（--target Android --options Development）、TestRunner.RunEditMode/RunPlayMode（--testNameFilter・--stackTraceLines指定）、Scene.Open・Save・GetActive、GameObject.Find・Create・SetTransform。

macOS で WiFi ネットワーク分析ツールを立ち上げられる。Python の CoreWLAN API と Node.js サーバーの依存関係を一括インストール、動作確認まで自動化されます。 CoreWLAN の認証情報エラーを事前に防げる。/usr/bin/python3 を使う必須条件、asdf・Homebrew・pyenv で入れた Python では失敗する理由が明確に分かります。 位置情報権限の設定が分かる。CoreWLAN スキャンに必要な macOS「プライバシーとセキュリティ」の権限付与方法、ターミナルアプリごとの設定手順が分かります。 トラブルシューティング手順がある。モジュール未検出エラー、位置情報認可失敗、ポート競合など、よくあるエラーの原因と解決方法が網羅されています。 macOS で WiFi 分析ツールを初めてセットアップするエンジニア。Python・Node.js の環境構築から動作確認まで、すべてのステップが明確に分かります。 CoreWLAN フレームワークを扱う開発者。標準 Python のみで動く理由、バージョン管理ツールの Python では失敗する理由など、深い理解が得られます。 macOS システムプログラミングに取り組む学習者。位置情報権限、CoreWLAN API の基本的な使い方の概要が掴めます。 開発環境の不具合を自力で解決したい開発者。各エラーメッセージと対応方法が系統立てて説明されており、デバッグが効率化されます。 macOS の CoreWLAN API を利用した WiFi ネットワーク分析ツールのセットアップガイド。前提条件は macOS 14.4 以降、Node.js v18+、/usr/bin/python3 の存在。セットアップ手順は 3 ステップ：(1) Python パッケージをインストール（/usr/bin/python3 -m pip install pyobjc-framework-CoreWLAN pyobjc-framework-CoreLocation、確認コマンドで OK 出力を確認）。CoreWLAN フレームワークは macOS 標準 Python からのみアクセス可、asdf・Homebrew・pyenv の Python では import CoreWLAN が失敗。(2) Node.js 依存パッケージを npm install。(3) npm start でサーバー起動、http://localhost:3000 で「スキャン開始」ボタン押下、WiFi ネットワーク一覧表示で成功判定。トラブルシューティングでは ModuleNotFoundError の場合は /usr/bin/python3 -c "import CoreWLAN; print('OK')" で確認、位置情報認可失敗時は macOS「システム設定 > プライバシーとセキュリティ > 位置情報サービス」でターミナルアプリを許可、ポート 3000 使用中時は server.js の PORT 変数を変更。

make_case.mdで定義したテストケースを自動で実行し、実際のdataLayerやGTMイベント、GA4イベントの実測値を取得します。 取得した実測値を自動で「想定値」として設定し、完全なcase.mdを自動生成できます。 GTMプレビューモードでサイトを操作し、複数のテストケースを連続実行できます。 手動操作が必要な部分はユーザーに指示して待機し、その後の自動実行を再開できます。 テスト完了後、ブラウザを自動で閉じるか、デバッグ用に開いたままにするか選択できます。 Google Tag Managerのテストケースを大量に用意していて、手動での実測値取得が手間な開発者 make_case.mdから完全なcase.mdを生成する作業を自動化したいQA・テスト担当者 GTMの動作検証をもっと効率的にしたいマーケティングテック担当者 dataLayerやイベント発火の仕様を正確にドキュメント化したいエンジニア make_case.mdから完全なcase.mdを自動生成するスキルです。テストフォルダ内のmake_case.mdを読み込み、YAMLフロントマター（site_name、gtm_account_id、gtm_container_id_numeric、gtm_container_id、workspace_name、gtm_workspace_id、start_url）をパースします。準備フェーズでは既存のChromeDevToolsプロセスを確認・終了し、GTMワークスペースURLを生成して開きます。ログイン状態が未確認の場合はユーザーに手動ログインを促します。GTMプレビュー起動後、各テストケースについて操作手順を実行し、window.dataLayerから最新10エントリを取得、GTMプレビューペインでイベント発火状態を確認します。手動操作指示がある場合はユーザーに表示し「続行」入力待機します。取得した実測値を想定値として設定し、最終的に完全なcase.mdを自動生成します。オプション引数として--output（生成ファイル名指定）と--no-cleanup（ブラウザを閉じない）が使用できます。

既存ログキーの重複チェック：プロジェクト内のBreakdownLoggerインスタンスを全検索し、新規キー作成前に既存キーでカバーしているか自動判定します。 命名規則に基づくキー選定支援：ドメイン別・テストレベル別・機能別の3方式から適切なネーミング方式を提案し、kebab-caseの統一性を確保します。 テストファイル限定の自動検証：実装コード（lib/）へのBreakdownLogger配置を検出し、CLAUDE.md規約違反をブロック。テストファイル（_test.ts）のみの使用を強制します。 ログの重要情報を先頭に配置：LOG_LENGTH末尾切り詰めに対応し、重要情報を先頭40字に配置するログ記述パターンを自動提案します。 キー発見から検証まで一括対応：grep検索→命名判定→配置確認→バリデーション→規約違反検出まで、ログキー管理の全工程を自動化します。 テストコード作成者：テスト時のログフィルタリングを効果的に行いたいが、キー重複を防ぎたいエンジニア。 BreakdownLogger導入プロジェクト開発者：ログキーの命名規則を統一化し、フィルタリング効率を高めたい人。 テストデバッグ効率化を目指す人：ログキーの重複や規約違反を事前に検出し、テスト実行時のノイズを減らしたい人。 チームのテストコード品質を向上させたい人：BreakdownLoggerの使用ルール（テストファイルのみ）を自動検証し、コード規約を遵守したい組織。 BreakdownLoggerの実装時ガイド。テストファイルのみ使用が必須（実装コード lib/は禁止）。ステップ1 KEY Discoveryでは既存キーをgrepで全検索し、既存キーが機能をカバーしているか判定：カバー→再利用、広すぎ→sub-key作成、なし→命名ルール準拠で新規、一時調査→fix-プレフィックス（事後削除）。ステップ2 KEY Namingは3方式から選択：By domain（ドメイン境界ごと）、By test level（テスト粒度ごと）、By feature（機能検証）。制約はlowercase kebab-case + -testサフィックス、汎用名禁止、名前空間プレフィックス必須。ステップ3 Placementはテストファイル先頭でインスタンス生成。ステップ4 Writing Styleは重要情報を先頭40字に、message=何が起きたか、data=証拠の形式。ステップ5 Validationで非テストファイルのBreakdownLogger importを検出し規約違反を通知。

現在のブランチのコードをビルドして、起動中のAndroidエミュレーターに自動的にインストールし、アプリを起動できます。 ビルドエラー、インストール失敗、ランタイムエラーをそれぞれ自動検出して、詳細な報告を提供します。 単体実行時とdebug-runスキルからの呼び出し時で、出力形式を自動切り替え（マークダウン形式 vs JSON形式）できるため、ワークフロー統合も柔軟に対応できます。 エミュレーターが起動していない場合、利用可能なエミュレーター一覧を表示して選択させ、自動起動することも可能です。 3秒のランタイムエラー監視で、アプリ起動時の FATAL EXCEPTION や AndroidRuntime エラーを即座に検出します。 Android開発時に「ビルド→インストール→起動」の一連の作業を毎回手動で行っているデベロッパー ビルドエラーやランタイムエラーの原因特定に時間がかかり、デバッグ効率を上げたい方 CI/CDパイプラインの一部として、自動でAndroidアプリをエミュレーターで検証したい方 複数のブランチを頻繁に切り替えながら、各ブランチの動作確認を効率よく行いたい方 プロジェクト固有情報：パッケージ名は org.starter.project、アプリモジュールは androidApp、Gradleタスクは :androidApp:installDebug、起動Activityは org.starter.project/.app.MainActivity です。 実行フロー：Step 0で実行モード判定（環境変数 CALLED_FROM_DEBUG_RUN の有無により JSON出力モード vs マークダウン出力モード を切り替え）、Step 1で adb devices で起動中デバイスを検出し、見つからない場合は emulator -list-avds で利用可能なエミュレーター一覧を取得後、AskUserQuestion でユーザーに選択させて起動、Step 2で ./gradlew :androidApp:installDebug を実行してビルド・インストールを行い、失敗時はエラーハンドリング実施、Step 3で adb shell am start でアプリを起動し、adb logcat で3秒間ランタイムエラーを監視します。成功時・ビルド失敗時それぞれのマークダウン出力形式（成功時は表形式のResults、失敗時は Build Error セクション付き）が定義されています。

ノード数乖離の原因を計測データから特定：rshogi と YaneuraOu（将棋エンジン）に debug ログを挿入してビルド・計測し、両者の探索ノード数の差分がどこで発生しているかを局所化できます。 コード比較では見つからない微細な差を発見：静的コード比較では特定できない、実際の動作時の微細な乖離を計測データから事実ベースで絞り込めます。 段階的な drill-down で原因を限定：root から開始して、1 ply（局面の深さ）ずつ掘り下げ、最初にズレる箇所を効率的に特定できます。 同一局面確認で仮説を検証：key（局面のハッシュ値）と SFEN を同時に出力し、両者が本当に同じ局面を評価しているか確認できます。 効率的なデバッグプロセスで長時間化を回避：最短ルート（depth 一致帯確定 → root 粒度で first mismatch 確定 → 段階的 drill-down）に従うことで、無駄なく原因にたどり着けます。 将棋 AI エンジン開発者：複数のエンジン実装間の微細な計算差を科学的に特定し、実装の正確性を向上させられます。 エンジンの最適化パフォーマンス向上に携わる人：乖離原因が分かれば、どの部分の改善が効果的かが明確になります。 静的コード比較だけでは解決できない問題に直面している人：実行時の計測データを使うことで、コード上では見えない動作時の差分を発見できます。 デバッグの時間効率を重視する人：フロー化された最短ルートに従うことで、原因特定にかかる時間を大幅に削減できます。 このスキルは rshogi と YaneuraOu（YO）の探索ノード数乖離を調査するもので、$ARGUMENTS で計測目標を受け取ります。入力例：startpos d28 root move breakdown、startpos d14 history at PLY3 path 4a3b/7g7f、startpos d14 A/B test mate_1ply。 対象ファイルパス：rshogi は crates/rshogi-core/src/search/（alpha_beta.rs、engine.rs、qsearch.rs など）と crates/rshogi-core/src/mate/；YO は /mnt/nvme1/development/YaneuraOu/source/（yaneuraou-search.cpp、movepick.cpp など）。 実行フロー（最短ルート）：（1）compare_nodes で depth ごとの差分を出し、d<=N 一致・d=N+1 初乖離を確定。（2）root 粒度で first mismatch 1 件確定（iter、mc、mv、nd、val の軽量ログのみ）。（3）同一文脈ゲート（root_move + pm1 + pm2 + ply + depth）で 1 ply ずつ drill-down、各段で最初にズレる child 1 件だけ追う。（4）val より nd を優先（fail-high/fail-low で val は揺れやすい）。（5）同一訪問確認を必須化（parent_key/child_key + SFEN を同時出力し、同一局面か確認）。

型チェック・リント・テストを一括実行: mypy（型検査）、ruff（コードスタイル・セキュリティ検査）、pytest（ユニットテスト）を順序立てて実行し、品質基準をクリアしたコードのみ完成とできます。 既存バグを実装前に修正してクリーンアップ: 実装開始前に mypy と ruff で既存コードをチェックし、混在するバグを先に解消することで、実装中のデバッグ時間を大幅削減できます。 Ruff違反を自動修正＋優先度分類: 自動修正可能なエラー（import順序など）を自動処理し、手動修正が必要なエラーをセキュリティ・複雑度・命名規則などの優先度で分類して効率的に対応できます。 コード修正後の自動テスト再実行: Ruff や型エラーの修正でコードが変更されたら自動的にテストを再実行し、既存機能が壊れていないことを確認できます。 Pythonバックエンド開発者: TDD（RED/GREEN/REFACTOR）のサイクルで、各フェーズ完了時に軽量な品質チェックを自動実行したい。 チームリード: コード品質を統一し、PR レビュー時の指摘を最小化したい。 新入エンジニア: Ruff違反や型エラーの修正方法を段階的に学べます。 CI/CD 担当者: ローカルでの品質チェックを標準化し、本番前の問題を事前防止できます。 品質チェックはステップ0（実装前）とステップ4（実装後）で実行されます。ステップ0では①mypy src/ で型エラー検出②ruff check src/ でスタイル・セキュリティ問題検出③エラー発見時は修正して再チェックする流れです。ステップ4では①pytest tests/ -v でテスト実行②ruff check で違反確認③ruff check --fix で自動修正④残りのエラーは手動修正（セキュリティ S・複雑度 C90・print文 T20・命名規則 N などの優先度順）⑤ruff format src/ でフォーマット適用⑥pytest tests/ -v で修正後のテスト再実行の全プロセスを実施します。完了条件は pytest で全テストパス、ruff check で「All checks passed!」、mypy で「Success: no issues found」の三点です。

GitHubのIssueを自動取得して一覧表示し、どのIssueから着手するかを選択できます。 選択したIssueの詳細情報（説明・コメント）を自動読み込みして、要件を正確に把握できます。 Issueの解決策を具体的に設計し、実装前にユーザーの承認を得てから着手できます。 作業中の変更が現在のブランチに影響しないよう、git worktreeで隔離された作業ディレクトリを自動生成できます。 実装完了後、自動的にコミット・プッシュ・PR作成・ブランチ削除までの流れを案内できます。 GitHubで複数のIssueを並行管理する開発者 作業中に誤ってメインブランチに影響を与えたくない人 Issue対応のフローを統一したい開発チーム 要件把握から実装・PR作成までの手順を体系的に進めたい人 手順：①gh issue listで指定リポジトリのIssue一覧を取得、②取得したIssueの中からユーザーが対応するIssueを選択、③gh issue view で詳細を読み込み要件を正確に把握、④解決策を具体的に設計・実装計画を立ててユーザーに提示して承認を得る、⑤Issue番号を含むブランチ名を決定（例：issue/123-fix-bug）、⑥git worktree add ./tmp/worktrees/ -b で隔離作業ディレクトリを作成、⑦worktreeディレクトリに移動してコーディング・テスト・デバッグを実施、⑧実装完了後add・commit・git push origin 、⑨gh pr createでPRを作成してIssueと紐付け、⑩git worktree remove ./tmp/worktrees/とgit branch -d でworktreeとローカルブランチを削除してクリーンアップ。

OWASP Mobile Top 10 の10個のリスク項目（不正なプラットフォーム使用・危険なデータ保存・通信暗号化不備・不正な認証など）に基づいて、iOSアプリのセキュリティを体系的にレビューできます。 Keychain・UserDefaults・Info.plist の設定を検査し、パスワード・トークン・APIキーなどの機密情報が適切に保護されているか診断します。 App Transport Security（ATS）の設定を確認し、強制HTTPS・証明書ピンニングが正しく実装されているか、または無効化されていないかをチェックします。 ハードコードされたシークレット・APIキー・パスワードを自動検索し、コード内に隠れている危険を洗い出します。 デバッグ用ログに機密情報が出力されていないか、print/NSLog の呼び出しを検査し、本番環境での情報漏洩リスクを低減します。 App Store リリース前にセキュリティレビューを実施したい iOS 開発者・技術リード OWASP Mobile Top 10 に準拠したセキュリティチェックリストが必要なセキュリティエンジニア Keychain・BiometricAuthenticationなどの実装が正しいか確認したいアプリ設計者 ユーザーの個人情報やAPIトークンを安全に保護するコードを書きたい開発チーム OWASP Mobile Top 10 チェック項目は M1（Info.plist ATS設定・権限の最小化）、M2（Keychain使用・UserDefaults に機密情報なし）、M3（HTTPS強制・証明書ピンニング）、M4（BiometricなしのKeychain保護・Token管理）を含みます。Swift セキュリティパターン検査項目は、パスワード・トークンがKeychainに保存（UserDefaults に機密情報なし、ハードコードシークレットなし）、Info.plistでATSが無効化されていない、URLSessionカスタム証明書検証の適切な実装、デバッグログに機密情報が出力されていないことです。コード検査パターンとして、ハードコード検索は grep -rn "password\|secret\|apiKey\|api_key" Sources/、print/NSLog 確認は grep -rn "print(\|NSLog(" Sources/ を実行し、マッチした行を検視します。

セッション終了時に自動的にパターン分析: 各Claude Code セッション終了時に Stop hook で起動し、セッション内で学んだ再利用可能なパターンを自動検出 エラー解決・デバッグ手法を学習: 特定のエラーがどう解決されたか、効果的なデバッグテクニック、フレームワーク・ライブラリの回避策を自動的に抽出 プロジェクト固有ルールを記録: ユーザーの修正から導かれたパターンやプロジェクト特有の規約を自動検出して保存 学習済みスキルとして再利用: 抽出したパターンを .claude/skills/learned/ に保存し、次のセッションで同じ問題に直面したときに活用 設定でカスタマイズ可能: min_session_length、extraction_threshold、ignore_patterns など設定ファイルで検出基準を調整 反復開発・継続改善を重視するチーム: 試行錯誤の過程で得られた知見をスキル化して、プロジェクト知識として蓄積したい 複数プロジェクト担当者: プロジェクト固有の開発ルール・パターンを自動記録し、チームナレッジとして共有したい デバッグが頻繁な開発: エラー解決パターンを学習させることで、同じエラーへの対応速度を向上させたい AI開発の学習曲線を加速: セッションごとに得られた工夫や回避策を自動的に蓄積し、長期的に開発効率を改善したい Stop hook として各セッション終了時に自動実行。セッション評価：メッセージ数が min_session_length（デフォルト10以上）か確認。パターン検出：error_resolution（エラー解決方法）、user_corrections（ユーザー修正から学んだパターン）、workarounds（フレームワーク問題への回避策）、debugging_techniques（効果的デバッグ手法）、project_specific（プロジェクト固有規約）の5つを検出。スキル抽出：有用パターンを .claude/skills/learned/ に保存。config.json で extraction_threshold（検出精度）、auto_approve（自動承認）、ignore_patterns（検出除外）をカスタマイズ。.claude/settings.json の hooks.Stop で evaluate-session.sh コマンドを設定。Stop hook は軽量（1回実行）・ノンブロッキング・完全なセッションコンテキストアクセス可能。セッション中の手動抽出は /learn コマンドで対応。

新機能やAPI変更、動作変更をコード実装時に自動でドキュメントに反映できます。 git diffを分析して変更種別を自動判定し、README、CLI仕様書、設定ドキュメント等の該当箇所を一括更新できます。 ユーザー向け変更を発見可能にするため、簡潔・例示優先・検索可能なドキュメント形式を自動適用できます。 内部実装詳細やデバッグ専用オプションなど、ユーザーに不要な情報を自動的に除外できます。 新機能実装時にドキュメント更新を忘れたくない開発者 複数のドキュメント箇所を一括で同期させたい技術リード ユーザー向けドキュメントの内容と実装の齟齬を防ぎたい品質管理者 API仕様やCLI仕様の変更を自動で反映させたいマイクロサービスチーム ユーザー向け変更を発見可能にするため、変更種別に応じたドキュメント箇所を更新する。決定マトリックス：新public API→README.md+mod.ts(JSDoc付export)、新機能→README.md+docs/usage.md、動作変更→README.md既存記述更新+CHANGELOG.md、CLI変更→docs/breakdown/interface/cli_commands.ja.md、パス解決変更→docs/breakdown/interface/path_resolution.ja.md、設定変更→docs/breakdown/interface/configuration.ja.md、ドメイン設計変更→docs/breakdown/domain_core/配下、内部変更→CLAUDE.md(開発ワークフロー影響時のみ)。手順：git diff --name-only→変更分類→該当ドキュメント更新→コード例動作確認。守則：簡潔・例示優先・検索可能。記載禁止事項：内部実装詳細、一時的ワークアラウンド、デバッグ専用オプション。