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）の対応パターンを一覧で管理します。

新しくリリースされた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 作成が完了したら終了。

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/ からの相対パス。

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。

リリース前の検証（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参照。

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 検証あり。

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

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 全パス状態。

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 バージョン変更時はファイルパス確認に注意。

Steel.devクラウドブラウザを使い、実ユーザー視点でWebアプリを自動テストし、バグを検出できます。 ページレンダリング、リンク・フォーム機能、エッジケース（空入力、特殊文字、ネットワーク遅延）、JavaScriptエラーを包括的にチェックできます。 検出したバグをCritical/High/Medium/Lowに分類し、Tier（Quick/Standard/Exhaustive）に応じた自動修正ループで品質を向上させます。 テスト実行から修正検証までのワークフローを自動化し、Paperclip Heartbeatで定期的にQAを実行できます。 Web アプリケーション開発チームの品質保証（QA）担当者 継続的デリバリーで定期的な自動テストが必要なスタートアップやSaaS企業 ブラウザの互換性確認やレイアウト崩れ検出を自動化したいフロントエンド開発チーム バグ検出から修正検証までを効率化したいプロダクト開発チーム Dev QA（Browser Testing & Bug Fix Agent）は、Steel.dev クラウドブラウザAPI を使い、Paperclip Heartbeat上でWebアプリを実ユーザー視点でテストします。 環境変数STEEL_API_KEY、PAPERCLIP_API_URL/KEY、COMPANY_ID、RUN_IDを設定後、Heartbeatフローは以下の通り：割り当てIssueを取得 → テスト対象URL・スコープを抽出 → ブラウザセッション作成 → テスト実行・バグ検出・修正・再検証 → レポートをIssueコメントに投稿 → セッション終了。 Steel.dev API操作は、POST /sessions でセッション作成（CDP_URL取得）、POST /actions/navigate でページ遷移、GET /actions/screenshot でスクリーンショット取得、DELETE /sessions でセッション終了。テストプロセスは、IssueからTarget URL・Scope・Tier を抽出。テスト実行ではレンダリング（HTTP 200、レイアウト、モバイル表示）、インタラクション（リンク・フォーム・ボタン・連打耐性）、エッジケース（空入力・特殊文字・遅延・戻る）、コンソール（JSエラー・ネットワークエラー）をチェック。バグをCritical/High/Medium/Low に分類し、Tier別に修正範囲を決定します。

プルリクエストの作成・管理を高速化 — ghコマンドでPRの作成、確認、編集をターミナルから一括実行でき、ブラウザを往復する手間が減ります。 コンフリクト（競合）の解決フロー — マージ時に発生したコードの競合を、ステップバイステップで確認・解決し、安全にマージできます。 Issue管理も同じツールで統一 — Issue作成・確認・クローズもコマンドラインから行え、GitHub操作全体をスムーズに。 PR情報をJSON形式で取得・確認 — マージ可能状態、レビューステータス、CI/CDの状態などを詳細に確認し、問題の早期発見ができます。 実装からマージまでの実践的な流れ — ブランチ作成→コミット→PR作成→マージまで、実例付きで全プロセスを標準化できます。 開発エンジニア — 毎日複数のPRを作成・レビューする人で、GitHub操作を高速化したい方。 チームリード — チームメンバーのPRレビューを効率化し、マージ作業をスムーズにしたい方。 Git初心者からの脱却を目指す人 — GUIではなくコマンドラインで自信を持ってGitHub操作をしたい方。 コンフリクト解決に不安がある人 — マージ時のコンフリクトに直面したとき、体系的に対応できるようになりたい方。 GitHub CLIの認証確認（gh auth status）から始まり、プルリクエストの作成・確認・編集（タイトル、説明、ラベル、レビュアー追加）の操作方法を網羅します。コンフリクト解決は4ステップで構成：(1)マージ可能状態の確認、(2)mainブランチのマージ、(3)競合ファイルの特定、(4)マーカー削除後のコミット・プッシュ。Issue操作（作成・一覧・確認・クローズ）も含まれます。JSONクエリを使用したPR情報取得（title、body、state、mergeable、files、reviewDecision、statusCheckRollup）、および「PR作成からマージまで」と「コンフリクト解決」の2つの実践例を提供し、実装フローを具体的に示します。

