Skill.md検索

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

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完了、コード実装済み、解析エラーなし、テスト通過、計画更新済みです。

iOS・macOS・watchOSなどAppleプラットフォーム向けのUIを、Apple Human Interface Guidelines(HIG)に自動準拠させて設計できます マージン・スペーシング・グリッド・タイポグラフィ・カラーなど、プラットフォーム別の厳密な仕様に基づいて設計できます Dynamic Type対応やダークモード対応など、ユーザーアクセシビリティに配慮した設計が実装できます Navigation Bar・Tab Bar・Buttons・Lists・Cardsなど、標準コンポーネントの正確な仕様（寸法・色・配置）がすぐに参照できます SF Symbols を活用したアイコン設計を、統一的なガイドラインで実行できます iOS・iPadOS・macOS向けアプリのUIデザインを行うUI/UXデザイナー Appleプラットフォーム開発初心者で、デザインシステムの標準的な仕様を学びたい開発者 複数Appleプラットフォーム（iPhone・iPad・Mac・Watch・TV）で一貫性あるUIを構築したいプロダクトチーム ユーザーのアクセシビリティニーズに配慮したアプリ設計を実装したいプロダクトマネージャー Apple Human Interface Guidelines(HIG)に準拠した洗練なUIデザイン作成スキルです。核心原則は明瞭性（すべてのサイズで読みやすく、装飾は適切）、敬意（UIはコンテンツを補助）、奥行き（レイヤーと動きで階層表現）です。iOS/iPadOS：セーフエリア8pt基本グリッド、マージン最小16pt、Dynamic Type対応フォント（San Francisco）、14段階のテキストスタイル、セマンティックカラー+ダークモード対応が必須。Navigation Bar高さ44pt（コンパクト）/96pt（ラージ）、Tab Bar高さ49pt、ボタン最小タップ領域44x44pt、リスト行最小44pt、カード角丸12pt/16ptが標準。macOS：ウィンドウ最小800x600pt、ツールバー高さ52pt/76pt、サイドバー幅150-250pt、ボタン高さ22-32pt。watchOS：マージンプラットフォーム別に設定。各プラットフォーム仕様が詳細に定義されています。

記事やプレゼン、ドキュメントなど、あらゆるコンテンツの「伝えたいこと」を対話しながら整理できます。 読者のペルソナ（誰に向けた内容か）と期待するアクション（読後にどうしてほしいか）を明確にし、ブレない構成を作ります。 複数の構成案を提案してもらい、その中から選びながら進められるので、自分の考えが反映された構成になります。 各セクションの内容を一緒に詰めながら、順番や強調点も調整できます。 実際の執筆は行わず「構成案の確定」までなので、重い腰を上げずに気軽に相談できます。 ブログ記事やホワイトペーパーを書く前に、「何を書くべきか」を整理したい人 プレゼン資料を作る前に、筋の通った話の流れを決めたい営業・企画担当者 社内向けドキュメントやマニュアルの構成を検討している業務効率化担当者 「伝えたいことはあるけど、どう構成すればいいか迷っている」という悩みがある人 対話的に進める方式で、以下4つのフェーズから構成されます。フェーズ1: 目的ヒアリングでは、①誰に向けた内容か（読者・聞き手のペルソナ）②読後/聞いた後にどんなアクションを起こしてほしいか、の2点を必ず確認します。フェーズ2: 素材ヒアリングでは、伝えたいことを自由に話してもらい、不足情報や曖昧な点を質問で深掘り、最後に「他に伝えたいことはありますか？」で漏れを確認します。フェーズ3: 構成案ヒアリング（対話的に）では、大まかな構成の方向性を2〜3案提案してフィードバックをもらい、選ばれた方向性で各セクション内容を詰めていき、順番や強調点を調整しながら「この構成でいいですか？」と確認を取ります。フェーズ4: 構成案確定では、目的・対象読者・期待するアクション・セクション構成をMarkdown形式で整理して提示します。重要な原則として、一方的に提案せず常にフィードバックをもらいながら進める、ユーザーの表現をそのまま活かす、実際の執筆は行わないことが強調されます。

