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

フォーマット修正・Lint修正・型チェック・ビルド・テストを自動実行し、コミット前にコード品質を確保できます。 各ステップの成功・失敗を順序通りに報告し、どこで問題が発生したか即座に把握できます。 フォーマットとLintの自動修正により、手動修正の手間を削減できます。 クイックモード（ビルド・テストスキップ）で、軽量なチェックも可能です。 PR作成前にコード品質を確認したいエンジニア TypeScript/JavaScriptプロジェクトで品質基準を保ちたい開発チーム DB関連のテストエラーを効率的に解決したいバックエンド開発者 5つのコマンドを順序通りに実行します：(1)pnpm format:fix（コードフォーマット自動修正）、(2)pnpm lint:fix（Lintエラー自動修正）、(3)pnpm typecheck（TypeScript型チェック）、(4)pnpm build（本番ビルド確認）、(5)pnpm test（ユニットテスト実行）。クイックモードはビルド・テストをスキップした3コマンド実行。エラー対応として、型チェックエラーはcd packages/db && pnpm buildで解決、DB関連テストエラーはdocker composeで対応、CI環境変数エラーは開発時は無視可能と定めています。

自然言語で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/配下に整理されています。

ユビキタス言語集を生成: ビジネスドメインで使用される専門用語を設計書とコードから抽出し、定義をまとめたドキュメント化。 アクター・ロール・権限を整理: システムに関わる人・役割・権限の関係を可視化し、認可ロジック（リファクタリング＝コードの整理・改善）と対応付け。 ドメイン-コード対応表を作成: 設計書の概念とコード上の実装を行ごとに紐付け、ドメイン理解を加速。 現行システム概要を文書化: 技術スタック、アーキテクチャ、モジュール構成を自動抽出し、新規開発者のオンボーディング資料に。 中間ファイルを逐次出力: 各ステップ完了時にすぐ結果ファイルを生成し、分析の進捗を可視化。 レガシーシステムをリプレイスまたはリファクタリングする開発チーム 既存システムの設計思想を新しいメンバーに学習させたい技術リーダー 設計書とコードの乖離を把握し、ドメインモデルを再構築したいアーキテクト マイクロサービス化やモジュール分割の検討時に現行構造を詳しく知りたい人 システム分析エージェントが既存システムの設計書とコードを分析し、ドメイン理解の基礎情報を抽出します。出力は reports/01_analysis/ ディレクトリに記載。Step 1 では mkdir でディレクトリ作成と対象スキャン、project-metadata.json 出力。Step 2 では設計書解析（ドキュメント読取、ビジネス用語抽出、アクター・ロール特定、機能・非機能要件整理）。Step 3 ではコードベース解析（mcp__serena__get_symbols_overview でシンボル一覧取得、ディレクトリ構造・名前空間・クラス・外部依存を観点に）、system-overview.md 出力。Step 4 ではユビキタス言語抽出（設計書の要件定義書・ER図・ユースケース、コードのクラス名・メソッド名・Enum値・コメント)、ubiquitous-language.md 出力。Step 5 ではアクター・ロール・権限整理（ユースケース図・認証コード・権限設定から）、actors-roles-permissions.md 出力。Step 6 では domain-code-mapping.md 出力（設計書概念とコード表現の対応表）。各ステップ完了時に即座にファイル出力すること。

