業務自動化

バージョン番号とビルド番号を自動更新：現在のバージョンを確認し、リリース内容に応じてバージョンを 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 作成が完了したら終了。

新しくリリースされた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 でアップグレード最新情報を参照します。

新機能実装時に 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()（ロール別ブロードキャスト）で実装します。

プロジェクト固有の用語と技術用語を体系的に定義・管理できます。 要件定義書、設計書、アーキテクチャなど複数ドキュメントから用語を統一的に抽出できます。 既存の用語集がある場合、その構造を保ちながら追加・更新できます。 全チームで用語の意味を共通認識化し、ドキュメント作成時の表記ゆれを防げます。 プロジェクトマネージャーで、チーム内の用語定義を統一したい人 ドキュメント作成者で、用語の一貫性を保ちたい人 新しいプロジェクトを立ち上げるときに用語体系を整備したい人 用語集を作成するための詳細ガイドです。前提条件として、①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を参照します。

アーキテクチャ設計で決まった技術スタック（言語、フレームワーク、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 です。

別リポジトリ間の変更を効率的に同期：mainリポジトリとkagリポジトリは独立した2つのGitHubリポジトリですが、チェリーピック機能により必要なコード変更のみを選別して適用できます。 コード変更とドキュメントを分離：機能実装やスキル設定は反映し、kagリポジトリ独自のドキュメント方針を保つため、ドキュメント変更は自動的に除外されます。 コンフリクトを最小化：マージではなくチェリーピックを使うことで、大量のコンフリクトを回避し、意図した変更のみを適用できます。 環境固有の設定を保護：kagリポジトリの環境変数や設定値を保ったままで、汎用的なコード改善だけを取り込めます。 「kagにも適用して」と指示されたときに安全かつ迅速に対応したい開発者 複数のAIエージェント環境を管理しており、共通機能を一括更新したい人 mainでバグ修正した内容をkagにも反映させる必要がある場合 Git操作に不安があるが、チェリーピック手順を理解したい初心者 mainリポジトリとkagリポジトリは完全に別のGitHubリポジトリとして管理されています。mainはminorun365/marp-agent、kagはminorun365/marp-agent-kagで、kagリポジトリにはupstreamリモートとしてmarpが登録されています。 同期対象はアプリコード変更と.claude/以下のスキル・サブエージェント設定で、docs/配下はkagの差分記載方針のため反映しません。手順は①mainで直近コミットの確認②kagリポジトリに移動してgit pull origin main、git fetch upstream、git cherry-pick を実行③git push origin mainで完了します。コンフリクト時はgit diff --name-only --diff-filter=Uで該当ファイルを確認し、手動解決後にgit add・git cherry-pick --continueで続行するか、git cherry-pick --abortで中止できます。

クライアント-サーバー間の通信プロトコルを「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に登録します。

X（Twitter）用のリリースノート投稿ドラフトを自動解析し、Discord用に整形・統合できます。 メインポスト＋連投を1つのメッセージに統合し、メディア行やメタ情報は自動除去します。 リリースバージョンに合わせたヘッダー、X投稿URL、GitHub Release URLを自動追加できます。 環境変数からDiscord webhook URLを読み込み、認証なしで安全に投稿できます。 投稿前にユーザーに内容を確認させ、Discord の2000文字制限をチェックしてから投稿します。 ソフトウェアリリースの告知をX・Discord両プラットフォームに投稿する開発チーム リリースノート作成の二重作業を削減したい開発者 リリース情報を複数チャネルで統一した形式で発信したい製品マネージャー Discord webhook設定ができる技術リード・DevOps担当者 バージョン $ARGUMENTS のXドラフトファイル（docs/release_notes/v$ARGUMENTS/xpost_v$ARGUMENTS_draft.md）から環境変数 DISCORD_WEBHOOK_URL を確認し、未設定の場合は設定を要求します。ドラフト内容から以下を機械的に変換：メインポスト＋連投を統合、添付メディア行（![...]等）・メタ情報セクション・区切り線を除去、セクション見出しを削除、冒頭に「MulmoCast（デスクトップアプリ）v リリースしました！」ヘッダーを追加、X投稿URLと GitHub Release URLを付加、同一トピックの英語/日本語はスラッシュ区切りで統合、トピック間を空行区切りで整形します。整形後ユーザーに確認させ、2000文字内かチェックしてから jq で JSON を構築し curl で webhook に 投稿します。HTTP 204 で成功、他は エラー報告を行います。

