Skill.md検索

ソースコード変更から対応スキルを自動特定し、どのドキュメントを更新すべきかを提示します スキル内のコード例とソースコードを比較し、差分がないか自動確認します sourcePatterns（監視対象ファイル）の設定が正しいか検証し、設定ミスを防ぎます 複数スキルの sourcePatterns を一覧で確認でき、スキル更新の漏れを防げます ソースコード更新後、対応ドキュメントをどれ更新すべきか分からない開発者 スキルドキュメント（SKILL.md）の差分管理・メンテナンスを自動化したいプロジェクト管理者 複数スキルを管理していて、更新漏れが発生しやすいドキュメント運用担当者 CLAUDE.mdやスキル内容の最新性を定期的に確保したいチームリーダー スキルと対応ソースコードの関係を管理し、変更検出→スキル特定→差分確認→sourcePatterns検証の4ステップで運用します。各スキルには sourcePatterns が定義されており、対応ソースファイルが変更された場合にスキルの更新が必要になります。変更されたファイルと sourcePatterns を照合し、更新が必要なスキルを特定。スキル内のコード例と実際のソースコードを比較し、乖離がないか確認。sourcePatterns が正しく設定されているか検証します。変更検出は git diff（最新5コミット、mainからの差分、特定コミットからの差分）で行い、複数スキル（tumiki-custom-mcp-server-feature、tumiki-dynamic-search-feature、tumiki-ee-ce-separation、tumiki-mcp-proxy-architecture、tumiki-prisma-schema-changes）の対応パターンを一覧で管理します。

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

iOS / Android のストアスクリーンショットを自動撮影・合成し、最新のUI状態をアップロード用に準備できます。 最新の CHANGELOG を分析して、App Store・Google Play 向けのリリースノートや説明文を自動生成・更新できます。 UI変更があったかどうかを判定し、更新対象（スクリーンショット、リリースノート、説明文等）をユーザーに提案できます。 Simulator × モック画面 × Marionette MCP を組み合わせることで、手作業のスクショ撮影・編集をほぼ自動化できます。 iOS・Android アプリのリリース時にストアメタデータを何度も手で更新しているエンジニア ストアスクリーンショットの撮影・編集に毎回時間をかけているプロダクトマネージャー CHANGELOG 更新後、App Store・Google Play・fastlane メタデータを同期更新したい開発チーム モバイルアプリの多言語対応（英語、日本語など）で、各言語のメタデータ更新に手間がかかっている人 ワークフロー三段階: Step 1 - バージョン確認・変更分析（git tag、pubspec.yaml、CHANGELOG確認）。Step 2 - 更新対象選択（8スクリーンショットシナリオ + 9メタデータテキストファイル）。Step 3 - メタデータテキスト更新（CHANGELOG ベースに release_notes・description・promotional_text を自動生成）。 スクリーンショット 8 シナリオ: Session List（ライト）、Approval List、Multi-Question Approval、Markdown Input、Image Attach、Git Diff、New Session、Session List（ダークモード）。各シナリオ用に ccpocket.navigateToStoreScenario カスタムエクステンション実行後、Simulator からスクショ撮影。 メタデータファイル: fastlane/metadata/en-US/release_notes.txt（iOS EN）、ja/release_notes.txt（iOS JA）、en-US/description.txt（App Store EN）、ja/description.txt（App Store JA）、promotional_text.txt、android/en-US/full_description.txt（Play Store EN）、ja-JP/full_description.txt（Play Store JA）、android/en-US/changelogs/default.txt（Play Store リリースノート EN）、ja-JP/changelogs/default.txt（Play Store リリースノート JA）。ファイルパスは apps/mobile/ からの相対パス。

設計書・ヒアリングシート・アーキテクチャ説明を多角的にレビュー：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 です。

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

別リポジトリ間の変更を効率的に同期：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で中止できます。

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

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

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 で成功、他は エラー報告を行います。

MulmoScript で作成した動画台本（JSON形式）から Markdown形式の Zenn記事を自動生成でき、手作業での変換作業を削減できます。 過去の Zenn記事テンプレートを参照して、フロントマター、:::message ブロック、見出し構成、動画リンク配置を自動で統一できます。 動画から生成された markdown をルール（div タグ除去、クレジット画像削除、画像パス変更、:::message 注釈追加）に基づいて自動編集し、Zenn記事として公開可能な形に整形できます。 YouTube URL が未登録の場合はプレースホルダーを記載してひとまず公開準備を進め、URL 受け取り後に記事ファイルと YouTube メタデータファイルの両方を一括更新できます。 /release-script 完了後のワンステップで、リリースノート用 Zenn記事を ZENN_CONTENT_DIR に自動出力できます。 動画コンテンツとテキストコンテンツを同時生成して公開したいコンテンツクリエイターやプロダクトチーム MulmoScript で台本管理をしており、Zenn への記事公開を自動化したいテクノロジー企業 リリースノートを動画と記事で同時配信するプロダクトマーケティング担当者 画像パスや リンク配置などの細かい編集ルールを統一して管理したいドキュメント編集チーム このスキルは MulmoScript（動画台本JSON）から Zenn 記事を自動生成・編集するワークフローです。 前提条件：docs/release_notes/v$ARGUMENTS/release_v_script.json が作成済み、YouTube URL が youtube_v_ja.md と _en.md に記録済み、環境変数 ZENN_CONTENT_DIR が設定済み（zenn-content リポジトリパス）。 Step 1: 環境変数確認：.env ファイルから ZENN_CONTENT_DIR を確認、未設定なら STOP してユーザーに設定依頼。 Step 2: mulmo markdown で原文生成：mulmo markdown docs/release_notes/v/release_v_script.json -o docs/release_notes/v/output/ を実行、release_v_script.md を生成。 Step 3: 過去記事をテンプレート参照：ls $ZENN_CONTENT_DIR/articles/*mulmocast-release*.md で最新記事を取得、フロントマター・:::message・見出し構成・動画リンク配置を参照。 Step 4: YouTube URL 取得：youtube_v_ja.md と _en.md から URL を抽出、未登録なら「（YouTube アップロード後に URL を追記）」をプレースホルダー。 Step 5: 記事編集ルール：(1)div タグ除去（タイトルスライドの # 見出しは残す、クロージングとその他は削除）、(2)mulmo_credit.png 参照行削除、(3)画像パス変更（/images/release_v_script/ファイル名.png）、(4):::message 注釈追加（フロントマター直後）。

ゴール文書を入力すると、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 全パス状態。