太刀使いの舘ひろし

構成図・アーキテクチャ図・エージェント構成・処理の流れを「動く画像」にして、X（Twitter）などに貼れる MP4 と GIF で書き出すスキル。ノードが順に現れ、線が引かれ、光の粒がエッジを流れ、いま動いている部分だけが光り、下に字幕がタイプされ、最後に全体が同時に動いてループする。箇条書きのツリー（「> main が…」「> worker が…」のような投稿文）やシステムの説明文を渡すだけで作れる。「構成図を動画にして」「アーキテクチャ図をアニメーションで」「エージェントのツリーを動く図に」「データの流れが見える図」「Xに貼る図解GIF」「この投稿みたいな動く図」「フロー図をMP4で」と言われたら、動画やGIFと明言されていなくても必ずこのスキルを使うこと。マルチエージェント構成、マイクロサービス、データパイプライン、RAG、CI/CD、業務フローなど、箱と矢印で描けるもの全般に使う。「お客様（専門外の人）に仕組みを説明する動画」「質問が処理されて返事になるまでを見せたい」「AI とプログラムの役割分担を見せたい」「データが手順を通ってどう変わるか」「ループの流れを動画で」のように、1つの具体例が手順を通って変わっていく様子を見せたいときも使う（運搬型）。静止画の図だけが欲しい場合（Mermaid で十分な場合）には使わない。

中文简介正在准备中。当前显示原文说明。

GitHub の issue / PR に投稿するコメントの書き方ルール。お客さん・非エンジニアも読む前提で、平易・短く・結論だけ・専門用語なしで書くためのもの。`gh issue comment` / `gh pr comment` でコメントを書く・投稿する・直すとき、特に検証結果（修正できた証拠）や差し戻しへの返信を書くときは必ずこのルールに従う。「issue にコメントして」「PR にコメント残して」「検証結果を載せて」と言われたら、明示されていなくてもこのスキルを参照する。

中文简介正在准备中。当前显示原文说明。

GitHub の issue を 1 件こなすときの開発ルール集。issue の読み方、作業フォルダ（git worktree）の選び方、ブランチの切り方と名前、Before/After の証拠の撮り方、コミット・push・PR の決まり、issue / PR へのコメントの書き方をまとめたもの。複数の issue を自動で回すループは含まない。「issue に着手して」「#123 やって」「この issue 対応して」「ブランチ切って」「PR 出して」「issue にコメントして」など、issue を起点に開発するときは、スキル名が出ていなくても参照する。

中文简介正在准备中。当前显示原文说明。

自分が担当している GitHub issue の「今どうなっているか」と、作業フォルダ（git worktree）の空き状況をまとめて確認する skill。「担当 issue の状況」「自分のチケット確認」「今抱えてる issue 一覧」「何が止まってる？」「ボールどっち？」「自分の issue の進捗まとめて」「空いてる worktree ある？」などと言われたら使う。issue 番号を指定されなくても、自分の担当 issue を棚卸ししたい意図が見えたら起動する。最重要: ブランチや PR の有無だけで「未着手」などと判断してはいけない。各 issue のコメントを 1 件ずつ実際に読んで現状を出す。

中文简介正在准备中。当前显示原文说明。

要件・問い合わせ・事例の集まりを、「対応が変わる分かれ目」で階層に分けて抽象化する（パターン分け・ケース分け・分類）。上の階層ほど根本の問い、下の階層は「なぜそうなるか」の理由で分け、名前は見た目ではなく「相手の側で何が起きているか」で付ける。「パターン分けして」「抽象化して」「ケースを整理して」「分類して」「網羅的に洗い出して」「テストケースを設計して」「どういう場合がある？」と言われたとき、事例の一覧から応対・仕様・テストの方針を作るとき、ユーザーが同じ整理を何度も求めているとき（伝わっていない合図）は、明示されていなくても必ず使う。

中文简介正在准备中。当前显示原文说明。

