使い方ガイドへスキップ
Design System Governance作者 owl-listener

Design System Governance スキル。

チームが共通デザインシステムに貢献し、発展させる方法を定義します。

  • デザインシステム
  • ガバナンス
ソースレビュー · design-system-governanceSKILL.md
タスク チームが共通デザインシステムに貢献し、発展させる方法を定義します。 成果物 参加チームに合った責任分担と貢献モデル。 始める前に このスキルはモデルを起草できますが、権限と責任分担は実際の組織に即している必要があります。
記事用の要約 · ソース確認日 2026-11-02 · 生成された例ではありません

01 機能概要

チームが共通デザインシステムに貢献し、発展させる方法を定義します

複数の製品チームが利用するデザインシステムの責任分担、貢献レビュー、バージョン管理、非推奨化のルールを定義します。

ソースに基づくワークフロー実行ベンチマークではありません

作業の進め方

Design System Governance は、複数チームの貢献があっても共通コンポーネント体系の一貫性を保つプロセスを定義します。責任分担、提案、レビュー、リリース、破壊的変更、非推奨化を扱います。誰がシステムを変更でき、利用側がその変更をどう知るかという課題に役立ちます。

ソースは集中型、連邦型、混合型の責任モデルを比較し、依頼から周知までの貢献ライフサイクルを示します。リリースの種類も利用側への影響に結び付けます。成果物は、品質基準と移行の期待事項を明示した、システム運用の合意書です。

想定される成果物

  • 参加チームに合った責任分担と貢献モデル。
  • レビューと品質要件を備えた、提案からリリースまでのプロセス。
  • 利用側に向けたバージョン管理、非推奨化、破壊的変更の方針。
サンプルブリーフを見る

ブリーフからレビューまで

  1. 01
    責任の境界を選ぶ

    基盤の保守担当と、領域固有のコンポーネントの貢献担当を明確にします。実際のチームの対応能力に照らして、集中型・連邦型・混合型を比較します。

  2. 02
    貢献のライフサイクルを定義する

    依頼、トリアージ、設計、レビュー、実装、リリース、周知の段階を定めます。新しいコンポーネントの受け入れ前に、再利用の確認とアクセシビリティレビューを含めます。

  3. 03
    利用側に向けた変更ルールを設ける

    パッチ・マイナー・メジャーのリリース、変更履歴、移行ガイドの要件を定義します。非推奨のコンポーネントを移行期間中も利用できる仕組みを説明します。

  4. 04
    合意を公開し維持する

    品質要件と参加経路を文書化します。貢献者の意見とコンポーネントの採用状況に基づいて、プロセスを見直します。

02 利用場面

使いどころ

このスキルはモデルを起草できますが、権限と責任分担は実際の組織に即している必要があります。

向いているケース

  • 複数チームでコンポーネントを共有貢献者に明確な責任と一貫した変更経路が必要な場合。
  • 破壊的変更による混乱利用側に予測可能なリリース告知と移行の期待事項が必要な場合。

確認すべき制限

  • 組織上の意思決定このスキルはモデルを起草できますが、権限と責任分担は実際の組織に即している必要があります。
  • 導入促進は別の作業ソースは採用戦略を design-system-adoption に委ねています。
  • 方針は実装ではないリリース手順を文書化しても、それだけでコンポーネントが公開されたり検査が強制されたりするわけではありません。

用意する入力

  • チーム構成保守担当、貢献者、利用チームを示します。
  • 現行システムコンポーネントの責任分担、リリース慣行、文書の不足を提供します。
  • 変更の制約互換性要件、移行に割ける人員・時間、期待するレビュー基準を含めます。

03 重要な判断

重要な判断

  1. 明確な参加方法

    提案したコンポーネントがどうレビューされるかをチームが把握できます。

  2. 予測可能な変更

    バージョンと非推奨化のルールが、利用側の対応事項を示します。

  3. 共通の品質水準

    文書、トークン使用、アクセシビリティへの期待を明示します。

04 依頼例

目的を絞った依頼文を試す

以下のサンプルブリーフはテストされていません。使用前にスキルのセットアップを確認してください。

ソースとセットアップを確認する

保守担当、貢献者、利用チームを示します。

アップストリームのソースファイル
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-systems/skills/design-system-governance/SKILL.md

以下の参照先から、提供元の手順を確認できます。利用前にリポジトリのセットアップ要件を確認してください。これはインストールコマンドではありません。

一つの成果物から始める

スキルを実行する前に、このブリーフの範囲、素材、制約を調整してください。

サンプルブリーフ
design-system-governance を使い、共通 UI ライブラリーの運用モデルを起草してください。小さなコアチームと、領域固有のコンポーネントを必要とする3つの製品チームがあります。責任モデルを比較し、基盤と拡張の境界を明確に提案してください。アクセシビリティとトークン要件を含め、依頼・レビュー・リリースのライフサイクルを定義してください。利用側の移行要件とともに、セマンティックバージョニングと非推奨化のルールを提案してください。担当者や日付を創作せず、チーム合意が必要な決定を示してください。実用的な貢献ガイドと、未解決の方針選択肢の別リストを納品してください。

結果を確認する

実際の出力を、次の観察可能な基準に照らして確認してください。

  • 責任と決定権限が架空の役割ではなく実際のチームに対応している。
  • リリース・非推奨化ルールに利用側の期待事項が書かれている。
  • 品質要件を確認する段階が貢献プロセスに定義されている。

OpenDesignは、コーディングエージェント向けのローカルデザインワークスペースを提供します。この掲載は、スキルが同梱されていること、または外部ツール、認証情報、ソフトウェア依存関係が含まれていることを意味しません。

05 ソースとライセンス

ソースとライセンス

このページは、下記にリンクされた固定のソースリビジョンについて説明しています。アップストリームの挙動や要件は変更される可能性があります。

ソースの所有者
owl-listener
スキルファイル
SKILL.md
ライセンス
MIT
確認したスナップショット
2026-11-02 · 9a6930cf84a8
編集部によるソース要約
チームが共通デザインシステムに貢献し、発展させる方法を定義します。

リンク先のソースに基づく、OpenDesignによるオリジナルの要約です。リポジトリのスター数は日付時点の人気の指標であり、スキルの利用状況や品質スコアではありません。

06 開始前の質問

始める前の質問

1つの中央チームがすべてを担当する必要がありますか?

いいえ。ソースは集中型、連邦型、混合型のモデルを比較します。

破壊的変更には何を添える必要がありますか?

ソースは移行経路、変更履歴での説明、移行文書を求め、必要に応じて互換性支援も検討します。

コンポーネントの品質も対象ですか?

はい。状態と props の文書化、アクセシビリティレビュー、レスポンシブ動作、トークン使用、デザインファイルとコードの整合性を含みます。

OpenDesign

依頼内容とデザイン作業を一つの場所に。

ブリーフ、ソース資料、デザイン作業をローカルワークスペースにまとめて管理できます。ワークフローに追加する前に、スキル自体のセットアップを確認してください。

アップストリームのソースファイル
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-systems/skills/design-system-governance/SKILL.md