Skill.md検索

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でレポートをマークダウン形式で出力します。

リリース前の検証（CI状態確認）から、Release workflowの実行、完了待機、新規releaseの検出まで一連のリリース運用を再現可能な手順で実行。 リリースノートから関連Issue・PRを自動抽出し、Issue返信文とSNS投稿案（Bluesky）を自動生成。手作業での返信文作成が不要。 --dry-runオプションで事前検証。本実行前に動作確認してからリリースを進められるので安全。 Codex LLMと同梱スクリプトの役割分離。確定的な検証・実行はスクリプト、非確定的な文章生成はLLMが担当する堅牢な設計。 obsidian-another-quick-switcherのメンテナー。毎回のリリース作業を効率化・標準化したい。 オープンソースプロジェクトの管理者。リリースフローの属人性を減らし、再現可能な手順を確立したい。 チーム開発で複数人がリリース対応する環境。誰でも同じ品質でリリース運用できる仕組みが欲しい。 GitHub Actionsと連携したリリース自動化を実装している人。リリースノート生成やIssue通知まで含めた完全自動化を目指す。 実行前提：bun、gh、gh auth statusが利用可能。Codex CLI実行時はghコマンドを最初からエスカレート実行（sandbox・host間の認証コンテキスト差異対応）。基本フロー：リポジトリルートでbun .agents/skills/another-quick-switcher-release/scripts/release.ts実行→スクリプト出力のJSON（RELEASE_RESULT_JSON）を読み取り→assets/templatesのテンプレート使用して標準出力（Bluesky投稿案・Issue返信テンプレート）。Script Options：--branch （対象ブランチ指定、既定master）、--dry-run（dispatch/git pull非実行）、--skip-issue-notify（Issue候補表示スキップ）。Output Contract：スクリプトはJSON出力でrelease・issueCandidatesフィールドを含む。Issue返信はPR除外（isPullRequest=false対象）、author重複除去、tagName・URL置換。Bluesky投稿は利用者視点の日本語要約・URL直記載で標準出力。失敗時は references/release-workflow.md のtroubleshooting参照。

設計書・ヒアリングシート・アーキテクチャ説明を多角的にレビュー：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最新情報との不一致が確認できた場合のみ指摘し、確認できない情報は記載しません。

新機能実装時に NotificationService を呼び出すだけで、ベルアイコン・ドロップダウン・トースト通知が自動表示されます セキュリティ・システム・アクション・情報・警告など、事前定義された6種類の通知タイプから選ぶだけで実装できます 特定ユーザーへの個別通知と、管理者などの特定ロール全体へのブロードキャスト通知（ブロードキャスト通知）が両方対応できます 通知はPostgreSQLに自動永続化され、未読数・既読・削除などの管理が APIエンドポイント経由で自動処理されます 日本語・英語対応で、多言語対応アプリでもそのまま使用できます 新機能実装時に通知周りの複雑な実装を避けたい開発者 ユーザーへのイベント通知を統一的に管理したいプロダクトマネージャー セキュリティアラート・アクション要求など、重要な通知を確実に配信したいシステム担当者 通知センターのUIを共通化して、アプリケーション全体の一貫性を保ちたいデザイナー NotificationServiceは、アプリケーション内での重要なイベントをユーザに通知する統一システムです。通知センター（ヘッダーのベルアイコン）、トースト通知（Sonnerでリアルタイム表示）、DB永続化（PostgreSQL×Prisma）で構成されています。6つの通知タイプ（SYSTEM・SECURITY・ACTION・INFO・WARNING・ERROR）と4段階の優先度（URGENT・HIGH・NORMAL・LOW）があります。ファイル構成は lib/services/notification-service.ts（通知発行）、lib/stores/notification-store.ts（Zustandストア）、lib/i18n/notifications.ts（翻訳）、app/api/notifications/route.ts・[id]/route.ts・read-all/route.ts・unread-count/route.ts（APIエンドポイント）、components/notifications/NotificationBell.tsx他（UIコンポーネント）です。API呼び出しは NotificationService.securityNotify()・systemNotify()・actionNotify()（個別通知）、NotificationService.broadcast()（ロール別ブロードキャスト）で実装します。

