Skill.md検索

Conventional Commits形式に自動対応したPRタイトルを生成できるため、リリースノートに反映されやすいPRが作成できます PR本文テンプレートに沿った構造化された説明を自動生成することで、レビューに必要な情報を漏れなく記載できます 破壊的変更（!マーク）や関連URL、プロダクト側対応事項などを体系的に整理できるため、チーム全体の確認漏れを防げます gh CLIのHEREDOC形式に対応したコマンドを提供するため、手作業でのフォーマット確認が不要になります SmartHR UIリポジトリに定期的にコードを貢献する開発者 PR作成時にテンプレート形式を毎回確認するのが手間と感じている人 プロダクト側の対応が必要な変更を忘れずに記載したい人 Conventional Commitsのルールを正確に守りたい人 SmartHR UIリポジトリのPR作成ルールを定義します。PRタイトルはConventional Commits形式（(): ）で日本語記述し、破壊的変更は!で示します。PR本文は「関連URL」「概要」「変更内容」「プロダクト側で対応が必要な事項」「確認方法」の5セクションで構成し、該当なしの場合は「なし」と記載します。変更内容にはBefore/Afterコード例やキャプチャを添付し、破壊的変更の場合は具体的な対応方法を記載します。確認方法ではStorybookやChromatic URLを記載します。実行時はgh pr createコマンドのHEREDOC形式で本文を渡します。

新しくリリースされたFlutterバージョンのBreaking Changes・非推奨APIを自動調査し、プロジェクトへの影響を可視化できます。 コードベース内の非推奨API使用箇所を自動検索し、修正が必要なファイルと行数を特定できます。 mise・GitHub Actions・Shorebird・dependency_overridesなどプロジェクト固有の構成それぞれについて、アップグレード時の対応内容をチェックリスト化できます。 Dart SDK制約やパッケージ互換性を確認し、アップグレード実行時の予期しないエラーを未然に防げます。 リリースノート調査から対応タスク作成まで一貫して進め、アップグレード作業の見落としをなくせます。 モバイルアプリ開発チームの技術リード（Flutter定期更新の計画・実行） Flutterエンジニア（新バージョンリリース時の個別対応確認） DevOps・インフラ担当者（mise・CI/CD・Shorebird等の統合管理） プロジェクトマネージャー（アップグレード作業のスケジューリング・見積もり判断） Flutterアップグレードは3フェーズで進みます。フェーズ1（情報収集）: リリースノート（GitHub Issues、docs.flutter.dev、Breaking Changes、Blogから調査）とプロジェクト現状確認（flutter --version、.mise.toml、pubspec.yaml環境）。hotfixの場合はメジャーリリースの Breaking Changes も併せて調査。フェーズ2（影響分析）: Breaking Changes について Grep でコードベース内の使用箇所を検索。mise・GitHub Actions・Shorebird・dependency_overrides・パッケージ互換性（flutter pub outdated）・Dart SDK制約を個別確認。フェーズ3（対応タスクリスト作成）: 必須タスク（.mise.toml更新、mise install、各ワークフロー確認等）と修正対応（Breaking Changes修正、Shorebird doctor確認等）を整理。各フェーズで WebSearch/WebFetch でアップグレード最新情報を参照します。