音声入力の文字起こしテキストを自動修正・補完し、完成度の高いブログ記事として仕上げることができます。 技術用語やサービス名を自動調査し、正確な情報を記事に反映させ、信頼性の高いコンテンツを実現できます。 過去記事のスタイルを参考にしながら、章立てや見出し構成をAIが提案し、ユーザー確認を経て記事を作成できます。 textlintなどのツールを使った文章品質チェックと記事レビューサブエージェントによる最終検証で、プロ品質の記事に仕上げます。 Markdown形式でFront Matter付きの完成記事を自動生成し、ブログシステムにそのまま投稿できます。 音声で思考を整理しながらブログ記事を作成したいライターやテックブロガー 話し言葉を文語に直す作業や文章推敲に時間をかけたくない執筆者 ブログ記事の品質を保ちながら執筆時間を短縮したいコンテンツクリエーター 定期的に技術ブログを公開する必要があるエンジニアやテック企業の広報担当者 tubone24のブログ記事作成スキルです。音声入力の文字起こしテキスト（誤認識、脱字、句読点欠落、論理の飛躍を含む）をブログ記事として完成させます。 ワークフローは以下の通り：ユーザープロンプトの主題・目的を理解し、不明点は確認を取ります。次に、技術用語調査サブエージェントで記事内のすべての技術用語・ツール名・サービス名を調査。過去記事を参照してライティングスタイルや構成を把握し、章立てを提案・確認します。各セクション執筆後、textlintで文章品質を向上させ、記事レビューサブエージェントで品質チェックと引用リンク検証を実施。最終版をユーザーに提出し、修正を経て完成させます。 Front Matterは必須で、slug（YYYY/MM/DD/slug形式）、title、date、tags、headerImage、templateKey（blog-post固定）、useAi（true固定）を含みます。見出しはh2～h5のみ、Mermaid図とコードブロックは言語タグ付き、箇条書きは最小限にとどめるという文体ルールを厳守します。

新機能の実装完了後、設計書・実装計画書・API比較表・README・チュートリアルをまとめて最新化できます Git の変更履歴から実装内容を自動判定し、どのドキュメントを更新すべきかを特定できます 実装ステータス、API仕様、実装詳細、ファイル構成などを一括更新し、ドキュメントと実装のズレを防げます 新しく実装されたAPIの場合、既存フォーマットに従って自動的に設計書を生成できます 機能を実装した直後、ドキュメント更新を効率的に済ませたい開発者 設計書と実装のズレを最小限にしたいプロジェクト README や API リファレンスを常に最新に保ちたいチーム 新機能追加時に、関連する複数のドキュメントを漏れなく更新したい人 update-docs スキルは 3 フェーズで実行されます。Phase 1（共通）：git diff と git log から変更内容を把握し、実装した機能を特定。Phase 2（開発ドキュメント更新）：設計書（docs/design/）ではステータスブロック・API仕様・Streamlit比較表を更新、実装計画書（docs/impl/）ではフェーズ完了状況・ファイル構成を更新、API比較表（docs/streamlit-api-comparison.md）では ❌ → ✅ に変更；該当ドキュメント未存在時は既存フォーマットに従い新規作成。Phase 3（README更新）：Features・API Reference セクションで新しいAPIを追加、既存フォーマット（TypeScript シグネチャ・パラメータテーブル・使用例）に従って記述。バグ修正・リファクタリング後にも使用可能。

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での絞り込み、関連用語での横断検索に対応しています。

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