PRD（企画書）と機能設計をもとに、システムの技術構成を決定し、図面として記録できます。 採用するプログラミング言語、データベース、API通信方式などの技術選定を、一覧表・図解・テキストで明確に文書化できます。 既存の設計書がある場合は優先し、ない場合は提供テンプレートを使って新規作成できます。 後続の実装チームが「どんな技術を使うのか」「どの部品がどう連携するのか」を一目で理解できる設計書を作成できます。 作成した設計書は docs/architecture.md に自動保存され、プロジェクト全体で参照可能になります。 システム構築の前に「技術全体像」を整理したいプロジェクトマネージャー・PO 開発チーム全体の共通理解を作りたいテックリード・アーキテクト 既存プロジェクトの技術選定を見直す必要がある開発責任者 複数チームで並行開発するときに技術的な一貫性を保ちたい組織 このスキルは、PRD（docs/product-requirements.md）と機能設計書（docs/functional-design.md）の前提条件を確認した上で、アーキテクチャ設計書を作成します。既存設計書（docs/architecture.md）がある場合はそれを優先し、ない場合は提供されたテンプレート（./template.md）とガイド（./guide.md）に従い新規作成します。アーキテクチャ設計は、PRDの要件と機能設計を技術的に実現するためのシステム構造とテクノロジースタック（使用言語・フレームワーク・DB・ミドルウェアなど）を定義します。出力先は docs/architecture.md です。

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。分類後、対象ファイルを直接更新します。

プロジェクト固有の用語と技術用語を体系的に定義・管理できます。 要件定義書、設計書、アーキテクチャなど複数ドキュメントから用語を統一的に抽出できます。 既存の用語集がある場合、その構造を保ちながら追加・更新できます。 全チームで用語の意味を共通認識化し、ドキュメント作成時の表記ゆれを防げます。 プロジェクトマネージャーで、チーム内の用語定義を統一したい人 ドキュメント作成者で、用語の一貫性を保ちたい人 新しいプロジェクトを立ち上げるときに用語体系を整備したい人 用語集を作成するための詳細ガイドです。前提条件として、①docs/product-requirements.md（PRD）②docs/functional-design.md（機能設計書）③docs/architecture.md（アーキテクチャ設計書）④docs/repository-structure.md（リポジトリ構造）⑤docs/development-guidelines.md（開発ガイドライン）を確認します。既存ドキュメント優先順位は①既存docs/glossary.md（最優先、プロジェクト固有定義）→②このスキルのガイド（参考資料）です。新規作成時はテンプレート使用、更新時は既存構造・内容を維持します。出力先はdocs/glossary.md、詳細ガイドは./guide.md、テンプレートは./template.mdを参照します。

PRDの要件を技術実装の詳細設計に落とし込み、機能設計書を素早く作成できます。 既存の設計書がある場合は自動的にそれを参考にし、構造を保ちながら更新・補足できます。 テンプレートとガイドが用意されているため、何から書き始めるか迷わずに執筆を開始できます。 設計書を docs/functional-design.md に一元管理し、チーム全体で設計内容を共有できます。 プロダクト企画者が決めた要件を、開発者向けに技術的な実装方法として落とし込みたい人 チームメンバーに「この機能はどう実装する予定？」を分かりやすく説明したい人 新しいプロジェクトやフェーズの開始時に、設計ドキュメントの骨組みをすぐに整えたい人 既存の設計書を保ちつつ、内容を段階的に充実させたい人 機能設計書作成の前提として、docs/product-requirements.md のPRDが存在する必要があります。設計書の優先順位として、既存の docs/functional-design.md がある場合はそれを最優先とし、このスキルのガイドは参考資料として使用します。新規作成時はテンプレート（./template.md）と詳細ガイド（./guide.md）を参照してください。作成した機能設計書は docs/functional-design.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）」を掲げ、ユーザーストーリーフォーマットと優先度分類が含まれます。

アーキテクチャ設計で決まった技術スタック（言語、フレームワーク、DBなど）を反映した、実際のディレクトリ構造を定義できます。 src/, tests/, docs/, config/ など、各フォルダの役割と配置ルールを明文化し、開発チーム全体で統一できます。 既存のディレクトリ構造定義がある場合は優先し、ない場合は提供テンプレートを使って新規作成できます。 新しいメンバーが加わったときに「このファイルはどのフォルダに置く？」という質問がなくなり、コード審査がスムーズになります。 作成した定義書は docs/repository-structure.md に自動保存され、プロジェクト全体で参照可能になります。 プロジェクトを始める前に「ファイル置き場を決めたい」プロジェクトマネージャー・PO 複数開発チームが参加するとき、ファイル配置の統一ルールを作りたいテックリード リポジトリが成長するにつれて雑然としてきたプロジェクトを整理し直したい開発責任者 オンボーディングを効率化し、新しいチームメンバーの迷いを減らしたいマネージャー このスキルは、PRD（docs/product-requirements.md）、機能設計書（docs/functional-design.md）、アーキテクチャ設計書（docs/architecture.md）の前提条件を確認した上で、リポジトリ構造定義書を作成します。既存定義書（docs/repository-structure.md）がある場合はそれを優先し、ない場合は提供されたテンプレート（./template.md）とガイド（./guide.md）に従い新規作成します。リポジトリ構造は、アーキテクチャ設計で決定された技術スタックとシステム構成を反映した具体的なディレクトリ構造およびファイル配置ルールを定義します。出力先は docs/repository-structure.md です。