シンプルな記述でコンテナを管理：Docker Composeより短い記述で、複数のコンテナを簡単に起動・停止・管理します。 local/dev/pre/live をステージで統一管理：環境に応じた異なる設定を1つのファイルで管理し、-sオプションで切り替えるだけで動作します。 ビルド・プッシュを自動化：Dockerfile からのビルドと、レジストリへのプッシュをコマンド1つで実行できます。 マルチアーキテクチャ・クラウド対応：--platformでARM/x86対応、さくらのクラウド・Cloudflareなど複数プロバイダーで動作。DNS自動管理もサポート。 Docker Composeより読みやすく、かつ環境を統一管理したい開発者 ローカル開発からクラウドデプロイまで、同じ設定ファイルで管理したい人 macOS（OrbStack）、Linux、クラウド環境など、複数の環境でコンテナを運用している人 CI/CDパイプラインで自動デプロイを実現したい人 FleetFlowはKDL Document Languageベースのコンテナオーケストレーションツール。コンセプトは「環境構築は対話になった。伝えれば、動く。」です。主要機能は超シンプルな記述、YAMLより読みやすいKDL構文、local/dev/pre/live のステージ管理、OrbStack連携、Dockerビルド、イメージプッシュ、クロスビルド（--platformでマルチアーキテクチャ対応）、サービスマージ、再起動ポリシー、依存サービス待機（Exponential Backoff）、さくらのクラウド・Cloudflareなど複数クラウドプロバイダー対応、DNS自動管理、CI/CDデプロイ、セルフアップデート、MCP対応、Playbookです。 インストールはcargo install --git https://github.com/chronista-club/fleetflow。最小構成例はproject、stage、serviceの記述でDB立ち上げが可能。基本操作はfleet up -s local（起動）、fleet ps（状態確認）、fleet logs（ログ表示）、fleet down -s local（停止・削除）。すべてのコマンドは-s/--stageオプションでステージ指定、または環境変数FLEET_STAGEで指定可能です。主要コマンドはup、down、deploy、ps、logs、start、stop、restart、build、validate、setup、play、cloud up、cloud down、mcp、self-update、versionがあります。

chrome-devtools-mcp を使用する際に、Chrome に拡張機能を読み込んで有効にした状態でテスト・デバッグできるように設定します。 別プロセスで拡張機能対応の Chrome を起動し、MCP との通信と独立して拡張機能の動作検証ができます。 コード変更後に Chrome を再起動せず拡張機能だけリロードでき、開発サイクルを高速化できます。 Chrome 拡張機能の開発・テストを MCP 環境で行いたい開発者 拡張機能の動作確認をスクリプトで自動化したい方 Playwright などのブラウザ自動化ツールで拡張機能をテストしたい方 このスキルは4つのステップで構成されます。Step 1 では拡張機能つきの Chrome を別プロセスで起動します。コマンドラインは --remote-debugging-port=9223（MCP の 9222 と被らないようする）、--user-data-dir=/tmp/chrome-ext-test（一時ディレクトリで既存プロファイルと分離）、--load-extension=/path/to/dist（ビルド済みフォルダパス指定）、--no-first-run、--no-default-browser-check を含みます。Step 2 で curl http://localhost:9223/json/version で Chrome の起動確認。Step 3 では Playwright で chromium.connectOverCDP('http://localhost:9223') で接続し、chrome://extensions/ にアクセスして拡張機能ID を確認、chrome.developerPrivate API で拡張情報を取得します。Step 4 では chrome.storage.sync.set() で設定を書き込み、対象ページをリロードして拡張機能動作確認。コード変更後はビルド後に拡張機能だけリロードすれば Chrome 再起動は不要です。

カスタマイズ支援（対話）: 「自動でlintしたい」「ファイル保存時に検証したい」などの要望に対し、最適な設定ファイルを作成・配置できる リファレンス自動更新: Memory、Skills、Subagents、Settings、Hooks、MCP、Plugins、ベストプラクティスなど8つのセクションを公式ドキュメントから最新版に一括更新 GitHub同期: カスタマイズ設定をGitHubリポジトリから同期し、常に最新の.claudeディレクトリを保つ 機能選択ガイド: 「何をしたいのか」に応じて、使うべき機能（Settings、Hooks、Skills、Agentsなど）と配置場所を自動判定 Claude Codeをさらに便利にカスタマイズしたい開発者 プロジェクトごとに異なる自動実行ルールを設定したい人 公式ドキュメントの最新情報を常に参照したい人 チーム全体で統一したClaudeの設定を運用したい人 このスキルは3つのサブコマンドで動作します。/cc-customで対話的にカスタマイズを支援し、/cc-custom update でリファレンスを更新します。セクション名は「memory」「skills」「subagents」「settings」「hooks」「mcp」「plugins」「best-practices」で、各々の出典URLが定義されています。更新時はWebFetchで最新情報を取得し、reference.mdの該当セクションを更新して「最終更新」日付を現在日に変更後、サマリーを報告。/cc-custom syncはGitHubリポジトリ（https://github.com/myuon/cc-custom）から.claudeディレクトリを上書き同期します。機能選択ガイドとして、やりたいことに応じてRules、Skills、Settings、Hooks、Subagents、MCP、Pluginsのどれを使うかの判定表と、プロジェクト用・個人用の配置場所テーブルが含まれています。