コードベースから自動的にアーキテクチャを可視化: ディレクトリ構造と命名規則を分析し、プロジェクト全体の設計思想を文書化できます。 技術スタックを一元管理: 使用フレームワーク、ライブラリ、ツール、技術的な制約や決定を記録し、すべてのメンバーが参照できます。 ビジネス背景を文書化: 製品目的、ターゲットユーザー、コア機能をまとめ、「なぜこの設計なのか」の背景を共有できます。 アーキテクチャ決定の歴史を記録: ADR（アーキテクチャ決定記録）形式で過去の判断理由を保存し、同じ議論の繰り返しを防げます。 チーム間でナレッジを共有・継承: セッション終了時に学習を自動抽出・保存し、他のメンバーやプロジェクトで再利用できます。 コードとドキュメントのズレを検出: 実装の変化を追跡し、古い情報を更新するよう提案できます。 AI エージェントと協働開発するチーム（steering 情報を全エージェントが参照） 新しいメンバーがプロジェクトに参画し、素早くキャッチアップが必要な場合 複数プロジェクトを並行管理し、ナレッジを移植したい組織 アーキテクチャ決定の理由を後で参照・学習したい長期プロジェクト steering スキルは「プロジェクトの記憶」を生成・維持するコンテキスト管理スキル。3つの steeringドキュメント（structure.md：アーキテクチャパターン・ディレクトリ構造・命名規則、tech.md：技術スタック・フレームワーク・制約、product.md：ビジネスコンテキスト・目的・ユーザー）と 4つのメモリドキュメント（memories/：アーキテクチャ決定記録 ADR、開発ワークフロー、ドメイン知識、CLI コマンド集、教訓）を管理。Agent Memory CLI（musubi-remember v3.5.0）で extract/export/import/condense/list/clear 操作が可能。セッション間の学習抽出、チーム間のナレッジ共有、プロジェクト間の ベストプラクティス移植、長時間セッションのメモリ最適化をサポート。重要：すべてのドキュメントを英語版（filename.md）と日本語版（filename.ja.md）で作成することが必須。乖離検出とアーキテクチャ改善提案も実装。

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 内のメモを育てるだけで形式を整えません。

「記事を書きたい」という要望から、ピラミッド原則とSCQAフレームワークに基づき、読者を引き込める技術記事を6フェーズで段階的に完成させられます。 ユーザーと対話しながら進むため、途中で方針修正できし、自分の思いと違う記事になる失敗を防げます。 目的・読者層・構成・執筆・推敲・公開設定が体系的に進むため、品質が安定し、執筆時間を大幅に削減できます。 導入部を SCQA（Situation → Complication → Question → Answer）で設計するため、読者が最初から引き込まれる記事になります。 テック企業のブロガー・エンジニア：定期的に技術記事を公開したい、でも何から始めればいいか分からない 初めてブログを始める技術者：「良い記事」の構成やロジックを学びながら書きたい 社内ナレッジ共有チーム：複数の技術情報を体系的な記事に整理したい Zenn/Qiita 投稿者：アクセス・スター数を伸ばしたい 6フェーズワークフロー：(1) 目的と読者の確認（記事ゴール・想定読者・前提知識・読了後の期待状態を質問で明確化）、(2) SCQA導入部の設計（Situation/Complication/Question/Answer 各要素を定義）、(3) ピラミッド構造でセクション構成（結論を支える3〜5個のキーポイント → 各セクションの詳細トピック を洗い出し）、(4) 各セクションの執筆（セクション単位で執筆 → ユーザーレビュー → 修正を繰り返す）、(5) 全セクション推敲と微調整（全体の流れ・用語の一貫性を確認）、(6) 公開設定（メタディスクリプション、タグ、公開日の確認）。ピラミッド原則は結論を先に述べ、その後に根拠・詳細を階層構造で展開します。

ページを参照参照ID付きで表示：agent-browserがページ要素に@e1、@e2などの参照IDを自動付与し、複雑なHTML構造をシンプルに操作できます。 クリック・入力・スクロールを直感的に実行：参照IDを指定するだけで、フォーム入力、ボタンクリック、ページスクロールが実行でき、ブラウザ自動化スクリプトのような複雑な記述が不要です。 ログイン処理を含むWebサイト操作：ユーザー認証が必要なサイトでのログイン操作から、その後のデータ取得まで一貫して行えます。 スクリーンショットとWebスクレイピングの両立：ページのビジュアルをスクリーンショットで確認しつつ、構造化されたテキスト情報も同時に抽出できます。 パフォーマンス計測とネットワーク監視（高度な用途）：chrome-devtools MCPで読み込み時間やAPI呼び出しを監視し、パフォーマンス問題を特定できます。 Webサイトから自動でデータを収集したいが、複雑なスクレイピング技術は避けたい人 ユーザー認証が必要なWebサイトの情報を定期的に取得する必要がある場合 HackerNewsやニュースサイトなどから最新情報を自動で抽出したい人 ブラウザの自動操作ツールを初めて使う人で、簡潔な記法で操作したい場合 agent-browserはデフォルトで使用します。理由は、未使用時にトークンを消費しないこと、参照ID（@e1、@e2等）でコンテキスト93%削減、シンプルなブラウザ操作に十分という点です。chrome-devtools MCPは高度な操作が必要なときのみ動的ロードします。 agent-browserの基本コマンドはopen（ページを開く）、snapshot（ページ構造を見る）、click（要素をクリック）、fill（フォーム入力）、scroll（スクロール）、screenshot（スクリーンショット）、closeです。Refsシステムでページ要素に@e1、@e2等のIDが付与され、これを使用して操作します。 chrome-devtools MCPは、パフォーマンス計測（performance_start_trace等）、ネットワークリクエスト監視、コンソールメッセージ取得、複数タブ操作、JavaScriptプログラムの実行が必要な時に使用します。主要ツールはnavigate_page、take_snapshot、take_screenshot、click、fill、evaluate_script、list_network_requests、list_console_messages、パフォーマンストレース機能です。