バージョン番号とビルド番号を自動更新：現在のバージョンを確認し、リリース内容に応じてバージョンを bump（例：1.19.0 → 1.20.0）して pubspec.yaml に反映できます。 更新内容を CHANGELOG に自動反映：前回リリース以降のコミットを自動解析し、Added / Changed / Fixed に分類して CHANGELOG を更新できます。 iOS・Android・macOS の任意の組み合わせで同時リリース：プラットフォームを選択するだけで、複数の OS 向けアプリを同時にビルド・署名・配布できます。 GitHub Actions による自動ビルド・署名・配布：タグ push 後、CI/CD パイプラインが自動実行され、TestFlight・Google Play への配布と GitHub Release 作成までが完全自動化されます。 リリース前の自動検証：静的解析とユニットテストをローカルで実行し、問題がある場合はリリースを防止できます。 Flutter アプリの開発・運用チーム：バージョン管理と配布プロセスを統一・自動化したい組織 複数プラットフォーム対応アプリの担当者：iOS と Android を同時リリースする際の手作業を削減したい リリース頻度が高いプロジェクト：毎週・毎日リリースする際の人的ミスを防ぎたい CI/CD パイプラインを構築したい組織：手動ビルド・配布から自動化へ移行したい Flutter アプリのリリースワークフロー全体を自動化します。前提として main ブランチで作業中で未コミット変更がないことが必要です。主な流れは：(1)現在のバージョン確認と差分コミット収集（grep で pubspec.yaml から version を取得、git log で前回タグ以降の差分を確認）→ (2)バージョンとプラットフォームをユーザーに確認（feat/fix コミット有無により minor/patch を推奨、build number は +1）→ (3)CHANGELOG.md を Added/Changed/Fixed で分類更新 → (4)pubspec.yaml の version 更新 → (5)dart analyze と flutter test による検証（失敗時は進まない）→ (6)git add/commit/push と複数プラットフォーム向けタグ打ち（ios/vX.Y.Z+N、android/vX.Y.Z+N、macos/vX.Y.Z+N）→ (7)GH Actions 自動実行（ios-release.yml で TestFlight・GitHub Release、android-release.yml で Google Play）。バージョン形式は X.Y.Z+N（N はビルド番号）です。

コマンドラインから Bridge Server（@ccpocket/bridge）のバージョン bump・CHANGELOG 更新・タグ push を一元管理でき、その後 GitHub Actions が自動で npm publish と GitHub Release を作成します。 前回のリリースタグからの差分コミットを自動解析し、semantic versioning（major / minor / patch）の推奨版を提示してくれるため、バージョン決定の判断が簡単になります。 CHANGELOG を自動で構造化（Added / Changed / Fixed セクション）し、リリースノートの品質を保ちながら手作業を最小化できます。 ローカルで テスト・型チェック・ビルド を実行して検証してから push するため、リリース後の問題を事前に防げます。 Flutter アプリ側の expectedBridgeVersion を同時に更新できるため、Bridge と アプリのバージョンズレによるバナー表示ミスを防げます。 Bridge Server の保守・リリース担当者またはメンテナー バージョン管理・CHANGELOG 更新・リリース自動化を統一したいプロジェクトチーム npm パッケージの semantic versioning を厳密に運用したい組織 GitHub Actions を使った CI/CD パイプラインを構築・運用する開発者 前提: main ブランチで作業中、未コミット変更がないこと。 手順: 1. バージョン確認・差分収集: package.json の現在バージョンを確認し、前回タグからの差分コミット一覧を取得（git log + 条件指定）。 2. バージョン決定: 差分コミットを分析（feat = minor 推奨、fix のみ = patch、破壊的変更 = major）し、AskUserQuestion でユーザーに具体的なバージョン番号を提示・確認。 3. CHANGELOG 更新: packages/bridge/CHANGELOG.md の先頭に新セクション（Added / Changed / Fixed）を追加。 4. バージョン bump: packages/bridge/package.json を更新。 4.5. Flutter 同期: apps/mobile/lib/constants/app_constants.dart の expectedBridgeVersion を同じバージョンに更新（アプリの古いバージョン検出ロジック対応）。 5. ローカル検証: npm run test:bridge / npx tsc --noEmit / npm run bridge:build をすべて実行し pass を確認（失敗時はユーザーに報告・修正待ち）。 6. コミット・タグ: git add → git commit → git push origin main → git tag bridge/vX.Y.Z → git push origin bridge/vX.Y.Z。 7. 完了確認: GitHub Actions (bridge-release.yml) の自動実行を確認。テスト・ビルド・npm publish・GitHub Release 作成が完了したら終了。