会計・経費・タスク・コミュニティなど多様な情報源（freee・GitHub・Discord）に対して、1つのクエリから必要な情報だけを並列で検索・取得できます。 クエリタイプを自動判定し（「売上は？」→freee優先、「PR数は？」→GitHub優先など）、各ソース別に最適なクエリに変換して同時実行します。 Discord Chrome自動操作はブラウザ起動が必要な場合のみ後続実行し、freee・GitHubの結果を先に返すため、レスポンス時間を短縮できます。 会計データ・開発タスク・コミュニティ情報を一度の質問で統合的に把握でき、ビジネス判断のための情報収集を効率化できます。 freee・GitHub・Discordを日常的に活用する個人事業主や小規模スタートアップの経営者 売上・経費・タスク進捗を一覧で確認し、日次・週次のビジネス状況判断を迅速に行いたい事業責任者 複数システムにまたがる質問（「未払経費と未クローズタスク」など）に素早く答える必要があるアシスタント・オペレーター GitHub Issues・freee・Discordチャンネルを横断的に検索して、組織全体の進捗を把握したいプロジェクト管理者 本事業所の利用可能ソースはfreee（MCP）・GitHub（gh CLI）・Discord（Chrome自動操作）の3系統。クエリタイプ別ソース選択テーブルで会計・経費→freee優先、開発費・工数→GitHub優先、コミュニティ→Discord優先など8パターンを規定。ソース別クエリ変換：freee は/api/1/deals（日付範囲取引）・/api/1/trial_balance（試算表）・/api/1/expense_applications（承認待経費）・/api/1/invoices（未入金請求書）；GitHub はgh issue list（キーワード・ラベル検索）・gh pr list（PR一覧）・gh api repos/.../milestones（進捗）・gh issue view（詳細）；Discord はmcp__claude-in-chrome__navigate（チャンネル移動）・mcp__claude-in-chrome__get_page_text（テキスト取得）・キーワード検索。freee・GitHub・Discordは独立しているため並列実行し、クエリ分解→並列実行→結果マージ・重複排除・統合回答。Discord Chrome操作はブラウザ起動が必要な場合は後続で取得。

現在のブランチの変更内容を自動分析し、テンプレートに従ったプルリクエストを作成できます。 変更ファイルのパスから自動的に「フロントエンド」「バックエンド」「ドキュメント」などの種別を判定します。 コミット履歴と変更内容から、適切なPRタイトルと本文を自動生成します。 アーキテクチャ規約への準拠状況をチェックリストで自動確認できます。 Simple Image Viewer プロジェクトの開発者で、PRを素早く作成したい人 プルリクエストのテンプレートを統一したいチーム コミット内容から自動的に変更種別を判定してほしい人 アーキテクチャ規約の準拠確認を自動化したい人 このスキルは Simple Image Viewer プロジェクト向けに、.github/pull_request_template.md に従ったプルリクエスト作成ワークフローを提供します。ブランチの差分取得（mcp_gitkraken_git_status、mcp_gitkraken_git_log_or_diff）から始まり、変更ファイルのパスを元に「フロントエンド（SolidJS）」「バックエンド（app/service/utils層）」「ドキュメント」「設定・ビルド」を自動判定します。タイトルは {type}: {概要} の形式で生成し、本文は概要・変更種別・変更内容・テスト方法・チェックリストの各セクションを埋めます。バックエンド変更時には「app層がservice経由で操作しているか」「service層がAppHandleを受け取っていないか」などのアーキテクチャ規約、フロントエンド変更時には「propsを分割代入していないか」「onCleanupでリスナーを解除しているか」などを自動チェックします。最後に git push と mcp_gitkraken_pull_request_create でプルリクエストを作成します。