CHANGELOG.mdから対象バージョン範囲の変更情報を自動抽出し、X（Twitter）投稿用の280文字以内の日本語テキストを生成できます。新機能・バグ修正・改善を変更カテゴリ別に絵文字で分類し、ユーザーにメリットが伝わる文面を自動作成します。 バージョン範囲を「v0.2.4～v0.2.9」「v0.2.9（直前から）」「最新リリース」など柔軟に指定でき、複数バージョンのまとめ投稿にも対応します。 生成された投稿文に概算文字数を表示し、そのままコピペでX投稿できる状態に整えます。 プロダクトマネージャー：リリース告知をSNSで迅速に配信したい人 マーケティング担当者：リリース情報をユーザーフレンドリーに加工したい人 開発チームリード：チーム内での連絡とSNS投稿を効率化したい人 3ステップ実行： 1. バージョン範囲特定：引数から開始・終了バージョン判定（2引数→指定範囲、1引数→直前タグから対象、0引数→最新リリース）、git tagで確認 2. CHANGELOG.md抽出：対象バージョン範囲のセクション全読込、変更内容を収集 3. 投稿文生成：フォーマット規則に従い生成 フォーマットルール：280文字以内（URLを除く）、日本語、カジュアルかつプロフェッショナル。構成＝タイトル行（v{version}リリース🎉）→サブタイトル（進化を簡潔に）→変更箇条書き（絵文字付き、ユーザー向けメリット重視、最大6項目）→固定フッター（CommandMate説明・GitHub link・ハッシュタグ）。変更カテゴリ別絵文字：新機能✨、バグ修正🩹、セキュリティ🔒、パフォーマンス⚡、UI/UX🎨等。

GitHub API・Yahoo Japan・Google検索を組み合わせて、直近1か月で更新・告知されたVRChat VPM（パッケージ管理システム）リポジトリを自動で検出できます。 リポジトリの作成日ではなく、最近の更新履歴や公開告知で発見できたものを報告対象とするため、埋もれていた配信元も見つかります。 GitHub Pages・カスタムドメイン上のindex.json・vpm.json形式を確認して、実在する正規のVPMリポジトリのみを報告できます。 既知リストのURLと照合してフィルタリングし、重複報告を避けて未収録の配信元のみを集約して提出できます。 複数の検索手段を並列実行することで、単一の検索では見落とされるニッチなVPMリポジトリも発掘できます。 VRChat コミュニティのVPMパッケージ情報をまとめている方 VRChat用ツール・アセット・プラグインの配信元リストを常に最新に保ちたいキュレーター VPMカタログの運用・保守を担当するメンテナー GitHub APIと複数の検索ソースを活用して、信頼性の高いリポジトリ検出が必要な方 VPM Repository Discoveryスキルは、GitHub API（主要手段）・Yahoo Japan リアルタイム・Google・Booth連携（補完）を用いてVRChat向けVPMリポジトリを発見します。フロー：①既知URLの読み込み（repositories.txt + repositories-ignore.txt、#以降は理由コメント）→②GitHub API検索（複数クエリで直近1か月更新範囲）→③補完検索（Yahoo・Google・Booth）→④URL正規化と検証（短縮URL展開、index.json/vpm.json確認）→⑤結果報告（未収録URL集約）。既知URLセットでフィルタリングするが情報源としては使用しません。GitHub Search APIではpushed:>YYYY-MM-DDで直近1か月に限定するものの、過去作成・最近更新のリポジトリも報告対象に含めます。複数クエリ（vpm+vrchat、vpm+package+listing+vrchat、vpm-listing+vrchat、VCC+listing+vrchat）を並列実行し、has_pages:true・fork:false・対象外（vpm-catalog自身、vrc-get等ツール系）でGitHub Pages URLを抽出します。homepageフィールドのカスタムドメインも候補とし、ページネーション対応（total_count>30は&page=2取得）をします。補完検索ではYahoo Japan リアルタイムやplaywright-cliを活用し、GitHub APIでは見つからない情報源を補完します。