Issue番号またはPR番号を指定するだけで、対応に必要な情報をまとめたレポートが自動生成されます。 バグ報告、機能要望、プロンプト要望など、Issue の種別を自動判定し、対応すべき内容を明確にします。 コードベースを調査して、その要望を実現するために変更が必要なファイルや影響範囲を自動で洗い出します。 実装の難易度を Low / Medium / High / Very High で判定し、工数目安を提示するため、優先度判断がしやすくなります。 既存機能との重複がないか、プロトコル変更が必要か、セキュリティ上の懸念はないかなど、多角的に対応判断を支援します。 GitHub上の Issue / PR が大量に溜まっており、どれから対応すべきかを判断したい プロジェクトマネージャーやチームリード バグ報告や機能要望の優先度を決める際に、実装難易度を知りたい開発者 新しい外部PRの内容をサッと把握して、マージ判定する必要がある レビュアー 実装前に関連コードや影響範囲を把握したい エンジニア GitHub Issue / PR 番号を入力するとトリアージレポートが自動生成されます。手順は4フェーズで実行されます。Phase 1ではghコマンドで Issue またはPRの詳細情報、コメント、レビューを取得し、テンプレートやラベルから種別（Bug / Feature / Prompt Request / Dependabot / 外部PR）を判定します。プラットフォームサポート状況も評価し、実機検証が必要な環境（Windows Bridge Server、macOS Flutter等）は experimental / best-effort として区別します。Phase 2では関連コード、既存機能との重複、影響範囲、プロトコル変更の必要性をExploreサブエージェントで並列調査します。PRの場合は変更ファイル一覧、diff、規約準拠、テスト追加の有無、セキュリティ懸念をチェックします。Phase 3では調査結果をもとに難易度を判定（工数目安：Low ~1時間、Medium 数時間、High 1日以上、Very High 数日以上）し、具体的なファイルパスと変更箇所を根拠として示します。Phase 4でレポートをマークダウン形式で出力します。

Bridge Server（TypeScript）のユニットテスト実行、TypeScript型チェック、カバレッジ測定を順番に実行し、全てのテストがパスすることを自動確認できます。 テストファイルのみを指定したり、ウォッチモード（開発中は自動再実行）で効率的にテストを回すことができます。テストファイルと型チェック対象の関係を正確に管理します。 vitest規約に基づいたテスト記述方法（ファイル配置・命名・import・テスト構造）の標準を適用し、チーム全体で一貫性のあるテストコードを保証します。 parser.ts、claude-process.ts、image-store.tsなど、現在テスト対象のモジュールを管理し、新しく純粋関数が追加される際のテスト追加ガイダンスを提供します。 外部依存（プロセスspawn・ファイルシステム・WebSocket）を除いた、ROIの高い純粋ロジックのテストに集中できます。 Bridge Server開発でコード品質を保ちながら継続的にテストを実行したい開発チーム TypeScriptの型チェックとテスト自動化で本番バグを事前に防ぎたい品質管理者 テスト記述規約を統一して、チーム内の開発効率と保守性を向上させたい技術リード 新機能追加時に既存機能の回帰テストを確保したいCI/CD環境構築者 Bridge Server（TypeScript）のテスト実行・型チェック・テスト記述ガイド。実行手順①ユニットテスト（npm run test:bridge、特定ファイル指定可、ウォッチモード対応）②TypeScript型チェック（npx tsc --noEmit、テストファイルと vitest.config.ts は tsconfig.json の exclude に含まれ型チェック対象外）③カバレッジ測定（任意）。テスト記述規約：ファイルはソースと同ディレクトリに .test.ts 配置、vitest のみ import（jest互換は不可）、テスト対象モジュールは .js 拡張子で import（NodeNext moduleResolution）、describe でグルーピング・it は英語三人称現在形・1つの it は1振る舞い検証。テスト対象は純粋関数・ロジック中心（高ROI）。現在テスト対象モジュール：parseClaudeEvent、claudeEventToServerMessage、parseClientMessage（parser.ts）、parseRule、matchesSessionRule、buildSessionRule、toolNeedsApproval（claude-process.ts）、ImageStore.extractImagePaths（image-store.ts）。新テスト追加時は純粋関数があれば追加検討、internal関数テストは export に変更OK。