ドキュメントの陳腐化を自動検出：README、tech.md、plan.mdなどが実際の開発状況と乖離していないかを自動判定し、最新化が必要な箇所を一覧化できます。 GitHub Issue との整合性を確認：オープン中のIssueや完了済みIssueが、プロジェクト計画ドキュメントに正しく反映されているか確認でき、計画と実装のズレを防げます。 コマンド・環境構成の正確性を保証：package.jsonのスクリプトやディレクトリ構成が実際に存在するか確認することで、セットアップ手順の実行エラーを事前に防げます。 プロジェクト全体の現況を可視化：複数のドキュメントから統一的に現状情報を抽出し、ステークホルダーに分かりやすく報告できます。 更新前に変更内容を明示：修正内容をユーザーに提示して承認を得てから実施するため、誤った情報削除を防げます。 複数のプロジェクトドキュメントを管理している技術リード・CTO プロジェクト進行状況をステークホルダーに定期報告するPM 新しい開発者のオンボーディング前にドキュメントを最新化したいチームリーダー プロジェクト Wiki や Confluence を常に最新状態に保ちたい組織 Steering ドキュメント更新は6ステップで進みます：（1）ls、cat、jqコマンドでパッケージ構成・スクリプト・ディレクトリ構成を把握、（2）mcp__github__list_issues・mcp__github__search_issuesでオープンイシューとクローズ済みイシューを確認、（3）README.md、product.md、tech.md、plan.md、work.md、structure.mdの6ファイルを読み込んで実態と比較、（4）陳腐化箇所を表形式で報告、（5）修正内容をユーザーに提示して承認取得、（6）承認後にMultiEditで一括修正してコミット。確認ポイントはファイルごと（README の セットアップ動作性、tech.md のバージョン正確性、plan.md の完了状態、structure.md のディレクトリ存在確認、Issue との整合性）に整理され、product.md は設計意図として扱う一方、work.md は変更を慎重に行う注意事項が記載されています。

ブログ記事のドラフトを解析し、kinako-mocchi MCP（Gemini画像生成）でOGP画像・解説図を自動生成します 記事内の `` コメントから画像位置と種別（architecture/flow/concept/comparison）を自動抽出し、各セクションに適切な図を生成します 記事構造がない場合は3〜5枚のテーマに合わせた図を自動で計画し、プロンプト生成から画像挿入まで一括実行します hero画像・システム構成図・処理フロー図・概念図など、テーマに応じた統一スタイル（白/薄灰色背景、青・スレート・翠緑の配色）の図を生成します ブログ記事執筆者（挿図作成の時間を大幅削減） 技術ドキュメント作成者（システム構成図・フロー図を自動生成） kinako-mocchi MCPが設定された環境を持つユーザー 記事の視覚的わかりやすさを上げたい執筆チーム このスキルは3つのPhaseで構成されます。Phase 1（環境確認） では .claude/skills/generate-article-images/references/KINAKO_MOCCHI_MCP.md をReadで読み込み、MCPサーバーが .mcp.json に設定済みであることを前提とします。Phase 2（記事分析と画像プラン） では対象ファイル（$ARGUMENTS未指定時は最新の drafts/draft-*.md）をReadで読み込み、frontmatterからタイトル・slug を抽出、H2/H3見出しと IMAGE_SLOT コメントの位置を特定します。IMAGE_SLOT がある場合は各コメントから type/種別名/内容説明を抽出、ない場合は記事構造から3〜5枚の画像を自動計画（hero 1枚＋解説図2〜3枚）します。Phase 3（プロンプト生成と画像生成） では、全画像に共通のsystem_prompt（フラットデザイン・ミニマリスト・テキスト厳格管理）を適用し、テキスト要素を多めにリストアップしてから各画像のプロンプトを生成します。mcp__kinako-mocchi__generate_image ツールで画像を生成し、Editで記事に挿入します。画像種別の選定は「システム構成→architecture」「処理手順→flow」「抽象概念→concept」「比較→comparison」の基準に従います。