ゲーム風カットイン演出の自動発動：メッセージを入力するだけで、SVG 背景のスライドイン、フラッシュ、キャラクタースライドイン、テキストフェードといったソシャゲの必殺技演出のような派手なアニメーションを自動再生できます。 感情に応じた背景の自動選択：喜び・穏やか・照れ・困惑・ノリノリなど、メッセージの感情を指定すると、それに合った背景（金色キラキラ・桜吹雪・紫ストライプなど）が自動で選ばれます。 手動での細かな演出カスタマイズ：背景パターン（赤系集中線・サイバーグリッド等）を手動で指定でき、演出の印象をコントロールできます。 TTS（音声合成）との連携：テキストを音声で読み上げながら演出が再生されるため、より没入感のある体験になります。 コンテキストからの自動メッセージ生成：引数なしで呼ばれた場合、直前の会話文脈から適切なメッセージと感情を自動推測し、さらに手間を減らせます。 プレゼンテーション・デモで印象的な瞬間を作りたい人：重要なメッセージをゲーム風の派手な演出で強調でき、視聴者の印象に残りやすくなります。 マスコット機能を使ったアプリケーションの開発者：演出スキルを組み込むことで、ユーザーとの対話がより魅力的になります。 感情表現の豊かなコミュニケーションを取りたい人：感情に応じた背景が自動選択されるため、メッセージの意図が視覚的に伝わりやすくなります。 macOS ユーザー：このスキルは macOS 専用で、Flutter フレームワークを使用しており、ネイティブな動作が保証されています。 このスキルは macOS 専用（flutter run -d macosでのみ動作確認済み）で、マスコットのフルスクリーン演出を制御します。使用方法：/cutin "メッセージ"（感情自動選択）、/cutin --emotion Joy "テスト全通過！"（感情指定）、/cutin --emotion Singing --bg cyber "リリース！"（感情＋背景指定）。 感情キーと自動背景：Gentle（穏やか）→ sakura、Joy（喜び）→ sparkle_burst、Blush（照れ）→ sakura、Trouble（困惑）→ diagonal_stripes、Singing（ノリノリ）→ sparkle_burst。背景パターン（手動指定用）：speed_lines（赤系集中線）、diagonal_stripes（紫斜めストライプ）、sparkle_burst（金色キラキラ）、sakura（ピンク桜吹雪）、cyber（サイバーグリッド）。 実行手順：（1）pgrep -f "utsutsu_code"でマスコット起動確認。（2）引数解析（--emotion、--bg、その他はメッセージ）。引数なしは直前コンテキストから推測。（3）シグナルファイル~/.claude/utsutsu-code/cutinに JSON 書き込み（message、emotion、background キー）。マスコットがファイル監視で検出し、サブプロセス起動。（4）2秒待機後にファイル存在確認で発動確認。

mod_version をチェックし、バージョンが古ければ更新種別（メジャー・マイナー・パッチ）を聞いて自動更新できます。 Gradle でビルドし、失敗したら即座に中断して原因を報告できます。 前回のリリースから今回の変更内容を自動取得し、リリースノートのドラフトを作成できます。 Git タグを作成して GitHub に push し、GitHub Releases に Fabric・Forge 両方の JAR ファイルを自動アップロードできます。 ビルド・タグ作成・リリース作成の各ステップで確認を取りながら進められるので、誤ったリリースを防げます。 Minecraft mod の開発者で、リリース作業を毎回手作業でやっている人 バージョン更新・ビルド・タグ・GitHub Release 作成をまとめて自動化したい人 Fabric と Forge の両方に対応したモッドを公開している人 リリースノートを手書きするのが面倒で、変更履歴から自動生成したい人 このスキルは Minecraft mod（LMML）のリリース全体を自動化します。前提条件として gradle.properties に mod_version が更新済み、ワーキングツリーがクリーン、gh CLI が認証済みである必要があります。手順：(1) gradle.properties から mod_version を読み取りユーザーに確認、未更新なら更新種別（x/y/z）を聞いて自動編集・コミット、(2) ./gradlew build を実行し失敗時は中断、(3) git describe --tags --abbrev=0 で前回タグを特定、git log で変更履歴を取得しリリースノートをドラフト、ユーザーに提示して確認、(4) git tag v{version} と git push origin v{version} でタグ作成・push、(5) gh release create で GitHub Release を作成し Fabric・Forge の JAR ファイルをアップロード（ファイル名パターン: LMML-{mc_version}-{version}-Fabric.jar など）、(6) Release URL をユーザーに報告。各ステップで確認を取り、Minecraft バージョン変更時はファイルパス確認に注意。