設計書・ヒアリングシート・アーキテクチャ説明を多角的にレビュー：AWS Well-Architected フレームワークの6つの視点（信頼性、セキュリティ、コスト最適化、運用上の優秀性、パフォーマンス効率、持続可能性）から包括的に分析し、改善案をレポート化します。 AWSベストプラクティスとの整合性を自動検証：最新のAWSドキュメントやサービス仕様と照合し、推測ではなく公式情報に基づいた指摘を提供します。 平易な説明とエンジニア向け詳細の両立：技術レベルに依存しない図解と、実装根拠となる詳細なドキュメントリンクを同時に提示します。 リージョン可用性やサービス最新機能を自動確認：新機能やリージョン対応状況を都度確認し、古い情報に基づく指摘を排除します。 非機能要件IPA分類とW-Aの柱の対応を自動マッピング：設計の品質要件を構造化し、どの柱でカバーされているか明確にします。 クラウドアーキテクト・ソリューションアーキテクト：新規プロジェクトの設計レビュー、既存システム改善の根拠提示に 開発チームリード・PMO：AWSベストプラクティス準拠をスケーラブルに検証したい セキュリティ・コンプライアンス担当：セキュリティ要件、コスト削減余地、リスク評価を構造化したい クラウド移行プロジェクト推進者：移行後の設計が大規模採用に耐えられるか定量的に判定したい AWS Well-Architected フレームワークの6本の柱に基づいてレビューを実施。対象は本リポジトリの設計テンプレート（design/doc_source/）、ヒアリングシート（survey/doc_source/）、ワークショップ資料（workshop/doc_source/）。ワークフローは①入力理解（ファイルパスまたはトピック名から対象を特定）、②ドキュメント読み込み（Glob・Read・Grep ツール活用）、③AWS最新ベストプラクティス確認（aws-knowledge MCPで Well-Architected・サービス固有・最新アップデート・リージョン可用性を検索）、④6本の柱による分析（非機能要件カテゴリ定義を参照して対応関係を確認）。出力は日本語で統一、AWS サービス名は英語表記のまま。AWS ドキュメントリンクは英語版URLを使用。

非機能要件ヒアリングシート（8ファイル）に記載されたAWSサービスの仕様が最新版と一致しているか自動チェックできます。 SLA・クォータなどの数値、サービス機能、ベストプラクティスが現在の公式情報と乖離していないかを検証できます。 旧サービス名のままで記載されている、サービス提供が終了している、新機能が言及されていないなどの課題を特定できます。 チェック範囲を全体・特定ファイル・カテゴリごとに指定でき、効率的に更新対象を絞り込めます。 AWS最新情報との照合結果をレポートにまとめ、ドキュメント更新の優先度判断ができます。 AWSソリューションアーキテクトやクラウド設計者 定期的にAWSドキュメント・ベストプラクティスを最新に保ちたい企業 長期運用しているAWSプロジェクトの非機能要件定義を刷新したい PM・要件定義者 信頼性・セキュリティ・コスト最適化など特定カテゴリの陳腐化を重点的にチェックしたいアーキテクト 非機能要件ヒアリングシート（reliability・security・cost-optimization等8ファイル）に記載されたAWSサービス情報を最新の公式仕様と照合します。検索範囲は $ARGUMENTS で指定可能（引数なし=全体、ファイル名指定、カテゴリ指定）。 ワークフローは4段階です。Step 1: nfr-taxonomy.mdとチェック対象ファイルを読み込み、Step 2: 各ファイルからAWSサービス名・SLA数値・機能記述・ベストプラクティスを抽出、Step 3: aws-knowledge MCPサーバーで照合（SLA正確性、サービス機能最新性、リブランド有無、新サービス欠落、非推奨サービス記載の5観点）、Step 4: 照合結果を日本語レポートで出力。AWS最新情報との不一致が確認できた場合のみ指摘し、確認できない情報は記載しません。