既存システムの分析結果をもとに、ScalarDB Clusterを用いた分散トランザクション対応のデータアーキテクチャ全体を設計します。複数のマイクロサービス間で一貫性のあるトランザクション処理を実現する方式を策定します。 クラスター構成やストレージバックエンド（PostgreSQL、DynamoDB、Cassandraなど）の選定、テーブル設計、パーティションキー・クラスタリングキーの最適化を含むスキーマ設計を提供します。 Sagaパターンなど分散トランザクション戦略、マイクロサービス間のデータ連携方針を立案します。 既存DBからの移行戦略とマイグレーション計画も含めた実装ロードマップを策定します。 マイクロサービスアーキテクチャへの移行を検討しており、分散トランザクションの複雑さに直面しているアーキテクト・エンジニア 複数の異種DBシステムを統一的に管理し、データの一貫性を保ちたいシステム設計者 スケーラビリティとトランザクション保証の両立を実現したい大規模システムの開発チーム HTAP（トランザクション＆分析処理の融合）アーキテクチャの構築を検討している企業 ScalarDB ClusterはgRPCベースの集中型トランザクションコーディネーターで、異種DBs間の分散トランザクションを実現するエンタープライズ向けHTAPプラットフォームです。設計対象は（1）クラスターアーキテクチャ（ノード構成、HA構成、ストレージバックエンド選定）、（2）スキーマ設計（テーブル設計、パーティション・クラスタリングキー、セカンダリインデックス）、（3）トランザクション設計（分散トランザクション戦略、Sagaパターン、コンシステンシーモデル）、（4）マイグレーション計画です。前提条件として、01_analysis配下の分析結果と03_design/target-architecture.mdが存在すること。アーキテクチャは、Application Layer（複数サービス）→ScalarDB Cluster（トランザクションコーディネーター3ノードのHA構成）→Storage Layer（PostgreSQL、DynamoDB、Cassandra等）という3層構成です。

ファイル変更を「論理的な変更単位」ごとに自動分類し、各グループのコミットメッセージ案を提示できます。 ユーザーの承認後、グループごとにファイルをステージして順番にコミットを実行し、変更履歴を整理できます。 コミットメッセージに作成者情報を自動付与し、CLAUDE.mdのコミットルール「1コミット = 1つの論理的な変更単位」に従った履歴を作成します。 Gitの変更履歴を見やすく整理し、後から参照しやすくしたい開発者 複数ファイルの変更を複数コミットに分け、各コミットの意図を明確にしたい人 コミット漏れや誤ったコミットを防ぎ、リポジトリ品質を保ちたい人 章・セクション・機能ごとに変更を論理的にグループ化したい人 コミットルール「1コミット = 1つの論理的な変更単位」に従い、変更をグループ分けしてコミット。Step 1でgit status・git diff・git logを実行して全変更を把握。Step 2で変更ファイルを章・セクション・機能単位でグループ化（基準：章・セクション執筆、進捗管理、セッションログ、スタイルガイド、サンプルコード、図・画像等）。Step 3でテーブル形式でグループ分け結果を提示しユーザー承認取得。Step 4で各グループを順番にgit add（ファイル個別指定）→HEREDOCでgit commit（プレフィックス：docs/feat/fix/chore等、日本語または英語、1行目70字以内推奨、Co-Authored-Byで作成者付与）。Step 5でgit log --onelineで全コミット一覧を表示。

コンテキストから最適なフォーマットを自動選択：障害・バグ・設計・企画など事象の種類を判定し、4F形式（事実・原因・対応・再発防止）またはSTAR形式（状況・課題・計画・成果）を自動選択して起票します。 既存Issueとの重複をチェック：起票前にキーワード検索で重複がないか確認し、既存Issue がある場合はコメント追加を提案します。 優先度・ラベルを自動判定：P0（本番障害）、P1（開発支障）、P2（改善）、ラベル（troubleshooting / planning / design / knowledge）を自動で付与します。 トラブルシューティング完了時に自動起票：Claude Codeのエージェント作業中に問題が解決したら、その知見を自動的にIssueとして記録できます。 開発チーム全体：バグ報告、設計議論、技術調査の結果を一元管理したい人 プロジェクトマネージャー：タスクの状態把握と優先順位付けを効率化したい人 テクニカルリード：解決済みのトラブルを組織的なナレッジ資産に変えたい人 AIエージェント連携開発者：自動化したトラブルシューティング結果をすぐにIssue化したい人 このスキルはコンテキスト分析、フォーマット自動選択、重複チェック、起票、プロジェクト追加の5ステップで動作します。コンテキスト分析では事象の種類（障害/バグ/企画/検討）、時制（過去/未来）、ラベル、優先度を判定します。4F形式は既発生の障害・バグ・調査結果に、STAR形式は未来の機能検討・設計議論・アップグレード計画に、フリーフォーマットはナレッジ共有・議論の記録に選択します。gh issue list コマンドで重複確認し、重複がなければ gh issue create で起票、gh project item-add でプロジェクトに追加します。トラブルシューティング自動起票ルール では、Claude Code エージェント作業中に問題が解消したら自動的に /issue を実行し、作業コンテキスト（エラー内容、原因、修正内容）から4F形式でIssueを生成し、ユーザー承認後に起票します。