/tsukuyomi-setup でセットアップが完了したマスコットアプリを起動できます。 macOS・Windows・Linux各プラットフォームで、自動的にマスコットが既に起動中かどうかを確認し、重複起動を防ぎます。 COEIROINK v2（音声合成ツール）の起動状態を自動チェックし、未起動時は起動を案内します。 --no-tts 引数で音声合成をスキップして、マスコットのみを起動することもできます。 マスコットアプリのセットアップを完了し、日常的に起動・運用したい開発者 macOS上でFlutter開発をしており、マスコット表示を確認しながら作業したい人 Windowsのリリース版exe でマスコットを運用する人 マスコット起動の流れ：(1)既起動確認（pgrep/Get-Process で判定）→ (2)COEIROINK v2ポート確認（localhost:50032）→ (3)macOS/Linuxではアセット確認（モデル・フォールバック画像） → (4)起動実行（macOS は flutter run -d macos &、Windows はリリース exe を探索実行）。既起動時は「再起動したい場合は /tsukuyomi-cleanup process で停止してから再実行」を案内します。セットアップ未完了時は /tsukuyomi-setup への誘導、モデル・アセット不足時も同様に誘導します。COEIROINK未起動時はmacOS で「アプリ起動してください」、Windows はポートチェックのみで案内。マスコット自体は音声なしでも動作します。

Cluster Script APIの型定義（index.d.ts）から必要なメソッドや引数をキーワード検索で素早く見つけ出せます。JSDocコメント付きで詳細な使い方も同時に表示されます。 日本語と英語の両方でAPI検索に対応しているため、「位置設定」でも「setPosition」でも同じ結果が得られます。 ItemHandle、PlayerHandle、Vector3など、インターフェース名やクラス名で検索を絞り込むことで、より正確な情報取得が可能です。 ファイルが古い場合は自動更新され、常に最新のAPI仕様を参照できます。 Cluster Script開発時に、特定のメソッドのシグネチャや引数仕様を素早く確認したいエンジニア APIドキュメントから目的の関数を探すのに時間がかかる開発者 ItemHandle・PlayerHandleなど特定のオブジェクトの全メソッド一覧を参照したい方 Cluster Script APIの型定義ファイル（index.d.ts）からAPI情報を検索するスキルです。スクリプトのパスは ${SKILL_DIR}/scripts/ 配下にあります。search.pyでキーワード検索を実行し、JSDocコメント + シグネチャをテキスト形式で出力（最大30件）します。ファイル未ダウンロード時は自動取得します。download.pyで最新のindex.d.tsを手動更新できます。キーワード最適化ルールとして、メソッド名直接検索（setPosition、getRotation等）、日本語検索、interface/classでの絞り込み、関連用語での横断検索に対応しています。

リージョン内のノード間で VM をゼロダウンタイムのライブマイグレーション（Protocol C）で実行できます。 リージョン間での VM コールドマイグレーション（VM 停止が必要）を自動化できます。 廃止するリージョンの全 VM を別リージョンに自動移行し、ノードを削除できます。 新しいリージョンを追加し、DR（災害復旧）レプリカを自動設定できます。 2+1 構成（リージョン内 2 レプリカ + リージョン間 1 DR レプリカ）のセットアップと管理を簡素化できます。 LINSTOR/DRBD マルチリージョン環境を運用しており、VM 移行を効率化したい基盤エンジニア リージョン廃止・追加など、大規模な基盤変更を安全に実行したい SRE・インフラ担当者 ダウンタイムを最小化（50ms 程度）しながら VM を移行する必要がある環境 DR レプリカの構築・管理を自動化したいデータセンター運用チーム 本スキルは LINSTOR マルチリージョン環境での 5 つのサブコマンドを提供します。live-migrate はリージョン内のノード間で Protocol C（同期レプリケーション、allow-two-primaries=yes）を活用し、ゼロダウンタイムで VM 移行します。実測ダウンタイムは 33～74ms、移行時間 11～18 秒です。事前に状態記録（qm status、drbdsetup status、uptime）を取得、ライブマイグレーション実行後に整合性検証（チェックサム、Primary ノード確認）を行います。cold-migrate はリージョン間移行で VM 停止が必須です。decommission-region は廃止リージョンの全 VM を自動移行後にノード削除、add-region は新規リージョン追加と DR 設定、setup-dr は 2+1 構成用 DR レプリカ追加です。全操作に pve-lock.sh と oplog.sh で排他制御とオペレーションログを記録します。トポロジーは Region A/B それぞれ 3 ノード、Protocol C リージョン内接続、Protocol A リージョン間接続です。

