Agent Skills by ALSEL
Anthropic ClaudeLLM・AI開発⭐ リポ 0品質スコア 50/100

gtm-board-and-investor-communication

取締役会の準備、投資家向けアップデート、経営幹部とのコミュニケーションを支援するスキル。ボードデッキの作成、投資家への進捗報告、悪いニュースの伝え方、QBRの構成、取締役会レベルの指標管理が必要な場面で活用できます。「Three Things」ナラティブモデル、4階層の指標フレームワーク、取締役会でのサプライズを防ぐ事前ブリーフィングパターンを含みます。

description の原文を見る

Board meeting preparation, investor updates, and executive communication. Use when preparing board decks, writing investor updates, handling bad news with the board, structuring QBRs, or building board-level metric discipline. Includes the "Three Things" narrative model, the 4-tier metric hierarchy, and the pre-brief pattern that prevents board surprises.

SKILL.md 本文

取締役会とインベスター・コミュニケーション

信頼を築き、意思決定を促進する取締役会会議、インベスター・アップデート、経営層向けコミュニケーションを構築します。誰も読まないスライドデッキではなく、実質的な伝達を実現します。

使用時期

トリガー:

  • 「取締役会会議にどう向き合えばいい?」
  • 「インベスター・アップデートに何を入れるべき?」
  • 「目標を達成できなかった。どう伝える?」
  • 「取締役会デッキの構成」
  • 「インベスターにどのくらい頻繁に更新を送るべき?」
  • 「取締役会会議が生産的でない」

コンテキスト:

  • シード~成長期のスタートアップ
  • 取締役会会議の準備と事後対応
  • 月次/四半期ごとのインベスター・アップデート
  • 目標ミスと悪いニュースの伝達
  • 戦略を取締役会から組織全体へカスケードする

コア・フレームワーク

1. ストーリーを語り、その後にデータを示す

パターン:

ほとんどの取締役会はデータの洪水で始まります。メトリクスのスライドが次々と続き、その後10分の質疑応答で取締役会メンバーがそれが何を意味するのか理解しようとします。

これを逆にします。ナレーティブがリードし、データはそれを裏付けるべきです。

仕組み:

あなたたちがどのような段階にいるかを説明するところから始めます。「ARRはこれです」ではなく「四半期初めに何を信じていたのか、何を学んだのか、それが今私たちをどこに置くのか」です。その後、そのナレーティブを検証するデータを示します。

取締役会会議の構成:

事前資料(会議の48~72時間前に送付)

  • 財務ダッシュボード(ARR、バーン、ランウェイ、パイプライン)
  • ヘルスインジケーター付きメトリクス・スコアカード(緑/黄/赤)
  • 市場コンテキストと戦略的アップデートをカバーする2~3ページのナレーティブ・サマリー
  • ルール: 読むことができるなら、プレゼンテーションしない

会議(90~120分)

  1. 市場コンテキストと事前資料への質問 (15分)

    • 前回の会議以降、市場で何が変わったか?
    • 取締役会が事前資料で不明な点について質問
    • データを再プレゼンしない
  2. CEO戦略アップデート — 「三つのこと」 (15分)

    • うまくいっていることは何か (勢いを示す2~3分野)
    • うまくいっていないことは何か (曖昧ではなく、1~2の具体的なギャップ)
    • それについて何をするのか (約束ではなく、具体的な変更)
    • これはナレーティブであり、数字ではありません
  3. 意思決定案件 (30~45分)

    • 取締役会の意見や承認が必要な1~3のトピック
    • 準備して臨む: 「X と Y のどちらかで決定しようとしていますが、取締役会の考えはどうですか?」
    • 「来期また検討しよう」ではなく、意思決定を持って終える
  4. 深掘り (20~30分)

    • 1つのトピックを深く掘り下げ(毎回異なるトピック)
    • それを所有する機能のリーダーを連れてくる
    • 例: 価格戦略、競争環境、組織設計、市場拡大
  5. クロージング (10分)

    • 下された決定と実行責任者をまとめる
    • 非公開セッション(取締役会のみ、経営陣なし)
    • CEO と取締役会会長の事後会談

よくある間違い:

  • ナレーティブの前にデータで始める(取締役会がコンテキストなしで数字に迷う)
  • 複数の競合するナレーティブ(取締役会が統合できない — 1つの流れに絞る)
  • 多くのトピックを深く掘ろうとする(すべての決定が急ぎになる)
  • 深掘りがない(取締役会がゴム印になる)
  • 良いニュースだけで会議を埋める(取締役会は勝利だけを共有するCEOを信頼しない)