マージ済みPRを自動検出してIssueをクローズ: PR body に「Closes #N」「Fixes #N」などの指定がある場合、マージ後に対応する Issue を自動でクローズできます。 実装状況を4段階で分類・レポート: クローズ対象（マージ済みPR）、進行中（オープンPR）、未着手、実装済み（CLAUDE.md） の4段階で Issue の現状を自動判定し、テーブル形式で視覚化できます。 CLAUDE.md のチェックリストと連動: Issue 完了状況と CLAUDE.md の実装済み「[x]」「[ ]」を対比し、食い違いがあれば自動更新できます。 依存関係のある Issue も一括管理: マージ済みPRで複数の Issue がクローズされる場合、確認・修正・報告を一度のコマンドで完了できます。 プロジェクトマネージャー: 実装進捗を Issue トラッキング上で正確に保ちたい。手作業でのクローズ作業を自動化したい。 エンジニア: PR マージ後、関連 Issue の状態更新を忘れずに一括実行したい。 チームリード: 複数メンバーの PR をレビューするときに、関連 Issue の状態を一括チェック・同期したい。 スクラムマスター: スプリント終了時に、完了した Issue と未完了の Issue を自動で分類し、レトロスペクティブの準備ができます。 同期は以下の手順で実行されます。①情報収集段階で、mcp__github__list_issues（state=open, closed）、mcp__github__list_pull_requests（state=closed, open）、CLAUDE.md の TODO セクションを並列取得します。②同期判定段階で、各オープン Issue について「マージ済みPRが body に Closes #N を含むか」「CLAUDE.md で [x] 済みか」「オープンPRが存在するか」「上記いずれでもない（未着手）か」を判定します。③同期実行段階で、mcp__github__update_issue で state=closed に変更し「Closed by PR #N」コメントを追加、CLAUDE.md も更新します。④結果報告は Issue# ・タイトル・状態・アクション列でテーブル表示します。クローズ対象が見つかった場合は実行前にユーザーに確認し、CLAUDE.md の変更は TODO チェックマーク更新のみ最小限にとどめます。

GitHub issue、PR、リポジトリ操作を、利用可能なツール（gh CLI、MCP、curl）から最適な方法を自動選択して実行できます。 gh CLI環境では高速で直感的な操作が可能、MCP経由ではAIエージェントとの統合が容易、curl フォールバックでは環境制限下でも動作するなど、環境の制約に柔軟に対応します。 認証トークン（GITHUB_TOKEN）の自動検出により、認証ありと認証なしの処理を自動で振り分け、セキュアかつシームレスな操作を実現できます。 リポジトリ情報を git remote から自動取得するため、手動でのオーナー・リポジトリ名指定が不要になります。 複数の環境（ローカル開発、CI/CDパイプライン、リモートサーバー）でGitHub操作を統一したい開発者 AIエージェント統合でGitHubワークフローを自動化したい技術チーム gh CLIが利用できない制限環境でも確実にGitHub連携を実現したい人 issue・PR管理を スクリプト化・自動化したい DevOpsエンジニア このスキルはフォールバック戦略で GitHub 操作を実行します。優先順は（1）gh CLI（まず gh --version で利用確認、コマンド未検出または認証エラーで次へ）、（2）MCP ツール（mcp__github__* ツール群：list_issues、get_issue、create_issue、list_pull_requests、get_pull_request、create_pull_request、search_repositories等、応答なしまたはエラーで次へ）、（3）curl + GitHub REST API（最終手段、環境変数 GITHUB_TOKEN で認証付きリクエスト、未設定時は認証なし）です。curl での例としてリポジトリ取得、issue一覧・詳細・作成、PR一覧等のコマンドを記載。フロー図では gh --version 実行 → MCP試行 → git remote から取得してcurl実行という段階的フォールバックを示します。Rate limit は認証なし 60 req/hour、認証あり 5,000 req/hour、書き込み操作は GITHUB_TOKEN 必須です。

