关于 component-scaffolder
为 Datex Studio 新组件提供脚手架路由，依据类型选择文件后缀、configurationTypeId、规范骨架及后续 creator skill。它负责分派与创建最小有效组件，不负责组件主体编写。
主要功能
- 01按组件类型分派创建器
- 02查找后缀与 configurationTypeId
- 03使用规范骨架创建组件
- 04检查分支冲突并验证后写入
- 05将后续编写交给对应 skill
适用场景
- 01在 Datex Studio 分支启动新组件
- 02确认组件类型对应的文件与配置 ID
- 03创建空白有效组件后继续完善
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/component-scaffolder确认已加载。
详细介绍
组件脚手架
根据有文档记录的骨架，为 Datex Studio 搭建新组件。此技能是“我需要开始创建一个新的 组件”的路由层。它会将请求的组件类型映射到：
- 文件后缀（附加在
referenceName上）。 configurationTypeId数字 ID。- 规范的最小有效骨架（来源于匹配的创建器技能中的
references/<type>.md）。 - 用于接手实际主体编写工作的匹配创建器技能。
创建器技能（action-creator、function-creator、grid-creator 等）负责编写各自组件类型的内容。此技能负责分发决策——选择哪个后缀、哪个 cti、哪个骨架文档、哪个创建器技能——这样就不会在每个创建器技能中重复路由逻辑。分支是事实来源；脚手架工具绝不会写入本地 src/ 树。
参考资料
- ../datex-studio-conventions/file-format.md — 规范的
configurationTypeId表、文件后缀规则，以及 cti 错误导致的故障模式。 - 每个创建器技能的
references/<type>.md— 对应组件类型的规范最小有效骨架。切勿凭记忆编造 JSON 结构；务必查阅匹配的参考文档。
工作流程
-
收集三个必需的输入：
- 类型 — 以下之一：
action、function、interface、enum、grid、hub、form、editor、embed、selector、storage、backendTest、datasource（OData 或 flow 查询类型，平台变体）、footprintDatasource（OData 或 flow 查询类型，Footprint 变体）。如果调用方只说了“datasource”，没有说明变体，请询问他们需要哪种变体（平台-datasource还是 Footprint-footprintDatasource）——它们对应不同的configurationTypeId，也是不同的组件变体。完整分类请参阅 datasource-creator/references/datasources.md。 - 名称 — 组件引用名称（不含文件后缀）。根据 ../datex-studio-conventions/naming-conventions.md，在名称本身上附加类型标识：
_storage、_hub、_form、_editor、_embed、_grid、选择器用_dd、_action、函数用_flow、接口使用i_前缀、枚举使用e_前缀。 - 描述 — 非 null、非空，且不超过 100 个字符。这是 Footprint 端 SQL 列的硬性上限——超过限制时，导入会因 SQL 截断错误而失败。如果调用方未提供描述，请向其索取；没有描述不得继续。
- 类型 — 以下之一：
-
在下表中查找分发对应行，了解该类型的后缀、
configurationTypeId、包含规范骨架的参考文档，以及下一步要委派任务的创建器技能。 -
从指定文档中读取规范骨架。不要猜测 JSON 结构。参考文档是骨架结构的权威来源（也包含各类型的特定细节，例如选择器和数据源的组件变体规则、后端测试的钩子流布局）。
-
应用骨架：
referenceName→ 组件名称。（例外：actions —referenceName以_action结尾，而文件后缀为-footprintFlow.json。创建者与名称的配对是有意为之；请参阅 action-creator/references/actions.md。）title→ 对于后端类型（function、action、datasource、footprintDatasource、interface、enum、storage、backendTest），标题不会显示在屏幕上，因此将其设为与referenceName相同。对于面向用户的类型（form、editor、hub、grid、embed 和独立选择器），title会显示为页眉 / 对话框标题 / 标签，因此必须是不同的句式大小写显示名称 — 根据名称推导一个（例如，custom_example_map_embed→Example map），或询问调用者。若title与referenceName的字节内容完全相同，则根据 ../datex-studio-conventions/naming-conventions.md → 面向用户组件的显示名称，属于命名违规。description→ 调用者提供的描述（≤100 个字符）。accessModifier→ 询问调用者；如果对方没有偏好，则默认为"public"。configurationTypeId→ 调度表中的数字 ID。如有任何疑问，请从同类型的可用组件中复制；错误的 cti 会导致 Validate 成功但 Preview 失败（请参阅 ../datex-studio-conventions/file-format.md）。- 所有其他字段 → 骨架默认值（空数组、null 等）。除最小有效骨架所需内容外，不要预填占位属性、筛选器或代码。
-
检查分支上的冲突。 分支（而不是本地工作树）是判断现有内容的准则。使用
dxs configuration get <type> <referenceName> -b <branchId>探查分支。404（DXS-404-001）表示名称可用；任何命中都表示组件已存在 → 停止并报告，不要覆盖。调用者可能想换一个名称，也可能想修改现有组件（这是创建器技能的工作，而不是脚手架工具的工作）。 -
将骨架写入临时
body.json。 此本地文件仅用于临时存储；系统记录以分支为准，而不是文件。调用者保留的任何本地工作副本都只是便捷镜像，绝不能作为事实来源。 -
先验证，再通过 dxs 在分支上创建 — 两个步骤，且第一步是第二步的前置条件：
dxs configuration validate <type> -b <branchId> -D body.json # exit 1 = errors found dxs configuration upsert <type> -b <branchId> -D body.jsonvalidate在发现错误时会以 1 退出 — 这表示验证报告了问题，并非 CLI 故障。读取validation_errors负载，修复骨架并重新验证；未通过验证关卡时，不要运行upsert。请参阅 ../datex-studio-shared/configuration-roundtrip.md。upsert会根据referenceName确定执行创建还是更新；分支上没有对应内容（步骤 5 已确认）时，它会走创建流程。此时，最小有效组件已位于分支上。 -
交接给对应的创建器技能。 骨架已位于分支上，因此创建器将在编辑模式下工作（获取 → 提取内部
.json→ 编写 →upsert）。告诉调用者后续负责此组件类型的创建器技能，以及显而易见的下一步（例如：“grid 已在分支上搭建好；调用grid-creator添加列并连接数据源”，“storage 已搭建好；调用storage-creator定义objectTypeDef列”）。
分派表
表格说明：
- 数据源有两种组件变体（
-datasource和-footprintDatasource），它们对应不同的configurationTypeId。每种变体都可以携带任一查询类型（OData 或 flow）——变体决定运行时层级，查询类型决定数据的获取方式。可选性矩阵（例如，selectors 只能指向-datasource.json）由 datasource-creator/references/datasources.md 维护——请参考该文档，不要在此重新推导。 interface和enum共用-customType.json组件类型（cti=22）。其内部主体差异很大——两种结构请参阅 type-definition-creator/references/type-definitions.md。- 对于定制变体（例如，通过
baseConfiguration覆盖定制现有的核心库 grid），不要从这些骨架搭建——定制覆盖结构不同，由tailoring-overlay技能负责。请直接调用该技能，而不是通过此脚手架分派。 - 修改现有组件时，不要搭建新文件——请直接调用匹配的创建器技能。此技能仅搭建新组件。
规则
- 骨架来自参考文档。 构建正文前，务必先阅读对应的
references/<type>.md。不要凭记忆编造 JSON 结构。参考文档是骨架结构和默认值的权威依据。 - 分支是唯一可信来源。 骨架通过
dxs configuration upsert写入分支；任何本地body.json都只是临时草稿，不能作为记录的依据。使用dxs configuration get检查是否存在，不要检查本地文件路径。 referenceName必须与文件名主体完全一致。 唯一例外是 actions：其referenceName以_action结尾，而文件后缀为-footprintFlow.json——这是文档规定的约定，并非笔误。后端类型的title与referenceName相同；但面向用户的类型（form、editor、hub、grid、embed、standalone selector）必须使用不同的、采用句首字母大写格式的展示title——参见步骤 4 和 ../datex-studio-conventions/naming-conventions.md。- 必须填写 Description，且长度不得超过 100 个字符。 这是 SQL 列的长度上限。没有 Description 就不要继续。不要擅自截断——请与调用方确认。
configurationTypeId会影响代码生成，即使 Studio 的 Validate 不会验证它。 cti 错误会导致 Preview 级联失败，且问题源自从未修改过的文件。务必从同类型的正常组件或上方的分派表复制。有关失败模式的讨论，请参见 ../datex-studio-conventions/file-format.md。- 仅保留最低限度的有效内容。 除了让 Validate 通过所需的骨架内容，不要添加占位属性、过滤器、列或代码。正文编写由 creator skill 负责；本 skill 只会在分支上创建一个空但有效的组件，然后交接。
- 遇到冲突时停止。 如果
dxs configuration get发现分支上已存在该referenceName，不要覆盖。报告冲突，让调用方决定是重命名、通过 creator skill 修改现有组件，还是删除。 - 每次调用只搭建一个组件。 如果调用方想搭建多个组件（例如 hub、其标签页 grid 以及过滤器 datasource），请逐个搭建，并按自然顺序交接——通常先搭建 datasource，再搭建使用它们的 UI 组件。