2. 「三つのこと」ナレーティブ・モデル

パターン:

ビジネスは複雑すぎて、1つの見出しで要約できません。3つの異なるポイント — うまくいっていることは何か、うまくいっていないことは何か、何が変わっているか — により、取締役会は数分で状況と軌跡を理解することができます。

うまくいっていることは何か(2~3分野): 具体的に。「営業がうまくいっている」ではなく「初の6桁エンタープライズ案件をクローズし、商業モーションを検証した」です。勢いを定量化:

  • 新製品ローンチが採用されている
  • セールスモーションが成熟している(初の大型顧客、反復可能なモーションが出現)
  • コミュニティ/エコシステムのマイルストーン

うまくいっていないことは何か(1~2分野): 同様に具体的に。「いくつかの課題があった」ではなく「セルフサーブのコンバージョン率が低い — 認知度は強いが0.1%のコンバージョン率」です。取締役会は実際の問題を理解する必要があり、婉曲な言い方ではありません。

それについて何をするのか(「うまくいっていない」それぞれについて): 具体的な変更を述べる。製品にはどのような変更を加えるか? 組織にはどのような変更を加えるか? タイムラインは? 投じるリソースは?

なぜこれが機能するのか:

取締役会メンバーは数十のアップデートを読みます。「三つのこと」モデルは彼らに精神的なファイリング・システムを与えます: 勢い(気分を良くする)、リスク(注意を払う)、主体性(このチームは問題に対処する)。これがないと、取締役会は1つの悪いメトリクスに過剰に反応するか、40スライドのデッキに埋もれた実際の問題を見落とします。


3. 進捗は絶対値ではなく方向性

パターン:

50K を目指していたのに 100K ユーザーに達したとしても、それが問題ではありません。200K を逃したとしても同様です。コンテキストがすべてです。絶対数ではなく、ゴールに向かった進捗を示します。

進捗のフレーミング方法:

  • 計画通り: 「目標は 10 万人のアクティブ開発者。現在 7 万人。すべてのイニシアチブが計画通りに実行されている。確実性: 高。」
  • リスクあり: 「目標は 10 万人のアクティブ開発者。現在 5 万人。獲得コストが予想より高い。新しいチャネルをテスト中。目標を調整: 8.5 万人。確実性: 中。」
  • 目標超過: 「目標は 10 万人のアクティブ開発者。現在 9.5 万人。獲得予測を上回る成績。新しいパートナーシップが成長を加速。確実性: 非常に高い。」

ルール:

  1. ゴールを事前に設定する(すべてのメトリクスにはターゲットが必要)
  2. 進捗を絶対数ではなくゴール達成度の % として示す
  3. ミスを認める; ピボットを説明する
  4. 軌跡に基づいて確実性レベルを述べる

よくある間違い:

ミスをしたときにゴールを変える。取締役会はこれを追跡します。Q1 目標が 100K でしたが 60K に達した場合、Q2 目標を 75K にしないで「改訂ガイダンス」と呼んでください。ミスを述べ、理由を説明し、回復計画を示します。信頼性はメトリクスより速く複利で増えます。


4. 4段階メトリクス・ヒエラルキー

パターン:

メトリクスが多すぎると取締役会を混乱させます。少なすぎると重要な信号を見落とします。4つの層でメトリクスを構造化し、四半期ごとに変更しないでください。

第1層: 北極星(1つのメトリク) 企業の健全性を最もよく表す単一のメトリク。

  • 例: ARR、アクティブユーザー、完了したタスク
  • トレンドラインを示す、現在の状態だけではなく
  • これは取締役会が他のすべてを忘れた場合に覚えるべき1つのメトリクです

第2層: ドライバー・メトリクス(3~5個) 北極星を予測する主要なリード指標。

  • ユーザー獲得率
  • リテンション曲線(先月アクティブだったユーザーのうち何人が今月もアクティブか?)
  • 機能採用(主要機能を使用しているユーザーの%)
  • DAU/MAU比率
  • パイプラインカバレッジ
  • なぜ追跡するのか: 収益への影響の前に早期警告