レビューコメントの自動一覧化: GitHub APIでPRの未解決コメントをすべて取得し、ファイル・行番号・内容をわかりやすく整理できます。 修正の優先度を自動判定: バグ修正・セキュリティ改善は推奨、設計判断はスキップ、トレードオフはユーザーに確認するなど、判断基準に基づいて分類できます。 修正内容を一括実行: ユーザーの承認を得た修正だけを自動で適用し、複数ファイルの編集をまとめてコミット・プッシュできます。 レビュワーへ対応結果を自動返信: 修正した項目・スキップした項目それぞれに理由付きで返信し、やり取りを記録に残せます。 レビュー指摘の対応に時間をかけたくない開発者: どの指摘に対応すべきか自動判定され、手作業を減らせます。 複数のPRレビューを抱えているコードレビュアー: レビューコメントの一覧化と対応状況の自動追跡で、フォローアップ漏れを防げます。 チームのレビュー品質を高めたい人: 修正理由をコメント返信で説明することで、暗黙知が形式知に変わります。 リモート・非同期チームで働く人: 口頭での「確認しておいて」が減り、コメントに記録が残ります。 mcp__github__pull_request_readで未解決レビューコメント（is_resolved: false）をスレッド取得し、各コメントの内容を要約してユーザーに提示します。判断基準は「修正推奨（バグ・セキュリティ・UX改善・テストカバレッジ拡充）」「修正不要（ユーザー決定事項・プロジェクト方針違い・過剰な将来対応）」「要確認（トレードオフ・設計判断）」の3段階。ユーザー承認後、承認された項目を修正して一括コミット・プッシュし、mcp__github__add_reply_to_pull_request_commentで各レビューコメント（commentId指定）に修正内容または理由を返信。修正返信は「ご指摘ありがとうございます。○○を△△に変更しました」、スキップ返信は「ご提案ありがとうございます。△△の理由から現状維持します」の形式で返信し、最後に「修正X件・スキップY件でよいですか？」と確認します。

Linear Issue の内容を自動読み込みして、ドキュメントのセクションを新規作成できます ブランチ作成からコミット、PR作成まで一気通貫で実行し、手作業を大幅削減できます ソースコードを直接参照しながら、正確なドキュメントを自動生成します mkdocs のナビゲーション設定を自動更新し、ドキュメント体系を整えます 作成後は Issue のステータスを自動更新し、進捗管理も効率化できます ドキュメント執筆を効率化したい技術ライター・ドキュメント担当者 Issue ベースで系統的にドキュメントを管理したい開発チーム Markdown と Git ワークフローで協働するプロジェクト管理者 ドキュメント品質を保ちながら執筆スピードを上げたい組織 /implement コマンドで Linear Issue に基づくドキュメント執筆をワンステップで実行します。処理フローは以下の通り： 1. mcp__linear-server__get_issue で Issue 詳細を取得し、ステータスを「In Progress」に更新 2. feat/- 形式でブランチを作成 3. ソースリポジトリ（src-ref/）から MCP ツール定義、CLI フラグ、設定構造、プロトコル実装などの正確な情報を収集 4. Issue の「ページ構成」に従ってドキュメントを執筆し、CLAUDE.md の執筆規約に従いながらコード例をソースから正確に記述 5. mkdocs.yml の nav セクションに新ページを追加し、mkdocs build で検証 6. Conventional Commits 形式でコミット（docs(): add section）してプッシュ、gh pr create で PR を作成 7. Issue ステータスを「In Review」に更新して完了報告 画像が必要なページはプレースホルダーを残し、5ページ以上の大規模セクションは index.md を先に執筆してから個別ページを作成します。