要件・仕様・業務の説明・受注依頼書から、業務の分類、中心となるデータと守る決まり、業務同士のつながりを整理し、設計の土台を作る。まず業務領域ごとに作り方を3段階で判定する（1: Next.js＋Prisma＋SQLite＋Tailwind で素直に作る、2: 厳選した11種のデザインパターンで疎結合にする、3: 集約・リポジトリ・値オブジェクト・ユースケースなど DDD の部品を持ち込む）。全体図・判定表・機能一覧を先に示し、用語、主体、保存の当たりを仮置きする。「要件をDDDで整理して」「集約を切って」「文脈を分けて」「ユビキタス言語を作って」「ドメインモデルにして」「設計に落として」「モデリングして」「構造を整理して」「どう作ればいい？」「DDDいる？」「どのパターンが合う？」など、要件から設計を考える依頼に使う。UIモックや画面設計のみ、設計済みコードの実装のみ、パターンの一般解説のみの依頼には使わない。

中文简介正在准备中。当前显示原文说明。

GitHub の Kanban から1〜3件の issue を取って、1件ずつ順番に「理解 → A/B 判定 → （必要なら設計）→ ブランチ → Before → 実装 → After → PR → レビュー対応」まで自走で処理する skill。feedback / enhancement / bug すべて対象。明示トリガーは `/issue-loop`、「kanban から issue 回して」「3件まとめて対応して」「ループで issue 処理」「feedback 回して」など。各 issue で A/B 判定する：A（やることが明確）なら設計を省いてすぐ実装に進めるか確認、B（曖昧）なら設計 HTML を見せて Accept を取ってから実装。「実装しなくていいから A パターン（すぐ迷わず実装できる issue）だけ洗い出して」「簡単なやつリストして」のように着手せず候補だけ見たいときは**スキャンモード**（`--scan`）で、A の issue だけを表にして止まる。

中文简介正在准备中。当前显示原文说明。

手元のスクリーンショット（PNG/JPG）に、番号付きの赤枠＋日本語の「使い方ガイド」凡例パネルを 重ねた画像を作るスキル。英語だらけのツール画面（SaaS / 管理画面 / 開発ツールなど）の 各ボタンやメニューの意味を、非エンジニアや新メンバーにも一目で分かるように注釈する。 「この画面に使い方ガイドを載せた画像を作って」「英語UIに日本語の説明を重ねて」「スクショに 赤枠と番号とラベルを付けて」「操作手順を画像で示したい」「オンボーディング用の注釈画像がほしい」 「/screenshot-annotate」などと言われたら、明示的にスキル名がなくても起動する。 ライブのブラウザを開いて撮り直す方式ではなく、既にある静止画に後から描き込む方式。 逆に、まだ撮っていない画面を撮るところからやる場合や、動画・GIF を作る場合には使わない。

中文简介正在准备中。当前显示原文说明。

「ものの仕組み」を3DCGで見せる解説ショート動画（縦 1080×1920・字幕・男性ナレーション付き MP4）を、Three.js とコードだけで作るスキル。台本（script.json）→ Gemini TTS でナレーション → 声の長さからカット割りと字幕の時刻を自動で決める → Three.js で各カットを「時刻 t の関数」として描く → Playwright で1コマずつ取り出し ffmpeg で MP4。参考にしたい動画があれば yt-dlp で落として1秒1枚に分解し、構成・カットの長さ・字幕の置き方を読み取ってから作る。「仕組みを3Dで解説する動画を作って」「Three.js で解説動画」「YouTube ショートの解説動画」「この動画みたいな3D解説を作りたい」「ナレーション付きの3D動画」「〇〇の仕組みを動画で」「yt-dlp で落としてフレーム分解して」「動画を1秒ごとに分解して内容を見て」と言われたら、Three.js と明言されていなくても必ずこのスキルを使うこと。Also use for any request to make a narrated 3D explainer / how-it-works short video with code (Three.js, WebGL, TTS narration, Gemini TTS, vertical shorts), or to download a reference video with yt-dlp and break it into frames to study its structure. 文字が音楽に合わせて動く MV は kinetic-type-mv、箱と矢印の構成図を動かすのは animated-arch-diagram を使う。

中文简介正在准备中。当前显示原文说明。