Skills
エージェント向けにパッケージ化された専門スキルと手順を 99,719 件掲載。コマンド 1 行でインストールできます。
すべて
予算を意識した演出。スクロール連動アニメーションではまずネイティブ CSS を使い、必要に応じて GSAP ScrollTrigger を使用します。Lenis によるスムーズスクロールと無効にするタイミング、分割テキストの表示、ピン留めシーン、性能予算内での canvas と WebGL、マテリアルとしてのシェーダー、画面外での一時停止、読み込み戦略、ページの可読性を保つ reduced-motion と JavaScript 無効時のフォールバックを扱います。マーケティングページ、ポートフォリオ、ローンチページ、ヒーローセクションに使用します。プロダクト UI には使用しません。
Semantic Versioning 2.0.0（semver.org）を適用して、バージョンの上げ幅の判断、バージョン文字列の検証、バージョン優先順位の比較を行う。次のバージョン番号の選定、変更が MAJOR/MINOR/PATCH のどれに当たるかの判断、文字列が正しい形式のバージョンかどうかの確認、優先順位によるバージョンの並べ替え、プレリリース版やビルドメタデータ付きバージョンの作成を伴うタスクで使用する。リリース、changelog、公開ワークフローの構成要素としてよく使われるため、"semver" という語が出てこなくても、バージョン番号を扱う場面では必ずトリガーする。
Douyin／Hongguo のヒット短編ドラマ向け、工業化脚本制作スーパーシステム v4.9.1。純粋な脚本エンジン（全ジャンル向け公開汎用版、制作連携なし）。主な機能：必要に応じて動的にマウントするマトリクス（8 つの対話モード、Context の肥大化を防ぐためコアファイルのみマウント）、感情契約ユニットチェーンの往復法、40 ジャンルの全体マップ（男性向け 12／女性向け 14／中性 14）、6 種の基本フック（中核の切り札を不可逆に奪う型を含む）と 5 つのクリフハンガー公式、A~I の 9 種の逆転手法のローテーションマトリクスとホット／コールド台帳の階層化、3 段階の長さ（標準 90~120 秒／本文 480~850 字、長尺 150~195 秒／820~1400 字、マンガドラマ 60~90 秒／330~620 字）、1 話 15 秒の切り替えにおける 4 拍進行表（引き込みと状況提示→正面衝突→札を明かして逆転→余波のフック）、強い映像を支える 3 つの視覚アンカー（2~4 文ごとに強い視覚描写 △ を挿入、E24 は会話だけの間延びを防止／E26 は無意味な微動作を防止）、平易な言葉で同じ拍に直接伝えるルールと緩急の原則（証拠と結論を同時に明示／設定用語は同じ文中で平易に言い換え、E25 は謎めいた隠語を防止）、似せるが模倣しない三層の再構成法（表層と禁止語を剥がす→ドラマの公式を抽出→別次元の装いに置き換える）、尺換算アンカー（目標速度 4.5 字/秒で執筆し、誇大な尺表示を防ぐため最低 4.5 字/秒で検証）、15 秒枠あたり <=95 字の制作側チェック、動作段落 <=40 字のソフト制約、セリフ／動作の黄金比 25%~70%、最初の 3 話のビートカード、ペイウォールの 4 変種、話をまたぐ連続性台帳、ウェブ小説の脚色パイプライン、人物バイブル、ドラマ技法レイヤー、独白・ナレーションの制御規程、表情フレーズの形式（映像語｜口調語）、レビュー・修復用問題カード、保護用反例集、広電 16 号令のコンプライアンス上の禁止事項 11 項目、段階別脚本機械チェック（E1~E26）と全編台帳チェック（S1~S8）。短編ドラマやアウトラインの執筆、企画立案、引きの調整、話ごとの構成、長尺版の執筆、脚本ドクター、ブラッシュアップ、内面独白、ナレーション、オフボイス、超高速短編ドラマ、コンプライアンス審査、連続執筆で使用します。
FlagOS スキルリポジトリ向けに新しいスキルを作成し、既存のスキルを変更し、スキルの品質を検証する。スキルをゼロから作成したい、既存のスキルを改善・編集したい、新しいスキルディレクトリを雛形から作成したい、スキル構造を検証したい、スキルに対してテストケースを実行したい場合にこのスキルを使用する。ユーザーが「create a skill」「make a new skill for X」「scaffold a skill」「improve this skill」「validate my skill」などと言った場合、または単に「/skill-creator-flagos」と入力した場合に発火する。ワークフローを再利用可能なスキルにしたい、繰り返しのプロセスをスキルとしてパッケージ化したいと言及した場合にも発火する。
smina 分子ドッキング CLI。カスタマイズ可能なスコアリング関数、ネイティブな SDF/MOL2/PDB リガンド入力、自動ボックス設定、局所エネルギー最小化、原子ごとのスコア内訳を備えた AutoDock Vina のフォーク。パイプライン：受容体 PDBQT の準備 -> リガンドの準備（RDKit/OpenBabel）-> 自動ボックスまたは明示的なグリッドでドッキング -> カスタムスコアリングで再スコア/最小化 -> 親和性でポーズをランク付け。カスタムスコアリング項（--custom_scoring）、既存ポーズの局所最適化（--local_only）、原子ごとの寄与（--atom_term_data）、または PDBQT への手動変換なしでの SDF/MOL2 リガンドが必要な場合は Vina より smina を選ぶ。結合部位が不明な場合は diffdock、Python バインディング/Vinardo ワークフローには autodock-vina-docking を使う。
Smithery ホームページアプリを構築・編集します。これは ~/.smithery/homepage にある TanStack Start + shadcn/ui の Web アプリで、Smithery Connect API を通じて MCP サーバーに接続します。ユーザーが Smithery ホームページを作成・変更・機能追加したい場合、MCP ツール（Linear issues、Gmail、Notion など）のデータを表示するページを構築したい場合、または ~/.smithery/homepage 内の編集について尋ねた場合はいつでもこのスキルを使用します。「add a page to the homepage」「show my Linear issues on the homepage」「update the homepage UI」といったリクエストや、~/.smithery/homepage プロジェクトに関わるあらゆるタスクでもトリガーされます。
ユーザーが LinkedIn、Twitter/X、Instagram、TikTok、Facebook などのプラットフォーム向けのソーシャルメディアコンテンツについて、作成、スケジュール設定、最適化の助けを求める場合に使用します。「LinkedIn の投稿」「Twitter のスレッド」「ソーシャルメディア」「コンテンツカレンダー」「ソーシャルスケジュール」「エンゲージメント」「バイラルコンテンツkitsume」とIntegrityされた場合も使用します。本スキルはコンテンツ作成、.Platform再利用、プラットフォーム固有の戦略dealなFoo Covers。
Creative Designer スキル。投稿のコンセプト、クライアントの製品写真、または実際のライフスタイル写真を受け取り、クライアントのブランドスタイルガイドを用いてブランドに沿ったソーシャルメディアビジュアルを制作する。4 つのモード — Generate（コンセプトから AI 画像を生成）、Composite（クライアントの製品写真を AI 生成シーンに配置）、Brand（実在のクライアント写真にテキストオーバーレイ処理を適用）、Stop-Motion Reel（6 フレームのアクションシーケンスを MP4 として書き出し）。brand-style.md を読み込み、プロンプトを構築し、Nano Banana MCP 経由で画像を生成・編集し、画像 + プロンプトログ + クリエイティブブリーフを出力する。
検証済みの多角的な視点でソフトウェアエンジニアリングの問いを調査するよう求められた場合に使用する——"should we use X vs Y"、"evaluate library/framework/database Z"、"research whether we should adopt …"、"write an ADR for …"、"spike on …"、"migrate from X to Y / upgrade path"。ソフトウェアに特化した STORM スタイルのパイプラインを実行する。5 つのリサーチモード（library-eval、deep-research、architecture、spike、migration）のいずれかを自動検出し、そのモードの専門家視点を並列に立ち上げ、それらの矛盾を整理し、HTML ブリーフィングと Markdown/ADR 記録を統合生成したうえで、バージョンを考慮しつつ一次ソフトウェア情報源（公式ドキュメント、RFC、GitHub リリース、OSV/CVE、OpenSSF Scorecard、ベンチマーク）に対してすべての主張を敵対的に検証する。複数の視点と、バージョンに正確でファクトチェック済みの主張が重要な意思決定に最適。素早い API 照会には過剰。ソフトウェア以外のトピックには deep-research を、純粋に採点された意思決定マトリクスには trade-off-analysis を使用する。
プラットフォームに依存しない優れたウェブサイトの仕様「The Website Specification」を検索して適用します。各項目は必須、推奨、任意、回避に分類されています。サイトに必要な要素、何かが必須かどうか、URL の監査方法、エージェント対応に不足している点など、ウェブのベストプラクティスを推測で答えることになる質問に使用します。WHATWG、W3C、IETF RFC、IANA、WCAG などの一次資料に基づいて回答します。HTTP 経由の Markdown として利用でき、検索、一覧、取得、チェックリスト、監査ツールを備えた MCP サーバーとしても利用できます。
Spring Boot の API ドキュメント向け Springdoc OpenAPI。Swagger UI の構成、アノテーション、schema のカスタマイズ、セキュリティドキュメントを扱う。castellino と gestionale-presenze プロジェクトの本番実践に基づく。使用場面：ユーザーが "Springdoc"、"Spring Boot OpenAPI"、"Swagger in Spring"、"@Operation"、"@Schema"、"Swagger UI Spring" に言及した場合、または "Spring Boot API documentation"、"Spring REST documentation"、"OpenAPI in Java" について質問した場合。使用しない場面：一般的な OpenAPI 仕様——代わりに `openapi` を使用。GraphQL——代わりに `graphql` を使用。Spring Boot 以外のプロジェクト。フロントエンドの OpenAPI 生成——代わりに `openapi-codegen` を使用。
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。