ユーザーからの新機能や変更指示を受け取ると、それに基づいた作業計画書（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 検証あり。

ADR（設計判断記録）、作業プラン、調査メモなどを統一フォーマットで作成・保存できます。 日付とカテゴリで自動的にファイルを整理し、docs/配下に体系的に蓄積できます。 既存ドキュメントを一覧表示して、過去の設計判断や作業履歴を素早く検索できます。 テンプレートを活用することで、設計意思決定を漏れなく記録する習慣がつきます。 技術的な設計判断とその根拠を記録して共有したいエンジニア プロジェクトの実装計画をドキュメント化して、チーム内で認識を統一したいPM・TL 技術調査結果や新ツール導入の検討内容をナレッジとして蓄積したい開発チーム プロジェクト期間中の重要な決定事項を後から参照できる形で残したいすべての職種 docs/配下にadr/（設計判断記録）、plan/（作業プラン）、research/（調査メモ）のディレクトリを用意します。ファイル名はdocs/{category}/yyyy-mm-dd_{タイトル}.mdの形式です。/doc create {category} "タイトル"で新規作成、/doc listで一覧表示ができます。ADRテンプレートは「ステータス→コンテキスト→決定→根拠→影響」の構成、作業プランは「概要→ステップ→対象ファイル→検証方法」、調査メモは「背景→調査結果→結論」の構成です。カテゴリは固定ではなく、必要に応じて新規ディレクトリを作成してよく、テンプレートはガイドラインで内容に応じて自由に調整できます。

メモを構造化Markdownに整理: バラバラなメモや箇条書きを、段落・見出し・階層構造のある統一したMarkdownへ整理します。Marpやスライド形式は意識せず、「伝えたい内容の構造」に集中できます。 スライド設計を中間成果物として作成: 整理された内容をスライドに分割し、各スライドのレイアウト・情報量・構成を定義する設計書を生成。発表時間に合わせた適切な枚数の提案も行います。 Marp形式の最終資料を自動生成: スライド設計書に基づき、Marp構文に沿った本番用HTMLスライド資料を生成。複数のレイアウトクラス（title、section、image、column-layoutなど）を活用した見栄えの良い資料が作れます。 各ステップでユーザー確認を実施: 内容整理→スライド設計→Marp生成と、ステップごとに必ずユーザーの修正指示を受けてから次に進むため、品質の高い資料が段階的に完成します。 途中から再開できる: ファイルの接頭辞（01_organized_、02_slide-design_、03_marp_）で自動判断し、途中から再スタートして効率的に進められます。 営業・企画担当者: 提案書やプレゼン資料を短時間で品質高く作成したい人 勉強会・社内研修の講師: 講演資料を体系的に整理し、見栄えの良いスライドに仕上げたい人 デザインスキルが未熟な人: レイアウトやビジュアルは自動で調整してもらい、内容に集中したい人 資料品質を重視する人: 複数の段階で修正・確認を重ねることで、完成度の高い資料を確実に作りたい人 3ステップのワークフロー: ステップ1（内容整理）でメモを構造化Markdown（01_organized_*.md）に変換。ステップ2（スライド設計）で整理済みmdをスライド分割設計書（02_slide-design_*.md）に変換。ステップ3（Marp生成）で設計書から最終Marpファイル（03_marp_*.md）を生成。各ステップ完了時に必ずユーザー確認を取り、修正指示がなければ次に進みます。発表時間とスライド枚数の目安は5分で5〜8枚、10分で10〜15枚、15分で15〜20枚、30分で20〜30枚。レイアウトクラスはtitle（表紙）、section（区切り）、基本（テキスト中心）、image（図表のみ）、content-image（図表とキャプション）、content-image-right/left（横並び）、column-layout（複数項目横並び）、small-text（情報量多）を利用。開始ステップは入力ファイル形式で自動判定され、メモ（接頭辞なし）→ステップ1、01_organized_→ステップ2、02_slide-design_→ステップ3から開始します。

実行計画テーブルから未完了タスクを自動抽出し、次々と着手します。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`に選択肢を記録し最適な方を選んで進みます。ビルドエラー・テスト失敗は原因調査・修正を試みた後、止めずに次タスクへ移行します。

ゴール文書を入力すると、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完了、コード実装済み、解析エラーなし、テスト通過、計画更新済みです。

症状から出発して、ログ・スタックトレース・デバッグツールを活用しながら根本原因を特定できます 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：マージンプラットフォーム別に設定。各プラットフォーム仕様が詳細に定義されています。