Playwright MCP（ブラウザ操作ツール）を使用して kintone アプリのレコード作成・編集・削除、検索・絞り込み、カスタマイズ機能などを自動テストできる ブラウザを遠隔操作してログイン、アプリ移動、フォーム入力、ボタンクリックなどの一連の操作をテストし、画面表示やデータ整合性を検証できる テスト結果をスクリーンショット付きで報告し、発見した問題点を明確に整理できる KINTONE_URL、KINTONE_USER、KINTONE_PASSWORD などの認証情報を .env から自動取得し、手動設定を最小化できる kintone カスタマイズ後に、CRUD（作成・読取・更新・削除）機能が正常に動くか確認したい人 検索・フィルタ、集計値、ルックアップなどのロジック検証を自動化したい人 ダークモード対応やレイアウト変更が既存機能を壊していないか確認したい人 定期的に同じテスト手順を繰り返す必要があり、手作業を減らしたい人 Playwright MCP を使用して kintone アプリの E2E テストを実行。事前に .env ファイルから KINTONE_URL/KINTONE_DOMAIN、KINTONE_USER/KINTONE_USERNAME、KINTONE_PASSWORD を取得し、テスト対象アプリID を確認（URL https://{domain}.cybozu.com/k/{APP_ID}/ から取得）。テスト実行フロー：ブラウザで kintone にアクセス → ユーザー名・パスワード入力でログイン → 対象アプリへ移動 → テスト実行。テスト種類は、レコード操作（作成・編集・削除・検索）、画面表示（一覧・詳細・フォーム・グラフ・ビュー）、データ整合性（集計値・参照・計算フィールド・ルックアップ）。Playwright MCP コマンド例：mcp__playwright__browser_navigate（URL移動）、mcp__playwright__browser_snapshot（画面取得）、mcp__playwright__browser_click（クリック）、mcp__playwright__browser_type（テキスト入力）、mcp__playwright__browser_fill_form（フォーム一括入力）、mcp__playwright__browser_take_screenshot（スクリーンショット）、mcp__playwright__browser_wait_for（待機）、mcp__playwright__browser_select_option（ドロップダウン）。テスト完了後に実行内容、成功/失敗、エラー詳細、改善提案を報告。

Pull Requestのレビューコメントをまとめて確認し、修正すべき項目とスキップできる項目を自動判定・提示できます。バグ修正やセキュリティ改善など推奨される指摘と、設計方針の違いなどスキップしてよい指摘を区別して、対応方針を提案します。 レビューコメント一つずつについて「修正推奨/不要/要確認」の判定理由を明示し、ユーザーが最終確認してから修正を実行するため、レビュー対応の漏れや誤った修正を防げます。 承認されたコメントだけを対象に自動修正を実行し、修正内容をコミット・プッシュまで一括処理するので、手作業の修正作業を省略できます。 修正完了時に「X件修正、Y件スキップ」とまとめて報告し、PR更新状況が一目でわかります。 開発チームのメンバー：Pull Requestのレビュー指摘に効率よく対応したい プロダクト開発者：バグ修正やセキュリティ指摘への対応漏れを防ぎたい コードレビュアー：チームメンバーが指摘に確実に対応したか確認したい スタートアップ・小規模チーム：レビュー対応を自動化して開発速度を上げたい mcp__github__pull_request_read の get_review_comments 実行により未解決コメントを取得。各コメントを要約してユーザーに提示し、修正の要否を判定（推奨/不要/要確認）し理由を説明。修正推奨：バグ修正、セキュリティ改善、アクセシビリティ改善、明らかなUX改善、カバレッジ不足（60%未満）の単体テスト拡充。修正不要：ユーザーが明示的に決定した設計、プロジェクト方針と異なる提案、過剰な抽象化・将来対応の提案。要確認：トレードオフがある変更、設計判断が必要な変更。修正推奨・要確認項目をまとめてユーザーに提示し承認を得る。承認された項目のみ各ファイルを編集（Edit/MultiEditツール使用）。修正内容をコミット・プッシュして PRブランチに反映。最後に「まとめ: X件修正、Y件スキップでよいですか？」と確認。

現在のブランチ内容を自動確認し、未コミット変更がないか、どんなコミットがあるかを把握できるため、PR作成前の確認漏れを防げます ブランチをリモートに自動プッシュできるため、PR作成の前準備を手動で行わなくて済みます PR テンプレートを自動読み込み、ボディ内容を構造化できるため、テンプレート形式に沿ったPRが素早く作成できます 作成後のPR本文を自動検証し、改行エスケープなどの形式エラーを検出できるため、見た目の悪いPRを防ぐことができます PR URLを自動で報告してくれるため、確認作業がシンプルになります GitHubでコードレビューを受ける開発者全般 PR作成時のテンプレート確認が手間と感じている人 GitHub CLIを活用したワークフローで効率化したい人 PR作成後の本文形式エラーを事前に防ぎたい人 PR作成スキルは6つのステップで構成されます。(1)git statusでコミット確認、git log・git diffで変更内容確認、(2)リモートにプッシュ、(3).github/PULL_REQUEST_TEMPLATE.mdを読み込み、(4)mcp__github__create_pull_requestでPR作成（タイトル・ボディは改行エスケープなしで記載）、(5)gh pr view --json bodyでPR本文を取得し改行エスケープ確認・問題時はmcp__github__update_pull_requestで修正、(6)PR URLを報告。ボディは「目的」「変更概要」セクションで構成、コミット済みの確認後に進め、masterへの直接プッシュを避け、PR タイトルは日本語50文字以内推奨。許可ツールはRead・Glob・Bash(git系)・GitHub CLI・update系MCPです。