第3層: ヘルス・メトリクス(3~5個) チームと運営上の健全性の信号。

  • バーンレートとランウェイ
  • 実績vs計画のヘッドカウント
  • エンジニアリング速度 / リリース速度
  • NPS またはカスタマー満足度
  • なぜ追跡するのか: 成長の制約要因となる容量

第4層: レッド・フラグ(2~3のしきい値) しきい値を超えた場合、即座の対応が必要なメトリクス。

  • チャーン率が X% を超える
  • CAC が $Y を超える
  • リテンション低下が Z% より大きい
  • なぜ追跡するのか: 監視ではなく、戦略的会話のトリガー

規律のルール:

  1. 毎四半期同じメトリクス。 4~6四半期の履歴を構築します。新しいメトリクスを追加してもよいですが、古いメトリクスを削除しないでください。
  2. メトリクスごとに1文のコンテキスト。 このメトリクスは何を教えてくれるのか? 良いか悪いか? その含意は?
  3. 実績と計画、常に。 計画なしでメトリクスを示さないでください。差分が会話です。
  4. 必要に応じて分解する。 総使用量はセグメントを隠す。顧客タイプ、セグメント、製品ラインで分解する — 平均が現実を覆い隠すところならどこでも。
  5. ヘルス・インジケーターを使用する。 取締役会の迅速な評価のための緑/黄/赤ステータス。取締役会がダッシュボードをスキャンして黄色と赤をズームインできます。

よくある間違い:

今四半期どのメトリクスが良く見えるかに基づいてどのメトリクスを表示するかを変更する。取締役会はすぐに気づきます。それはあなたの数字への信頼を失う最速の方法です。毎回同じダッシュボードを示します — メトリクスが悪く見える場合、それが会話です。


5. 取締役会が尋ねる前に悪いニュースを伝える

パターン:

悪いニュースが遅延または砂糖塗りされると、取締役会の信頼は低下します。彼らは悪いニュースに対処できます。彼らはサプライズに対処できません。そして、彼らは意思決定が遅いのを嫌います。

事前説明パターン:

悪いニュースが取締役会全体に達する前に、会議の48~72時間前にあなたのリード・ディレクターに事前説明します。

  • 誰: 取締役会会長または最も経験豊富なディレクター
  • 何: その問題、あなたの評価、あなたの計画
  • なぜ: ディレクターは取締役会全体へのフレーミングを支援し、サプライズ・ショックを回避し、このパターンを前に見ている可能性があります

その後、短いメールを取締役会全体に送信します:

「次の会議の前にフラグを立てたいと思います。[具体的な問題]。これまでに知っていることは、まだ知らないことは、それについて何をしているかはこちらです。次の取締役会会議で詳細をお知らせします。」

悪いニュース・フレームワーク:

悪いニュースの各部分について、4つの要素:

  1. 何が起きたか(防御的ではなく、1文)

    • 「Q1 の新規エンタープライズ顧客の目標は 10 社でしたが、7 社を達成しました」
  2. なぜそれが起きたか(言い訳ではなく、根本原因)

    • 「顧客の評価タイムラインが製品ギャップによってずれたもので、早期に診断できませんでした」
    • 所有する: 「市場が変わった」ではなく「需要信号を誤読しました」
  3. その影響は何か(重大性について正直に)

    • 「Q1 ARR に約 $50K の影響を与え、当初のガイダンスを下回ります」
  4. それについて何をしているのか(約束ではなく、具体的なアクション、実行責任者、タイムライン)

    • 「セールスモーションを変更し、製品準備状況に基づいて事前に適格性を確認; Q2 の目標を(Q1 のバックログ 7 件を含む)15 件に改訂」

ミスをコミュニケーションする方法ではなく:

  • 「Q1 の目標に達しませんでしたが、パイプラインは強いです」
  • 「外的要因が取引を遅くしましたが、Q2 について自信があります」
  • 「実装上の課題がありましたが、今は解決しています」

すべて曖昧。すべて防御的。根本原因や計画を説明していません。

フォロースルー・パターン:

その後のすべての取締役会アップデートは、以前に提起された問題を参照する必要があります: 「前期、私は [問題] をフラグしました。これはアップデートです: [進捗]。ステータス: [解決 / 進行中 / エスカレート中]。」

これは自分の問題を追跡するフォロースルーの記録を構築します。取締役会は自分たちの問題を追跡する人を覚えています。

よくある間違い:

悪いニュースを誰も気づかないことを願って良いニュースの間に挟み込む。取締役会メンバーはこれをすぐに見ます。悪いニュース自体よりも信頼を損ないます。


6. 月次インベスター・アップデート

パターン:

ほとんどのファウンダーは最高でも四半期ごとにインベスター・アップデートを送ります。最高のファウンダーは月次で送ります — 物事が悪い場合でも。特に物事が悪い場合。

月次の理由:

  • スケジュール呼び出しなしでインベスターを関与させ続ける
  • ヘルプが必要な場合(紹介、アドバイス、ブリッジ)、インベスターはすでにコンテキストを持っています
  • 一貫性は運営規律を示す; 不規則なアップデートは混乱を示す

形式:

件名: [会社名] — [月] アップデート

オープニング(1段落): 1つの見出し。簡潔なコンテキスト。

TL;DR(3つのポイント):

  • 1つの数字(今最も重要なメトリク)
  • 1つの勝利(具体的 — 顧客名、取引規模、マイルストーン)
  • 1つの課題(それについて何をしているのか)

主要メトリクス(毎月同じテーブル):

メトリク今月先月3ヶ月平均vs 計画
ARR
MRR 成長
バーン率
ランウェイ(月)
パイプライン
顧客数

前回のアップデート以降変わっていないメトリクスは含めないでください — 新しいものに焦点を当てます。

主要アップデート(2~3のポイント):

  • 主要な採用、製品ローンチ、パートナーシップ/顧客の勝利
  • 戦略的なピボットやコース修正
  • 重要な程度に具体的

依頼事項(1~2のポイント):

  • どのようなヘルプが必要ですか? 紹介、採用リード、戦略的アドバイス
  • 具体的に: 「[企業タイプ] の VP Eng への紹介を探しています」ではなく「エンジニアリング人材を探しています」

ケイデンス・ルール:

  • 毎月同じ日。月初の月曜日、金曜日最後 — 1つを選んで決してミスしない
  • 主要なニュースがある場合は1週間以内に送信(次の定期的なアップデートまで待つ必要がなし)
  • アクティブな資金調達中: 温かいインベスターへの週次アップデート、既存インベスターへの月次

よくある間違い:

物事が良い場合にのみアップデートを送ります。6ヶ月の良いニュースに続く沈黙は、インベスターに正確に何を言わないでいるのかを伝えます。


7. バーンは規律について; 収益は牽引力について

パターン:

取締役会への財務コミュニケーションは2つの別々のストーリーを持っています。これらを混ぜないでください。

バーン・コミュニケーション:

  • 月次レート、月単位のランウェイ、年間の改善
  • 効率性向上(何をカットしましたか、何を最適化しましたか?)
  • 資本計画: 何が確保されているか、何がターゲットか、タイムラインは何か

バーンのストーリーは: 「私たちは資本をさらに進める規律のある運営者です。」

収益コミュニケーション:

  • 月月増加、CAC、LTV、返済期間
  • 顧客セグメンテーション(セルフサーブ対エンタープライズ、ミックスは何か?)
  • タイムラインを伴う収益化計画

収益のストーリーは: 「私たちは牽引力を持っており、それを成長させる方法を知っています。」

両方を調整: 最高の財務コミュニケーションは次を示します: 「私たちはバーンは少なくなっていますが、より速く成長しています。」これは運営レバレッジの証拠であり、これは取締役会が聞くことができる最も説得力のあるただ1つのことです。

よくある間違い:

バーンを成長と混同する。「私たちは急速に成長しています」と聞く取締役会がバーンレートの上昇を聞くと、あなたは成長を買っていると思います。「バーンを 40% カットしました」と聞く取締役会が成長の停滞を聞くと、あなたはサバイバル・モードにいると思います。両方のストーリーを別々に、そして次にそれらを接続してください。


8. 取締役会から組織へ戦略をカスケードする

パターン:

取締役会室で決定された戦略は、チームがそれを知らない場合は重要ではありません。体系的な通信カスケードを作成します。

4つのレベル:

レベル1: 経営陣(週次)

  • 戦略的優先事項と出現するリスク
  • 調整が必要な主要な決定

レベル2: 拡大リーダーシップ(隔週)

  • 戦略が各機能に与える影響
  • 主要な優先事項と成功がどのように測定されるか

