mcpField
R
run-ui-registry-variations

run-ui-registry-variations

github.com/darkmatter设计与 UI0264 次安装6 天前更新
代码仓库

关于 run-ui-registry-variations

面向 UI 任务的手动工作流技能，要求基于获准的组件注册表提供方案。它会先验证注册表访问权限，再构建三个可运行的变体供比较，选定默认界面前不替换现有方案。

主要功能

  1. 01验证注册表访问权限
  2. 02构建三个可运行的 UI 变体
  3. 03仅使用获准的注册表
  4. 04变体共享业务逻辑
  5. 05提供桌面与移动端验证指引
  6. 06标明变体组件来源

适用场景

  1. 01比较基于注册表的 UI 方案
  2. 02为一次性界面创建多个选项
  3. 03为没有设计系统的项目制作方案

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/darkmatter/skills --skill run-ui-registry-variations

安装后在 Claude Code 中输入/run-ui-registry-variations确认已加载。

附带文件reference/variation-template.mdscripts/validate-registry-access.ts

详细介绍

run-ui-registry-variations

用于 UI 工作的手动工作流：必须从经过批准的组件注册表开始，而不是手写界面代码。该技能会严格限制注册表访问，然后构建三个真实方案供用户比较。

适用场景

  • /run-ui-registry-variations <UI request>
  • 用户明确说出 run-ui-registry-variations。
  • 用户要求使用 shadcnblocks、Aceternity 或 Darkmatter shadcn 注册表提供三个 UI 方案。
  • 用户想制作一次性 UI、新建没有设计系统的项目界面，或 darkmatter.io 界面，并希望获得基于注册表的方案。

不适用场景

  • 用户只问该使用哪个注册表。直接回答或使用 ui-ux-pro-max。
  • 项目是有自身设计系统的旗舰应用，且用户没有明确调用此技能。
  • 任务涉及后端、基础设施、文案或非视觉内容。
  • 用户只要求一个最终实现，不需要备选方案。

约定

  1. 视觉结构只能使用以下组件来源：shadcnblocks、Aceternity 或 https://shadcn.darkmatter.io。
  2. 使用来源前，先验证注册表访问权限。shadcnblocks 和 Aceternity 需要验证 API 密钥／令牌；shadcn.darkmatter.io 需要进行实时抓取检查。
  3. 必须恰好构建三个方案。不要只提供描述或情绪板。
  4. 替换默认 UI 路径之前，先向用户展示全部三个方案。
  5. 保护机密信息。切勿输出 API 密钥、解密后的注册表配置、包含令牌的私有 URL，或生成的明文凭据文件。
  6. 不要用未经批准的组件来源凑数。如果某个来源未通过验证，请改用其他已验证的允许来源，或停止。

工作流

1. 确定目标范围

确定目标路由、组件、页面或原型界面。如果应用已有设计系统，先阅读并确保各方案与之兼容。

对于没有设计系统的 Darkmatter 工作、darkmatter.io 和一次性 UI，默认将 https://shadcn.darkmatter.io 作为基础视觉风格。

2. 查找注册表配置

按以下顺序检查可能的来源：

  1. 项目文档中的注册表设置。
  2. components.sops.json、secrets/*.sops.json 或其他加密的项目配置。
  3. 明文 components.json、.env.local、.env 或 package 脚本。

如果存在加密配置，请使用 sops-secret-access。只解密必要内容，优先使用管道或临时文件，并且不要输出解密后的内容。

可查找的常见私有令牌名称，但不要假设此列表包含所有名称：

  • SHADCNBLOCKS_API_KEY、SHADCNBLOCKS_TOKEN、SHADCNBLOCKS_REGISTRY_TOKEN
  • ACETERNITY_API_KEY、ACETERNITY_TOKEN、ACETERNITY_REGISTRY_TOKEN
3. 验证访问权限

始终尝试对 shadcnblocks 和 Aceternity 进行私有提供方预检，即使可能回退使用 shadcn.darkmatter.io。如果私有提供方没有可用密钥，请将该提供方标记为受阻，并且不要使用它。

针对每个计划使用的来源：

  • shadcnblocks：确认 API 密钥／令牌存在，并通过经过身份验证的注册表请求证明其有效。
  • Aceternity：确认 API 密钥／令牌存在，并通过经过身份验证的注册表请求证明其有效。
  • shadcn.darkmatter.io：使用 curl 或项目的注册表工具确认可以访问注册表端点。

当已知注册表 URL 和环境变量名称时，使用 bun scripts/validate-registry-access.ts（此技能自带的副本）。如果项目使用自定义注册表工具，请运行能够抓取注册表索引或一个已知组件的最小只读命令。

如果某个私有提供方未通过验证，不要在任何方案中使用该提供方。可以继续使用任何已验证的允许来源；如果没有允许的来源通过验证，则停止并报告受阻的提供方检查结果。

4. 选择组件

每个变体都必须注明所引用的源注册表，以及所使用的具体组件/区块。如果所有来源均可用，优先使用三个不同的来源：

  1. 变体 A：shadcnblocks
  2. 变体 B：Aceternity
  3. 变体 C：shadcn.darkmatter.io

如果只有一个或两个来源通过验证，仍需构建三个变体，但所有视觉结构都必须来自通过验证的允许来源集合。

5. 构建三个变体

创建实际的代码产物，而不只是文字说明：

  • 使用独立的组件文件、命名清晰的导出、预览路由、标签页、Storybook stories，或其他本地模式，让用户可以比较这三个变体。
  • 共享数据契约和业务逻辑；让布局、信息密度、交互方式和视觉重点有所不同。
  • 在用户做出选择之前，不要将任何一个变体设为最终默认方案。
  • 避免使用未经封装的自定义 Tailwind 外壳，除非它们用于包裹或组合注册表组件。
6. 验证并展示

针对修改的部分运行应用的常规前端检查。如果可以进行浏览器预览，请在桌面和移动设备宽度下截取或检查全部三个变体。

使用 reference/variation-template.md 展示结果。包括：

  • shadcnblocks、Aceternity 和 shadcn.darkmatter.io 的验证状态。
  • 每个变体使用的源注册表和组件。
  • 供审阅的本地路径/路由。
  • 任何受阻的提供方及非机密原因。

工具

scripts/validate-registry-access.ts

验证注册表端点是否可访问；可选择使用环境变量中的令牌，且不会打印令牌。

bun skills/run-ui-registry-variations/scripts/validate-registry-access.ts \
  shadcnblocks "$SHADCNBLOCKS_REGISTRY_URL" SHADCNBLOCKS_API_KEY

bun skills/run-ui-registry-variations/scripts/validate-registry-access.ts \
  aceternity "$ACETERNITY_REGISTRY_URL" ACETERNITY_API_KEY

bun skills/run-ui-registry-variations/scripts/validate-registry-access.ts \
  shadcn-darkmatter https://shadcn.darkmatter.io

依赖项： Bun（fetch）。如果令牌存储在 SOPS 中，请先通过项目批准的 SOPS 路径将其载入环境变量。

参考资料

  • reference/variation-template.md — 展示三个变体和提供方验证证据的输出格式。

评论

支持 Markdown