PR レビューのコメントやセッション中の発見を自動分析し、プロジェクト設定ファイル（CLAUDE.md・スキル・エージェント設定）に学習結果を即座に反映できます。 CodeRabbit や人間レビュアーからの指摘をルール化し、同じ品質問題の再発を未然に防げます。 セッション終了時に会話全体から学習ポイントを自動抽出し、次回からの作業効率が向上します。 複数 PR の共通パターンを検出でき、プロジェクト全体の設計方針をアップデートできます。 繰り返す品質指摘に疲れているレビュアー チーム開発でルール定義が曖昧なプロジェクト セッション終了後の成果物を自動的に記録・更新したいエンジニア データ駆動でプロジェクト方針を改善したい技術リーダー Retro は PR レビューのフィードバックやセッション中に得た知見を分析し、CLAUDE.md・skills・agents・memory に学びを自動反映する振り返りスキルです。実行パターンは3つ：PR番号指定で該当PR分析、recentで直近マージ済みPR分析、sessionで今セッションの発見を処理。各コメントから「事象（何が問題か）」「原因（なぜか）」「対処（解決策）」「ルール化候補」を抽出します。CodeRabbit フィルタリング（⚠️ Critical/Major → 分析、🟡 Minor → 判断、nitpick → スキップ）を適用。学びは判定ツリーで分類：普遍ルール → CLAUDE.md、ワークフロー改善 → skill/command、エージェント指針 → agents、運用知識 → MEMORY.md。分類後、対象ファイルを直接更新します。

プロダクトアイデアから、実装に耐える詳細なPRD（プロダクト要求定義書）を対話的に作成できます。 ターゲットユーザー、課題、機能要件、非機能要件、成功指標をテンプレートに沿って体系的に整理します。 曖昧な要件を具体的・測定可能な形に落とし込み、「これは実装可能か」をAIが検証します。 機能を優先度（P0必須/P1重要/P2検討）で分類し、MVP範囲を明確にします。 既存PRDがある場合は構造を維持しながら更新、新規作成時はテンプレートガイドを参照できます。 起業家・プロダクトマネージャーで、アイデアを実装可能な形に落とし込みたい方 デザイナーや開発チームのリーダーで、要件の曖昧さを事前に潰したい方 投資家向けプレゼン資料としても使える、説得力のあるドキュメントを作成したい方 プロダクト開発の初期段階で、「作る前に仕様を決め切る」プロセスを回したい方 PRD作成の前提条件として、docs/ideas/initial-requirements.md に初期要求（アイデア、課題、ターゲット、主要機能、MVP範囲）を保存する必要があります。既存の docs/product-requirements.md がある場合は最優先し、このスキルのテンプレートは参考資料として使用します。作成プロセスは①initial-requirements.md 確認、②テンプレートに従ってドラフト生成、③5つの観点（ビジョン明確性、ユーザー具体性、成功指標測定可能性、機能詳細化レベル、非機能要件網羅性）でレビュー、④指摘を改善・再レビュー、です。重要な方針として「具体性と測定可能性」「ユーザー中心設計」「優先順位の明確化（P0/P1/P2）」を掲げ、ユーザーストーリーフォーマットと優先度分類が含まれます。

ユーザーからの新機能や変更指示を受け取ると、それに基づいた作業計画書（requirements.md、design.md、tasklist.md）を自動生成できます。 tasklist.md に記載されたタスクを 1 つずつ進捗管理し、完了時にリアルタイムで checklist を更新できます。 プロジェクトの永続ドキュメント（product-requirements.md、functional-design.md、architecture.md など）と整合させながら、一貫性のある設計・実装を進められます。 実装完了後に振り返りドキュメントを自動生成し、次のタスクへの知見を記録できます。 作業指示を受けるたびに「何をやるのか」「どの順序でやるのか」を明確に整理したい PM・チームリード 複数の並行タスクがあり、進捗を可視化・一元管理したい開発チーム 実装完了時に「何をやったか」「なぜそう決めたか」を記録し、チームの知識を蓄積したい人 プロジェクトの永続的な設計方針と日々のタスク実行を同じドキュメント体系で管理したい人 Steering スキルは、.steering/[YYYYMMDD]-[機能名]/ の形式でディレクトリを作成し、requirements.md、design.md、tasklist.md の 3 つのテンプレートに基づいたファイルを生成します。実装時には tasklist.md を常に開いた状態で進め、タスク開始時に [ ] → [x] に更新し、完了時に EditToolで記録することが必須です。重要な原則として、tasklist.md の全タスクが完了するまで作業を継続し、「時間の都合」「別タスク予定」などの理由によるスキップは禁止です。タスクが大きすぎる場合はサブタスクに分割し、スキップが許可されるのは実装方針変更・アーキテクチャ変更・依存関係変更・設計変更など技術的理由に限定されます。スキップ時には tasklist.md に理由を明記し、最後に振り返りドキュメントを作成して実装完了とします。