レベル3: 全社(月次、60分)

  • リーダーシップアップデート(15分): 私たちがいる場所、何が変わったか
  • 勝利祝い(10分): 顧客、ローンチ、人
  • 深掘り(20分): 1つの戦略イニシアチブの詳細
  • Q&A(15分): 実際の質問、実際の回答

レベル4: チーム別(継続的)

  • チーム目標が企業戦略にどのように接続するか
  • このチームの成功が具体的に何を意味するか

テスト:

ランダムに従業員を1人選ぶ。企業戦略を説明できますか? そうでない場合、カスケードが壊れています。実行幹部の頭の中にのみ存在する戦略は戦略ではありません — それは秘密です。

OKR をカスケードに接続:

  • 戦略からの企業 OKR
  • 企業に調整された機能 OKR
  • 機能に調整されたチーム OKR
  • 個人は自分たちがどのように貢献するかを理解します

よくある間違い:

一貫性のないメッセージ。異なるリーダーが会社がどこへ向かっているかについて異なるストーリーを伝える場合、組織は矛盾する目標に最適化します。戦略を書き留める。1ページ。誰もが同じ言葉を使うようにします。


意思決定ツリー

取締役会会議対インベスター・アップデート

これは取締役会の完全な会議ですか?
├─ はい → 完全な構造: 事前資料 + 三つのこと + 決定 + 深掘り
└─ いいえ → 続行...
    │
    これは主要なイベント(資金調達クローズ、大きなミス、主要な採用)ですか?
    ├─ はい → すぐにアドホック・アップデート(スケジュールを待たない)
    └─ いいえ → 月次インベスター・アップデート形式

メトリクスのフレーミング方法

ターゲットを達成しましたか?
├─ はい → それを述べる、進む。過剰に祝わない。
└─ いいえ → 続行...
    │
    なぜそれが起きたのかを理解していますか?
    ├─ はい → 根本原因 + 計画 + 改訂タイムライン
    └─ いいえ → 「診断中」と言う + 見つけるために何をしているか
        │
        ミスは重大ですか(ランウェイ、戦略、または取締役会の信頼に影響)?
        ├─ はい → 取締役会会議の前にリード・ディレクターに事前説明
        └─ いいえ → 三つのもののナレーティブに含める、「うまくいっていないこと」

よくある間違い

1. ステータス・レポートとしての取締役会会議 取締役会メンバーは読むことができます。事前資料を送ります。データウォークスルーではなく、決定と議論に会議を使用します。

2. 毎四半期メトリクスを変更 メトリクスの一貫性は信頼を構築します。悪く見えるメトリクスを良く見えるメトリクスに入れ替える瞬間、あなたは取締役会にあなたの数字は信頼できないと言ったのです。

3. 明確な依頼事項がない すべてのインベスター・アップデート、すべての取締役会会議は依頼事項を持つべきです。紹介、アドバイス、承認、忍耐力。インベスターは支援したいと考えています — 尋ねない場合、彼らは関与を辞めます。

4. 説明する代わりに防御する ミスを10分間説明しているとき、取締役会は防御性を聞きます。ミスを述べ、原因を述べ、計画を述べます。進む。

5. 戦略は取締役会室に留まる チームが戦略を説明できない場合、それはコミュニケーションしていません。カスケードするか、それは存在しません。

6. 取締役会会議でのサプライズ 悪いニュースは取締役会会議に初めて着地してはいけません。リード・ディレクターに事前説明。取締役会全体に旗のメールを送信。会議の前に取締役会が処理する。


クイック・リファレンス

取締役会会議の流れ: 事前資料(48~72時間前) → 質問(15分) → 三つのことのナレーティブ(15分) → 意思決定案件(30~45分) → 深掘り(20~30分) → 非公開セッション(10分)

三つのことのモデル: うまくいっていることは何か + うまくいっていないことは何か + それについて何をするのか

メトリク・ヒエラルキー: 北極星(1) → ドライバー(3~5) → ヘルス(3~5) → レッド・フラグ(2~3のしきい値)

悪いニュース・プロトコル: リード・ディレクターに事前説明(48~72時間) → 取締役会全体に旗のメール → 何が起きたか → なぜ → 影響 → 計画 → その後の毎回の会議をフォロー・アップ

月次インベスター・アップデート: TL;DR(3つのポイント) → 同じメトリク・テーブル → 主要アップデート(2~3) → 具体的な依頼事項(1~2)

通信カスケード: 経営陣(週次) → リーダーシップ(隔週) → 全社(月次) → チーム(継続的)