評価駆動開発の実装: 実装前に期待される動作を評価として定義し、開発中に継続的にテストを実行して品質を確保できます。 能力評価とリグレッション評価の自動実行: Claudeが新しくできるようになったことをテストする一方、既存機能が壊れていないことを同時に確認できます。 複数の評価方法を組み合わせ: コード内の決定論的チェック（Grep、ビルド確認）、AIによる自由形式評価、人間のレビューフラグを柔軟に組み合わせられます。 pass@kメトリクスで信頼度を数値化: 「k回の試行で成功」という形式で実装の安定性を定量的に測定できます。 評価レポートを自動生成: 能力評価、リグレッション評価、メトリクスをまとめた詳細レポートで進捗を可視化できます。 Claude Codeを使ってAIに実装させる開発者・プロダクトマネージャー テスト駆動開発（TDD）の考え方を好む人 AI生成コードの品質が不安な人、安定性を重視する人 変更ごとにリグレッション（機能低下）がないか追跡したい人 eval-harness は「評価駆動開発（EDD）」の原則を実装するフレームワークです。能力評価（チェックリスト形式で期待される動作を定義）とリグレッション評価（既存機能の動作確認）の2種類の評価タイプを提供します。評価方法は3種類：(1)コードベース評価者（Grep、テスト実行などの決定論的チェック）、(2)モデルベース評価者（Claudeが自由形式で出力を評価）、(3)人間評価者（手動レビュー）です。メトリクスとしてpass@k（k回試行で1回以上成功）およびpass^k（k回全て成功）を使用。ワークフローは4ステップ：定義（コード前に評価項目を記述）→実装（評価に合格するコードを作成）→評価実行→レポート生成。詳細なレポート形式とテンプレートが用意されています。

Luaスクリプトとシェーダーコードを組み合わせて、OBS（配信ソフト）用の映像エフェクト（ぼかし、色調変更、モザイク、歪みなど）を自動生成できます。 「フィルター追加」「〇〇エフェクトを実装して」といった指示から、動作するプラグイン一式（Luaスクリプト、シェーダー、ドキュメント）をまとめて作成できます。 プラグイン内のパラメータ（エフェクトの強さなど）を調整できる仕組みも含めて実装されます。 配信者で、OBSにカスタムエフェクトを追加したい方 ライブ配信用のビジュアル演出を自動化したい制作チーム エフェクトプラグインの開発経験がないが、簡単に作成したい開発者 Lua・シェーダーの細かい文法を気にせず、機能実装に集中したい方 OBSフィルターはLuaスクリプトとシェーダーコード（GLSL）で構成されます。実装手順は以下の通りです： 1. ディレクトリ構成: scripts/{filter-name}-filter/ 配下に、{filter-name}-filter.lua とシェーダーファイルを配置 2. Luaスクリプト基本構造: obs モジュールをインポート後、フィルター定義オブジェクト（source_def）を作成。フィルター名取得（get_name）、生成（create）、削除（destroy）、ビデオレンダリング（video_render）などのコールバックを実装します。シェーダーパラメータ（resolution_x、resolution_y、カスタムパラメータ）を gs_effect_get_param_by_name で取得し、レンダリング時に渡します。 3. シェーダーの役割: 実際のピクセル変換処理はGLSLシェーダーで実装。入力の解像度・カスタムパラメータを受け取り、出力画像を生成します。 4. 登録: obs.register_source(source_def) でOBSに登録し、UI上から「フィルター追加」で選択可能にします。