クライアント-サーバー間の通信プロトコルを「Request-Response型」または「Event型」から選択して実装できます。 IPacketResponseクラスを継承し、MessagePackでシリアライズされたデータを処理するプロトコルを作成できます。 PacketResponseCreatorに新規プロトコルを登録し、サーバーで即座に利用可能な状態にできます。 ビジネスロジックとシリアライズ処理を分離した保守性の高いプロトコル実装ができます。 moorestechサーバーに新しい機能を追加するサーバー開発者 クライアント-サーバー通信仕様（プロトコル）を実装・設計する開発チーム ゲームサーバーのリクエスト/レスポンス処理やイベント通知を実装する必要がある担当者 MessagePackを使用した通信システムを構築・保守しているエンジニア moorestechサーバーのプロトコル実装ガイドです。プロトコルは「クライアント明示的要求型」のRequest-Response型と「サーバー状態変化通知型」のEvent型の2種類があり、詳細パターンはreferences/protocol-patterns.mdを参照します。Request-Response型はmoorestech_server/Assets/Scripts/Server.Protocol/PacketResponse/に新規ファイルを作成し、IPacketResponseを継承したクラスを実装します。プロトコルクラスはServiceProviderから依存関係を注入され、GetResponse()メソッドで受信ペイロードをMessagePackデシリアライズして処理し、ProtocolMessagePackBaseを継承したレスポンスを返します。MessagePackObject属性を使用したデータクラスではKey(0)=Tag、Key(1)=SequenceIdが基底クラスで予約済みです。実装後はPacketResponseCreatorに登録します。

VanillaSchema 配下の YAML スキーマを安全に編集できる。ブロック・アイテム・液体など、マスターデータのスキーマ構造を体系的に変更・追加でき、SourceGenerator の自動コード生成の仕組みが分かります。 スキーマ追加・削除時の設定変更が自動化される。csc.rsp への追加・削除、_CompileRequester.cs の更新手順が明確で、ビルド失敗のリスクが減ります。 再利用可能なスキーマ部品（ref）を活用できる。inventoryConnects.yml など共通パターンをスキーマ部品として定義し、定義の重複を削減できます。 switch・cases、foreignKey などの高度なスキーマ機能を使いこなせる。条件分岐、他スキーマへの参照、共有インターフェース定義など、複雑なマスターデータ構造を表現できます。 Moorestech プロジェクトでマスターデータを管理するエンジニア。YAML スキーマから自動生成される C# クラスの関係を理解でき、スキーマ変更時の対応ミスが減ります。 新しいブロックタイプ・パラメータを追加する開発者。スキーマ定義から SourceGenerator 発動、コード生成までのフロー全体が把握でき、追加作業の手戻りが減ります。 CI/CD パイプラインの失敗を減らしたい DevOps エンジニア。JSON データとスキーマのプロパティ名をすべてチェック、grep コマンドで更新漏れを検出する方法が明確です。 マスターデータ管理を一から構築する技術リーダー。ref・defineInterface・switch/cases などのパターンが実例で示されており、保守性の高いスキーマ設計が可能になります。 マスターデータの YAML スキーマ編集ガイド。ディレクトリ構造は VanillaSchema 直下にブロック・アイテム・液体など主スキーマ、ref 配下に inventoryConnects.yml など再利用可能な部品。編集手順は 4 ステップ：(1) VanillaSchema 配下の YAML を編集、(2) スキーマ追加・削除時に moorestech_server/Assets/Scripts/Core.Master/csc.rsp を編集（/additionalfile:Assets/../../VanillaSchema/newSchema.yml 追加または削除行削除）、(3) _CompileRequester.cs の dummyText 定数を変更してトリガー、(4) MCP または Unity でリビルド（生成コードは Mooresmaster.Model.*Module 名前空間）。重要パターンとして ref は ref: inventoryConnects で VanillaSchema/ref/inventoryConnects.yml を参照、switch/cases で blockType によって条件分岐したプロパティ定義、defineInterface で IChestParam など共有プロパティを定義・実装、foreignKey で items スキーマ参照など。重要ルールは optional: true は必要時のみ、手動で Mooresmaster.Model クラス作成禁止、変更後は _CompileRequester.cs を更新してコミット。プロパティのリネーム・削除時は CRITICAL：JSON データ更新（TestMod、Client.Tests、../moorestech_master、mooresmaster.SandBox 全対象）、grep で旧プロパティ名の残存確認必須（.claude/worktrees を除外）。スキーマ変更後も CRITICAL 検証あり。

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