未コミットのマークダウンファイルを自動検出：git statusから新規追加・変更されたファイルを自動で見つけて処理対象にします。 WebサイトとYouTube両対応：記事やブログ、YouTubeの動画など、URLの形式に応じて最適な方法でコンテンツを取得します。 構造化された要約を自動生成：取得したコンテンツを、概要・主要トピック・結論などの構造に整理して要約を作成します。 事実確認と補足情報を追加：生成した要約を確認し、重要な情報が正確か検証したうえで、必要な補足情報を追加します。 記事やYouTube動画を定期的にまとめて、デジタルノートを作成したい人 Webコンテンツを読むとき、要点を素早く把握できるまとめが欲しい人 複数のWebページや動画から情報を集約して、社内報告用に整理したい人 本スキルは5段階のフェーズで動作します。 Phase 1: ファイル検出では、git statusでUncommittedなmdファイルを検出し、frontmatterのsourceURLを抽出。URLがない場合はスキップします。複数ファイルがある場合はユーザーに確認します。 Phase 2: コンテンツ取得では、YouTubeのURL（youtube.com/watch?v=xxx、youtu.be/xxxなど）とWebページを判定。YouTube文字起こしAPI（mcp__youtube-transcription__get_transcript）またはFirecrawl/WebFetchを使用してコンテンツを取得します。 Phase 3: 要約生成では、取得したコンテンツからメタデータ（著者・公開日など）を補完し、構造化された要約を生成します。 Phase 4: レビューでは、生成した要約に対して事実確認と補足情報を追加します。 Phase 5: ユーザー確認では、AskUserQuestionでユーザーに確認後、ファイルを更新します。使用タイミングは、新しいclippingファイルの要約、動画・記事のノート作成、既存ノートへの要約追加です。

Python SDK と FastMCP フレームワークを使用して、Model Context Protocol (MCP) サーバーを新規作成できます。 ツール・リソース・プロンプトを FastMCP のデコレータで簡潔に実装し、LLM が利用できるカスタム機能を提供できます。 Pydantic モデルを活用した型安全な実装で、複雑なデータ構造を明確に定義・返却できます。 STDIO および HTTP トランスポートを設定でき、異なる環境（ローカル / クラウド）に対応できます。 MCP Inspector を用いたテスト・デバッグで、実装したツールやリソースの動作を確認できます。 Python でカスタム LLM ツール・プラグインを作成したい開発者 既存のバックエンド API や DB にアクセスするMCPサーバーが必要なエンジニア FastMCP の簡潔なデコレータ構文を使って迅速にプロトタイピングしたい人 型安全性と保守性を重視した Python 開発を実践したいチーム このスキルは Python SDK と FastMCP フレームワークを使用した MCP サーバー構築の完全なガイドです。開発環境セットアップは uv init と uv add "mcp[cli]" で実施。pyproject.toml では依存関係（mcp、pydantic など）と開発依存関係（pytest、pytest-asyncio）を定義します。ツール実装は FastMCP の @mcp.tool() デコレータを使用し、型ヒント付きの Python 関数として記述。基本的なツールから Pydantic モデルを使用した構造化出力（WeatherData など）、さらに Context を使用した非同期・ロギング対応の高度なツールまで実装できます。各ツールは Args と Returns に詳細説明を記載し、LLM が理解しやすくします。リソース実装は リソースの取得・更新・リスト表示に対応。プロンプト実装は predefined や dynamic 形式で LLM に高度な指示を提供。STDIO（ローカル実行）と HTTP トランスポート（サーバー公開）の設定をサポート。MCP Inspector による対話型テストで実装検証。