プロジェクトのアウトライン（目次・章立て）を読み込んで、文体・トーン・執筆方針をAIと対話形式で決定できます。 カジュアル/フォーマルの選択、一人称の表記（私/僕など）、語尾のスタイルなど細かい執筆ルールを対話の中で確定させられます。 参考にしたい記事のURLやスタイル例を提示することで、目指すトーンを具体的に共有できます。 決定した方針を「write-plan.md」に構造化して保存し、実際の執筆フェーズで一貫性のある文章を生成できるようにします。 ユーザーが明示的に同意するまで次のステップに進まず、納得できる執筆方針が確定するまで修正・調整を繰り返せます。 記事やブログ、ドキュメントを執筆する前に、文体ルールを明確にしておきたいライター・エディター 複数の執筆者がいるプロジェクトで、統一された文体・トーンを保ちたいチーム AIによる自動執筆の品質を高めたい方（方針が明確なほど生成結果が良くなる） 執筆方針の決定プロセスを記録として残しておきたい方 Phase 1 執筆準備スキルはアウトラインを読み込み、文体・トーン・執筆方針を対話形式で決定してwrite-plan.mdに保存します。プロジェクト名（$ARGUMENTS）必須で、未指定の場合は案内して終了します。context.md・goal.md・outline.mdを読み込み、不在の場合は該当フェーズを案内します。ユーザーに文体・トーン（カジュアル/フォーマル、一人称表記、語尾スタイル）、参考スタイル（任意のURL・説明）、特別な制約（文字数目安、フォーマット要件）を聞きます。回答は構造化前にoutput/$ARGUMENTS/write/input-log.mdに原文のまま記録してから、write-plan.mdへ統合・保存します。write-plan.mdはテンプレート（templates/write-plan.md参照）に従い、文体方針・アウトライン章と記事セクション対応表・執筆上の注意点（独自価値・避けるべきこと）を含めます。保存後、整理内容をユーザーに提示して同意確認し、追加・修正要望があれば反映します。ユーザーが明示的に同意したら「Phase 1完了」と伝え、Skillツール（write-body、$ARGUMENTS引数）を起動して実行フェーズに移行します。

ブログのテーマをヒアリングしながら、Zenn互換のMarkdown記事を対話的に構成・執筆できます。 Playwright CLI でブラウザスクリーンショットや動画を自動撮影し、手順や操作フローを画像で記録できます。 読者像・記事のゴール・トーン（チュートリアル/解説/体験記など）を確認し、読みやすい構成を自動生成します。 セクション、コード例、アウトラインをテンプレート化した上で、Zenn Topics タグも自動提案します。 完成後のファイルを blog-output/ に整理して出力し、Zennへの投稿準備が完了します。 エンジニアで、使った技術や知見をZennに記事化したいが、構成や見出しに迷う方 ソフトウェアの紹介・チュートリアル記事を書く際に、スクリーンショット撮影を自動化したい方 技術ブログを継続的に書きたいが、毎回ゼロから構成を考えるのが負担な方 デモ動画やスクリーンショットが豊富で、わかりやすい記事を短時間で完成させたい方 ブログ記事作成は5つのフェーズで進みます。Phase 1（ディスカッション2-3回）では記事ゴール・想定読者・記事種別を対話で確認、Phase 2（アウトライン確定）では構成・撮影計画を表形式でユーザーに提示し承認を得ます。Phase 3（素材撮影）では Playwright CLI でスクリーンショット・動画・GIF を撮影、blog-output/NNN/ ディレクトリに連番で整理します。ffmpeg は GIF変換に必要。Phase 4（記事執筆）で Zenn互換Markdown を生成、Phase 5（完了）でファイルパスと概要を報告します。入力パラメータはテーマ・方向性・対象URL で、短い指示でも Phase 1 から対話を開始し、不足情報を補います。