実行計画テーブルから未完了タスクを自動抽出し、次々と着手します。TreeWalk実装→VM同期→回帰検出のサイクルを自動繰り返すため、人間の指示なしに開発が進みます。 タスク完了時に自動で計画を「完了」に更新し、changelog.mdに記録するため、進捗管理の手作業がなくなります。 パフォーマンス改善タスク（P3、G2）は自動的にベンチマークを記録し、改善効果を数値で確認できます。 ビルドエラーやテスト失敗を検出した場合、原因調査→修正を試みてから次タスクに移るため、問題が連鎖しません。 CLAUDE.md、plan/memo.md、plan/roadmap.mdなどのプロジェクトドキュメントを毎回参照するため、規約や設計を外さない実装が実現します。 長時間の反復開発を効率化したい開発チーム テスト合格・ベンチマーク記録まで自動で行いたい開発者 計画書とコードの同期ズレを防ぎたいプロジェクトマネージャー 朝出勤時に計画を立てたら昼には完了タスクが溜まっていてほしい人 このスキルは毎イテレーション時にgit logとgit statusで現状を把握した後、plan/memo.mdの実行計画テーブルから未完了の最初のタスクを選定します。開発手順は「TreeWalkで正しい振る舞いを実装」→「VMを同期（同じ結果を返すように）」→「--compareで回帰検出（zig build run -- --compare -e '(test-expr)'）」→「テスト追加・実行（zig build testで baseline=1036 pass）」です。タスク完了時は計画表の該当行を「完了」に更新し、changelog.mdも追記します。パフォーマンス系（P3、G2）タスクでは必ずベンチマークを記録（bash bench/run_bench.sh --quick --record --version="..."）します。意味のある単位でgit commitしたら、設計判断が必要な場合はplan/notes.md`に選択肢を記録し最適な方を選んで進みます。ビルドエラー・テスト失敗は原因調査・修正を試みた後、止めずに次タスクへ移行します。

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 セレクタで実装。

ゴール文書を入力すると、Ralph Loopパターンで設計→実装→検証を自動で回します 設計フェーズでは既存コードやRN版リファレンスを読み込み、実装方針を自動決定します 実装フェーズでは自動コード生成と既存Flameパターンへの準拠を同時に実行します 検証フェーズで flutter analyze と flutter test を自動実行し、エラーを検出して修正します 進捗状況がファイルベースで記録されるため、中断→再開が可能で、反復的な開発が効率化できます G-Runner Flutter版の新機能を、リファレンス（RN版）を参考にして自動実装したい開発者 設計→実装→検証のループを何度も回す反復開発を自動化したい開発チーム IMPLEMENTATION_PLAN.mdの進捗更新を自動化して、プロジェクト管理を効率化したいプロダクトマネージャー Flameゲームエンジンの標準パターン（PositionComponent、anchor、論理座標系）に沿ったコード生成をしたい技術リーダー ゴール文書をインプットに、Ralph Loopパターンで設計→実装→検証の開発ループを自律実行するスキルです。引数は第1引数がゴール文書パス（必須）、--max-iterationsが最大イテレーション数（デフォルト10）。プロンプトテンプレートは、G-Runner Flutter版開発エージェント向けに、CLAUDE.md・IMPLEMENTATION_PLAN.md・RN版リファレンスを読み込ませ、Phase 0（Design）→Phase 1（Implementation）→Phase 2（Verify）→Phase 3（Update Plan）を順次実行します。Phase 0はRN版ファイル読み込み、ゴール分析、実装方針決定。Phase 1は constants.dart・stage_data.dart への追加、新規Flameコンポーネント実装、ゲームエンジン統合、HUD/画面更新。Phase 2は flutter analyze と flutter test 実行。Phase 3は IMPLEMENTATION_PLAN.md 更新。完了条件は全Phase完了、コード実装済み、解析エラーなし、テスト通過、計画更新済みです。

バージョン自動計算とリリース分岐を一括生成：引数（patch/minor/major）またはバージョン直指定から、セマンティックバージョニング規則に従った次バージョンを計算し、git worktree + release ブランチを自動作成します。 commandmatedev エージェント委譲でリリース準備を自動化：package.json 更新、CHANGELOG 作成、ビルド・テスト・lintの品質チェック完全自動化をエージェント経由で実施、失敗時は中断報告。 3フェーズ制御でリリース完了まで一気実行：①worktree作成と登録確認、②エージェント委譲でリリース準備、③マージ・タグ・push を制御フロー通りに順序保証。 疎通確認と段階的ロールバック対応：commandmatedev サーバー状態確認、main ブランチ最新化、worktree 登録失敗時のユーザーガイダンスを自動判定。 リリースマネージャー・リードエンジニア：手動リリースの繰り返し作業を廃止し、リリース品質を標準化したい マイクロサービス・モノレポ運用チーム：複数パッケージの並行リリースを一元管理したい CI/CD パイプライン構築者：git worktree + エージェント委譲の組み合わせパターンを参考にしたい DevOps エンジニア：リリースプロセスのボトルネック自動化が必要な組織 3フェーズ実行フロー：Phase1（worktree準備）では commandmatedev 疎通確認→現在バージョン取得→次バージョン計算（セマンティックバージョニング準拠）→main ブランチ最新化→release ブランチと worktree 作成→npm install→worktree 登録確認。Phase2（エージェント委譲）では WT ID 取得→リリースタスク（package.json version更新、package-lock.json更新、CHANGELOG追加、品質チェック：lint・tsc・test・build）を commandmatedev send で送信→エージェント完了待機。Phase3（完了処理）では main マージ・タグ作成・push・worktree 削除。前提：main 最新、commandmatedev 起動、lint/tsc/test/build 全パス状態。

症状から出発して、ログ・スタックトレース・デバッグツールを活用しながら根本原因を特定できます 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）して体系的に調査を開始できます。

iOS・macOS・watchOSなどAppleプラットフォーム向けのUIを、Apple Human Interface Guidelines(HIG)に自動準拠させて設計できます マージン・スペーシング・グリッド・タイポグラフィ・カラーなど、プラットフォーム別の厳密な仕様に基づいて設計できます Dynamic Type対応やダークモード対応など、ユーザーアクセシビリティに配慮した設計が実装できます Navigation Bar・Tab Bar・Buttons・Lists・Cardsなど、標準コンポーネントの正確な仕様（寸法・色・配置）がすぐに参照できます SF Symbols を活用したアイコン設計を、統一的なガイドラインで実行できます iOS・iPadOS・macOS向けアプリのUIデザインを行うUI/UXデザイナー Appleプラットフォーム開発初心者で、デザインシステムの標準的な仕様を学びたい開発者 複数Appleプラットフォーム（iPhone・iPad・Mac・Watch・TV）で一貫性あるUIを構築したいプロダクトチーム ユーザーのアクセシビリティニーズに配慮したアプリ設計を実装したいプロダクトマネージャー Apple Human Interface Guidelines(HIG)に準拠した洗練なUIデザイン作成スキルです。核心原則は明瞭性（すべてのサイズで読みやすく、装飾は適切）、敬意（UIはコンテンツを補助）、奥行き（レイヤーと動きで階層表現）です。iOS/iPadOS：セーフエリア8pt基本グリッド、マージン最小16pt、Dynamic Type対応フォント（San Francisco）、14段階のテキストスタイル、セマンティックカラー+ダークモード対応が必須。Navigation Bar高さ44pt（コンパクト）/96pt（ラージ）、Tab Bar高さ49pt、ボタン最小タップ領域44x44pt、リスト行最小44pt、カード角丸12pt/16ptが標準。macOS：ウィンドウ最小800x600pt、ツールバー高さ52pt/76pt、サイドバー幅150-250pt、ボタン高さ22-32pt。watchOS：マージンプラットフォーム別に設定。各プラットフォーム仕様が詳細に定義されています。