関連スキル

  • operating-cadence: 取締役会準備に有益な内部会議リズム
  • enterprise-account-planning: 取締役会報告のためのパイプラインと取引メトリクス
  • technical-product-pricing: 取締役会入力が必要な価格決定

複数の企業でシリーズAからIPO後まで取締役会コミュニケーションを準備・サポートした経験に基づく — 1つのデッキを構築し、複数で会議に出席し、他の人は取締役会にアップデートを報告しました。信頼を逃したセッション全体にわたって信頼を維持していた月次インベスター・アップデート・ケイデンス、複数の企業で使用されていた「三つのこと」ナレーティブ・モデル、および急激な成長を生き残ったメトリク・規律フレームワークが含まれます。理論ではなく — 何が取締役会に着地し、何がしないかを見るのに十分近い実行パターン。

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
github
リポジトリ
github/awesome-copilot
ライセンス
MIT
最終更新
不明

Source: https://github.com/github/awesome-copilot / ライセンス: MIT

関連スキル

OpenAILLM・AI開発⭐ リポ 6,054

agent-browser

AI エージェント向けのブラウザ自動化 CLI です。ウェブサイトとの対話が必要な場合に使用します。ページ遷移、フォーム入力、ボタンクリック、スクリーンショット取得、データ抽出、ウェブアプリのテスト、ブラウザ操作の自動化など、あらゆるブラウザタスクに対応できます。「ウェブサイトを開く」「フォームに記入する」「ボタンをクリックする」「スクリーンショットを取得する」「ページからデータを抽出する」「このウェブアプリをテストする」「サイトにログインする」「ブラウザ操作を自動化する」といった要求や、プログラマティックなウェブ操作が必要なタスクで起動します。

by JimmyLv
汎用LLM・AI開発⭐ リポ 1,982

anyskill

AnySkill — あなたのプライベート・スキルクラウド。GitHubを基盤としたリポジトリからエージェントスキルを管理、同期、動的にロードできます。自然言語でクラウドスキルを検索し、オンデマンドでプロンプトを自動ロード、カスタムスキルのアップロードと共有、スキルバンドルの一括インストールが可能です。OpenClaw、Antigravity、Claude Code、Cursorに対応しています。

by LeoYeAI
汎用LLM・AI開発⭐ リポ 1,982

engram

AIエージェント向けの永続的なメモリシステムです。バグ修正、意思決定、発見、設定変更の後はmem_saveを使用してください。ユーザーが「覚えている」「記憶している」と言及した場合、または以前のセッションと重複する作業を開始する際はmem_searchを使用します。セッション終了前にmem_session_summaryを使用して、コンテキストを保持してください。

by LeoYeAI
汎用LLM・AI開発⭐ リポ 21,584

skyvern

AI駆動のブラウザ自動化により、任意のウェブサイトを自動化できます。フォーム入力、データ抽出、ファイルダウンロード、ログイン、複数ステップのワークフロー実行など、ユーザーがウェブサイトと連携する必要があるときに使用します。Skyvernは、LLMとコンピュータビジョンを活用して、未知のサイトも自動操作可能です。Python SDK、TypeScript SDK、REST API、MCPサーバー、またはCLIを通じて統合できます。

by Skyvern-AI
汎用LLM・AI開発⭐ リポ 1,149

pinchbench

PinchBenchベンチマークを実行して、OpenClawエージェントの実世界タスクにおけるパフォーマンスを評価できます。モデルの機能テスト、モデル間の比較、ベンチマーク結果のリーダーボード提出、またはOpenClawのセットアップがカレンダー、メール、リサーチ、コーディング、複数ステップのワークフローにどの程度対応しているかを確認する際に使用します。

by pinchbench
汎用LLM・AI開発⭐ リポ 4,693

openui

OpenUIとOpenUI Langを使用してジェネレーティブUIアプリを構築できます。これらはLLM生成インターフェースのためのトークン効率的なオープン標準です。OpenUI、@openuidev、ジェネレーティブUI、LLMからのストリーミングUI、AI向けコンポーネントライブラリ、またはjson-render/A2UIの置き換えについて述べる際に使用します。スキャフォルディング、defineComponent、システムプロンプト、Renderer、およびOpenUI Lang出力のデバッグに対応しています。

by thesysdev
本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: github · github/awesome-copilot · ライセンス: MIT