5ch.ioへの接続状態を確認し、到達可能かどうかを検証できます。 投稿フロー（ユーザーが実際に記事を投稿できるかの流れ）をテストできます。 認証機能（ログイン・認証トークン）が正常に動作しているか確認できます。 複数の検証タイプ（到達性確認、投稿機能、ユーザー認証、権限昇格など）を選択して実行できます。 実際の投稿を実行する際は安全トークンが必須となり、誤った投稿を防ぐことができます。 5ch.ioのシステム管理者で、定期的にサービスの稼働状況を確認したい人 5ch.ioプラットフォームの投稿機能が正常に動作しているか検証したい開発者 システム障害が発生したときに原因を特定したい技術担当者 新しい認証機能をデプロイした後に動作確認をしたい運用チーム 5ch.io接続プローブを実行するスキルで、引数でプローブ種別を選択します。実行可能なプローブは以下の通りです。validateは基本的な接続確認を実行し、postは投稿フロー全体をテストします。beはバックエンド（BE）ログイン深掘り検証を、upliftはバックエンド権限昇格認証を検証します。引数なしまたはallを指定した場合は、デフォルトでvalidateのみを実行します。重要な制限として、ユーザーが安全トークンI_UNDERSTAND_REAL_POSTを明示的に提供しない限り、--allow-real-submitオプション付きでプローブを実行してはいけません。実行にはPython 3とrequestsパッケージが必要です。

アーキテクチャパターンを自動抽出・文書化: ディレクトリ構造、命名規則、コード組織を分析し、structure.md に整理できます。 技術スタックを可視化: 使用言語、フレームワーク、ライブラリ、ツール、技術制約を tech.md として一元管理できます。 ビジネスコンテキストを記録: README やドキュメントから製品目的、ユーザー、コア機能を抽出し product.md に整理できます。 プロジェクト設定を機械可読形式で管理: project.yml にアーキテクチャ、技術スタック、設定を記録し、他のエージェントが自動参照できます。 セッション間の学習を自動保存: musubi-remember CLI を使い、セッション終了時に学習を抽出・保存し、チーム間でナレッジを共有できます。 コードとドキュメントの乖離を検出: アーキテクチャ変更を察知し、ドキュメント更新の必要性を提案できます。 マルチエージェント開発環境でプロジェクト情報を一元化したい人 新しいメンバーがプロジェクト全体を素早く理解する必要がある場合 チーム間でアーキテクチャ決定やベストプラクティスを共有したい組織 長期プロジェクトで知識の継承と蓄積が課題の人 steering スキルは、コードベース分析、steeringドキュメント管理、メモリシステム管理の3専門領域で構成。steeringドキュメント：structure.md（アーキテクチャ・ディレクトリ構造）、tech.md（技術スタック・制約）、product.md（ビジネスコンテキスト）、project.yml（機械可読設定）。memories/ ディレクトリに ADR（アーキテクチャ決定記録）、開発ワークフロー、ドメイン知識、よく使うコマンド、教訓を保存。Agent Memory CLI（musubi-remember）で extract（学習抽出）、export/import（ファイル化）、condense（圧縮）、list（一覧）、clear（削除）が可能。英語版と日本語版ドキュメント両方必須（filename.md と filename.ja.md）。コードとドキュメント乖離の検出と改善提案も含みます。