outline.mdから出発し、「発表の場」「発表形式・時間」「その場の求め」などの制約条件を確認した上で、何を話して何を捨てるかを段階的に決めていけます。アウトラインの全量を時間内に話すのは難しいため、ユーザーと一緒に優先度を逆算して絞り込めます。 アウトラインの章順がそのまま発表に最適とは限らないため、LT（5分）・セッション（20分）・セッション（40分）など形式に応じた構成パターンを提案し、聴衆の集中力を考慮した再構成ができます。 goal.md の「語りのスタンス」を踏まえ、結論を言い切る・問いかけを挟む・エピソード語りを軸にするなど、話し方の方針を対話で詰められます。 壁打ち結果をoutput/$ARGUMENTS/talk/talk-note.mdに保存し、複数回の壁打ちを重ねるたびに最新結果に更新するため、発表本番までの改善サイクルが記録に残ります。 このスキルは何度でも実行可能なため、時間が経ってから「もう一度壁打ちしたい」という場合も既存の壁打ちメモから続きの作業ができます。 LT 大会や勉強会での発表が決まり、アウトラインはあるけど時間内に何をしゃべるか整理したい人 20分と40分で同じテーマを発表する際、時間に応じた構成を切り替えたい スピーカー 何を優先して伝えるべきか、一人では判断しにくい複雑なテーマの発表者 発表の「壁打ち」をAIと対話形式で詰めて、本番に備えたい講演者 $ARGUMENTSにプロジェクト名が指定される場合、CLAUDE.md の命名規則に従いディレクトリを解決します。output/$ARGUMENTS/outline/outline.md（アウトライン）、goal.md（ゴール）、context.md（コンテキスト）、既存ならtalk/talk-note.md（壁打ちメモ）を読み込みます。outline.md 不在なら/outlineを案内。ユーザーに制約条件を確認：(1)発表の場（例：吉祥寺.pm、社内勉強会）(2)発表形式・時間（LT 5分、セッション20分/40分）(3)その場で求められること（任意）。既存 talk-note.md があれば前回制約条件を提示し、同条件で続行するか確認。壁打ち進め方：(1)取捨選択（何を話して何を捨てるか、ゴール逆算）(2)構成の組み替え（LT/20分/40分パターン提案、聴衆集中力配慮）(3)話し方の方針（結論言い切り・問いかけ・エピソード語り、トーン設定）(4)不安解消。対話後、壁打ちメモをoutput/$ARGUMENTS/talk/talk-note.mdに保存、ユーザー確認後に上書き。何度でも実行可能で、壁打ちを重ねるたびにメモが最新化されます。

まだ記事やスライドの形になっていない「思いついたばかりのアイデア」を素早く記録できます。 記録したアイデアを一覧表示し、作成日付やステータス（ネタ、アウトライン作成中）で管理できます。 アイデアの詳細をいつでも確認し、ブラッシュアップ（深掘り対話）で解像度を高められます。 ブラッシュアップで出た内容を自動的にメモとして保存し、アイデアを段階的に育てられます。 アイデアが固まれば、そのまま /outline コマンドでアウトラインワークフロー（記事・LT・登壇の構成作成）に進めます。 日々いろいろなアイデアが浮かぶけど、どこに記録するか決めていない人 LT・ブログ・登壇ネタは思いつくけど、実際に形にするまでに時間がかかる人 「いつか書きたい」というアイデアを整理・育成したい人 複数のプロジェクト（分野）で異なるアイデアを一元管理したい人 このスキルは output//idea.md にアイデアを 1 ファイル 1 ネタで保存し、CLAUDE.md の命名規則に従って YYYYMMDD-NN_タイトル 形式のディレクトリを自動生成します。add コマンド（引数なし）でネタを追加する際、タイトル・ひとことメモ・想定アウトプット形式（LT/ブログ/登壇など）・きっかけ背景を聞き、templates/idea.md に沿って保存します。list コマンドで output/*/idea.md を検索し、作成日の降順で表形式（作成日・タイトル・形式・ステータス）で表示し、outline/ ディレクトリの有無でステータス（ネタ/アウトライン作成中）を判定します。show コマンドで特定のアイデアを詳細表示し、brush コマンドで対話形式でアイデアを深掘り（「何が面白いか」「誰に届けたいか」「自分ならではの視点」など）し、メモ欄に追記保存します。outline は構造化ドキュメント（context.md・goal.md・outline.md）を作るのに対し、brush は idea.md 内のメモを育てるだけで形式を整えません。

