跳转到使用指南
Design System Governance作者 owl-listener

Design System Governance Skill.

明确团队如何参与共享设计系统,并推动其演进。

  • 设计系统
  • 治理
源文件解读 · design-system-governanceSKILL.md
任务 明确团队如何参与共享设计系统,并推动其演进。 产出 适合参与团队的责任归属和贡献模型。 开始前的准备 该 skill 可以起草模型,但权限和责任归属必须符合真实组织情况。
编辑摘要 · 源文件核查于 2026-11-02 · 非生成示例

01 功能说明

明确团队如何参与共享设计系统,并推动其演进

为多个产品团队共用的设计系统明确责任归属、贡献评审、版本管理和弃用规则。

基于来源的工作流并非执行基准测试

工作方法

Design System Governance 定义多个团队参与时保持共享组件系统一致性的流程,涵盖责任归属、提案、评审、发布、破坏性变更和弃用。当问题是“谁能修改系统,使用方如何获知变更”时,这个 skill 就能发挥作用。

源文件比较集中式、联邦式和混合式责任模型,再勾勒从提出请求到沟通发布的贡献生命周期。它还将发布类型与对使用方的影响关联起来。产出是一份系统运作约定,明确质量标准和迁移预期。

预期交付物

  • 适合参与团队的责任归属和贡献模型。
  • 包含评审与质量要求、从提案到发布的流程。
  • 面向使用方的版本管理、弃用和破坏性变更政策。
查看示例简报

从简报到审查

  1. 01
    划定职责边界

    明确基础部分由谁维护,业务领域组件由谁贡献。结合团队真实承载能力,比较集中式、联邦式和混合式模型。

  2. 02
    定义贡献生命周期

    规定请求、分流、设计、评审、实现、发布和沟通步骤。接纳新组件之前,加入复用检查和无障碍评审。

  3. 03
    制定面向使用方的变更规则

    定义补丁、次版本和主版本发布,明确变更日志与迁移指南要求。说明被弃用组件如何在过渡期继续可用。

  4. 04
    发布并维护约定

    记录质量要求和参与途径。根据贡献者反馈及组件采用信息,重新审视流程。

02 适用场景

适合什么场景

该 skill 可以起草模型,但权限和责任归属必须符合真实组织情况。

适合的场景

  • 多个团队共享组件贡献者需要明确职责和一致的变更路径。
  • 破坏性变更带来混乱使用方需要可预期的发布沟通和迁移要求。

需要检查的限制

  • 组织层面的决策该 skill 可以起草模型,但权限和责任归属必须符合真实组织情况。
  • 采用推广另行处理源文件将采用策略交给 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 库起草运作模型。我们有一个小型核心团队,以及需要业务领域组件的三个产品团队。比较责任归属方案,建议基础部分与扩展部分的清晰边界。定义请求、评审和发布生命周期,包括无障碍和设计变量要求。提出语义化版本与弃用规则,说明使用方的迁移预期。指出需要团队达成一致的决策,不要编造负责人或日期。交付实用的贡献指南,并单独列出尚未决定的政策选项。

检查结果

根据以下可观察标准检查实际输出。

  • 责任归属和决策权限对应真实团队,而非虚构角色。
  • 发布和弃用规则说明使用方可以预期什么。
  • 质量要求在贡献流程中有明确评审节点。

OpenDesign 为编码智能体提供本地设计工作区。此条目并不表示该技能已内置,也不表示其中包含其外部工具、凭据和软件依赖项。

05 来源与许可证

来源与许可证

本页面描述的是下方链接所指向的固定来源修订版本。上游行为和要求可能会发生变化。

来源所有者
owl-listener
技能文件
SKILL.md
许可证
MIT
已审查的快照
2026-11-02 · 9a6930cf84a8
编辑来源摘要
明确团队如何参与共享设计系统,并推动其演进。

由 OpenDesign 根据所链接来源撰写的原创摘要。仓库星标数只是带有时间属性的受欢迎程度指标,并不代表技能使用量或质量评分。

06 开始前的问题

开始前可能想问

必须由一个中央团队负责全部内容吗?

不必。源文件比较了集中式、联邦式和混合式模型。

破坏性变更需要附带什么?

源文件要求迁移路径、变更日志说明和迁移文档,并在必要时考虑兼容性支持。

它包含组件质量吗?

包含。范围涵盖已记录的状态和 props、无障碍评审、响应式行为、设计变量使用,以及设计文件与代码的一致性。

OpenDesign

让需求和设计工作保存在一起。

将简报、来源材料和设计工作集中保存在本地工作区中。将该技能添加到工作流程前,请检查其自身的设置说明。

上游源文件
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-systems/skills/design-system-governance/SKILL.md