GitHub PR を素早く作成でき、適切なラベル（feature、bug、refactoring、documentation、chore、AI、test）を自動または手動で付与します。 PR の一覧表示、詳細表示、ブラウザでの確認、ブランチのチェックアウトなどを効率的に行えます。 PR に寄せられたコメント（会話コメント・インラインレビューコメント）を一括取得し、複数のコメントを見落とさず確認できます。 マージ前に VRT（ビジュアルリグレッションテスト）の実行状況を確認し、UI 変更の意図的性を検証できます。 他リポジトリへの誤操作を防ぎ、sh1ma/blog リポジトリのみで安全に PR 管理できます。 GitHub を使用したチーム開発を行っており、PR ワークフローを効率化したい開発者 PR 作成時に必要なラベル付けやテンプレート遵守を自動化したい方 複数の PR コメント・レビュー指摘を見落とさず、確認漏れを防ぎたい方 UI 変更を含む PR で VRT スナップショット更新の判断を適切に行いたい方 このスキルは sh1ma/blog リポジトリのみを対象とし、他リポジトリへの --repo 指定は禁止です。主要コマンドは以下：gh pr list で PR 一覧を状態・author・assignee・ラベルでフィルタ表示。gh pr view 123 で PR #123 の詳細を表示し、--comments で会話コメントを、--json comments で詳細 JSON を取得。gh pr checkout 123 で PR のブランチをチェックアウト。gh pr create で新規 PR を作成する際、.github/pull_request_template.md テンプレートを遵守し、「概要」「変更内容」「関連Issue」「テスト項目」「VRT設定」「スクリーンショット」「備考」の各セクションを記入。ラベルは必ず feature・bug・refactoring・documentation・chore・AI・test から 1 つ以上を指定。複数ラベルは --label "feature" --label "AI" で付与。PR 作成後は自動で VRT が実行され、UI 変更時には R2 からベースライン（main ブランチ最新スナップショット）と比較されます。

要件定義書（requirements.md）をもとに、開発作業の設計書（design.md）を自動生成します。 新規機能開発またはパフォーマンス改善など、作業タイプに応じて最適なテンプレートを自動選択します。 永続化ドキュメント（アーキテクチャ仕様書、リポジトリ構造定義書、開発ガイドライン等）を自動参照し、既存のルールに準拠した設計を生成します。 多言語対応（i18n）やNuxt UI v4の最新コンポーネント記法を設計に反映させます。 既存の開発ディレクトリに設計書を追加したり、古い設計書を再生成・更新することができます。 新機能開発を始める際に、要件から設計書を素早く作成したいエンジニア パフォーマンス改善プロジェクトで、最適化戦略を設計書として形式化したい技術リード プロジェクトのコーディング規約やアーキテクチャに準拠した設計を確実に作成したいアーキテクト 複数の開発作業ディレクトリを管理するプロジェクトマネージャー このスキルは開発作業の設計書（design.md）を生成・再生成します。使用シーンは要件定義から設計開始時、パフォーマンス改善の最適化設計時、既存ディレクトリへの設計書追加時、設計書再生成時です。必要情報はディレクトリパス（docs/working/{YYYYMMDD}_{要件名}/）、要件名（英語ケバブケース）、作業タイプ（「feature」または「performance」、デフォルト「feature」）です。前提としてrequirements.mdの存在を推奨します。実行手順：Step 1で企画書を読み込み、テーマ・ターゲット・見出し構成を確認、Step 2でCONTRIBUTING_QIITA.mdとcontext/knowledge/参照、Step 3で記事を執筆し導入セクション・本文・サンプルコード・まとめセクションを記載、Step 4で保存完了です。執筆ルールはCONTRIBUTING_QIITA.md全遵守、本文2,000～6,000文字目安、H1未使用H2から開始、コードブロック最低1個以上、外部リンクは公式ドキュメント優先です。テンプレートはtemplate.mdまたはtemplate-performance.mdを使用し、Nuxt UI v4記法（UFormField使用、UFormGroup禁止、items属性使用、options禁止）を必須とします。多言語対応（i18n）は必須で、ハードコード文字列禁止、翻訳キー構造設計、プレースホルダー対応を明記します。永続化ドキュメント参照は03_architecture_specifications.md（技術スタック確認）、04_repository_structure.md（ディレクトリ構造確認）、05_development_guidelines.md（コーディング規約確認）、06_ubiquitous_language.md（用語確認）、UI設計時は05の「2.4多言語対応」確認が必須です。