LLM特有の表現パターン（定型的な言い回し、冗長な説明など）を自動検出して、修正案を提示できます。 ファイルの文体方針（ブログ、エッセイ、ドキュメントなど）に合わせて修正内容をカスタマイズできます。 修正内容をユーザーと対話しながら決定でき、意図的な表現は尊重して機械的な置換を避けられます。 修正履歴を自動的にログに記録し、プロジェクト内で修正内容を可視化できます。 AIに生成させた文章を人間らしく見せたい編集者やライター ブログ記事やドキュメントの品質を高めたいコンテンツ作成チーム ChatGPTやClaude等で生成された文章を最終確認する際の手間を減らしたい人 「これLLMっぽい」という違和感を素早く言語化して修正したい場面 対象ファイルを指定して実行。patterns.mdのパターンマッピングに従い、LLM生成文の特有表現を検出します。修正案のトーンは、output/配下のファイルなら対応するwrite-plan.mdの「文体方針」セクションから、それ以外はユーザーへの確認で取得します。write-plan.mdで意図的に許容されている表現は対象外とします。検出時は1箇所の使用は許容し、繰り返し・集中して現れるパターンを重視。カテゴリ6（結びの定型表現）は1回でも検出対象。診断結果をユーザーに提示し、修正案採用・修正・却下を確認する対話的な改善フローを実施。承認内容をファイルに適用後、output/配下ならhumanize-log.mdにログを保存します。

自然言語でMCPツールを検索 - 「メール送信」「データベース接続」など日本語で説明するだけで、関連するツールを自動発見でき、ツール名を覚えていなくても利用できます。 見つかったツールのスキーマを自動取得 - 検索結果のツールについて、必要な入力パラメータ・出力形式を自動表示するため、ツール仕様を確認しながら利用できます。 コンテキストを肥大化させない - 全ツールを同時に公開するのではなく、必要なツールだけを動的に検索・実行するため、AIのプロンプトサイズを削減できます。 メタツール経由でツール実行を一元管理 - search_tools → describe_tools → execute_toolの3ステップで、統一的なツール実行フローを実現できます。 エンタープライズエディション（EE）限定機能 - Community Edition（CE）では無効化され、EE環境でのみDynamic Search機能を活用できます。 MCPサーバー管理者 - ツール数が多い環境で、Dynamic Searchを有効化してAIのコンテキスト効率を改善できます。 AI統合開発者 - search_tools、describe_tools、execute_toolメタツールを理解し、カスタム検索・実行ロジックを実装できます。 Enterprise Edition ユーザー - EE機能を最大限活用して、大規模MCPサーバー環境でのツール管理を最適化できます。 Dynamic Search機能のデバッガー - 新規実装・拡張・バグ修正時に、このリファレンスガイドを参照して効率的に対応できます。 Dynamic Searchはツール発見を最適化するインテリジェント検索システム。従来モードではすべてのツールを{template}__{toolName}形式で公開してコンテキストが肥大化しますが、Dynamic Searchモード（dynamicSearch=true）では3つのメタツール（search_tools、describe_tools、execute_tool）のみ公開し、必要なツールを動的に検索・取得します。ノードは.ee.ts拡張子とSPDXライセンスヘッダー必須のEE実装。型定義はMCP SDK型（Tool、CallToolRequestParams）をre-export。SearchToolsArgs（検索クエリ、最大結果数）、DescribeToolsArgs（スキーマ取得対象ツール名）、SearchResult（ツール名、説明、関連度スコア0-1）、DescribeToolsResult（ツール名、説明、inputSchema、発見フラグ）を定義。metaToolDefinitions.ee.ts、searchTools.ee.ts、describeTools.ee.ts、executeToolDynamic.ee.tsで実装。EE/CE分離アーキテクチャを理解し、ファイル構成はapps/mcp-proxy/src/features/dynamicSearch/配下に整理されています。