القائمة
Use when changing retikz providers layer code, builtin definitions, registry resolvers, BUILTIN_* collections, reserved or removed keys, custom definition merging, provider diagnostics, or implementation of contract capabilities.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | standard-providers |
| description | Use when changing retikz providers layer code, builtin definitions, registry resolvers, BUILTIN_* collections, reserved or removed keys, custom definition merging, provider diagnostics, or implementation of contract capabilities. |
providers/ 是契约实现层：实现内置 definition，合并用户 definition，并向 pipeline / compile 提供可消费的 registry。它可以依赖 shared、schemas、contract，不依赖 pipeline / compile。
不要让消费侧复制内置白名单；不要把用户 definition 放到与内置不同的旁路逻辑。
| 形态 | 规则 |
|---|---|
providers/<capability>/definitions.ts | 内置 definition 集合，或组装各内置项 |
providers/<capability>/registry.ts | resolveXxxRegistry()、索引 map、重复 key / 保留名诊断 |
providers/<capability>/<builtin>.ts | 复杂内置项的单独实现 |
BUILTIN_XXXS | 内置 definition 数组或集合 |
BUILTIN_XXX_DEFINITIONS_BY_<KEY> | 按真实 discriminator 建索引 map |
RESERVED_XXX_<KEYS> / REMOVED_XXX_<KEYS> | 保留名和已移除名诊断依据 |
xxxDefinitionOf() | 按 key 查询 definition |
<KEY> 后缀必须匹配真实 discriminator，不要 kind / name 混用。
defineXxx() 或同等 contract 入口创建。options 对象承载；不要把第三个及之后的位置参数作为未来扩展槽。shared。definitions.ts 组装，registry.ts 是否只负责 resolver？BUILTIN_* 数组里是否只放命名 definition，不直接内联长对象？Use when changing any retikz apps/docs content, route data, i18n, demo, SourceLinks, or schema reference before loading the matching page-type skill.
Use when retikz needs multiple independent LLMs to review the same fixed code, ADR, implementation plan, test contract, commit, or working-tree snapshot before a gate or delivery decision.
Use when an Alpha ADR needs a pre-implementation capability gate, or a Beta milestone needs code-based completeness and package-boundary auditing.
Use when planning a retikz architecture direction, version roadmap, or alpha feature that may need a long-lived ADR before implementation.
Use when retikz work is primarily refactoring, reorganization, renaming cleanup, modularization, or internal simplification and should start from a reviewed implementation plan before code changes.
Use when retikz implementation, adversarial testing, and docs are complete, and an ADR or beta TODO needs changelog, contract consistency review, roadmap status updates, or final human acknowledgement.