Skill.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：クリーンアップ。デバッグログ全削除、プロジェクト一貫性確認。アンチパターンは推測修正・一度に大量変更・ログ残し。

会話履歴から作業手順を自動抽出 - これまでの対話の中で実行した操作・判断・スクリプトを自動で分析し、誰が読んでも再現できる手順に言語化します。 暗黙的な判断基準を明記 - 「ここで条件分岐する理由は何か」「なぜこのツールを使うのか」といった背景を徹底的に言語化。エージェントが正しく判断できるようになります。 スキル名を自動提案してカスタマイズ可能 - 既存スキルとの重複をチェックし、3つの名前候補を提示。「これがいい」と指示するだけでスキル化が進みます。 公式ベストプラクティス準拠の高品質SKILL.mdを生成 - ファイル構造、説明文、セクション分けなど、Anthropic公式の基準に準拠したスキルが完成します。 スクリプト・参照ファイルも整理して配置 - 作成したスクリプトや参照資料も、スキルディレクトリ内に自動で整理・配置します。すぐに他のプロジェクトで再利用できます。 開発チーム全体 - よく繰り返す手作業（デプロイ、テスト、ドキュメント生成など）をスキル化し、チーム全体で再利用したい場合。 SRE・DevOps - 運用作業をスキル化して属人化を解消し、チーム全員で対応できるようにしたい場合。 プロダクト開発 - 「このタスク、毎回同じ手順だな」と思った作業を素早くスキル化して効率化したい場合。 技術リーダー - チームの知見（ノウハウ）をスキル化し、プロジェクト内で共有・再利用する仕組みを作りたい場合。

SKILL.mdファイルを自動レビュー - スキルのメタデータ（名前、説明、タグ）、本体のセクション構成、内容の品質などを、Anthropic公式の基準に照らして全項目チェックします。 落ち穴やベストプラクティス違反を指摘 - 「説明文がトリガーワードを含まない」「冗長な説明がある」「参照ファイルの条件が不明確」といった、実際に多く見られる問題を具体的に指摘。 改善提案を優先度付きで提示 - Critical（スキルの動作に支障あり）→Major（品質低下）→Minor（微調整）の3段階で、何から直すべきかが一目瞭然です。 修正ステップを段階的にサポート - 重要度の高い修正から順に実施し、各修正後に再検証。段階的に品質を上げていけます。 スキルの実装構造も検証 - ディレクトリ構成、スクリプト、参照ファイル、評価ケースなども含めて総合的にチェックします。 スキル開発者 - 自分が作ったスキルを公式基準で評価し、品質を高めたい場合。 技術リーダー - チームが作成したスキルを統一基準でレビューし、品質を保証したい場合。 プロダクト開発チーム - 社内で使用するスキルを標準化し、再利用性を高めたい場合。 エージェント開発者 - 自動化ツールとして作るスキルの仕様を厳密にしたい場合。