dict-sync

Synchronizes module dicts.ts dictionary contracts with backend dictionary services via MCP tools.

5|1|Updated Apr 8, 2026
One-click install
npx skills add https://github.com/ChenyCHENYU/wl-skills-kit --skill dict-sync-chenychenyu
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dict-sync
Source: https://github.com/ChenyCHENYU/wl-skills-kit/tree/main/files/.wl-skills/skills/sync/dict-sync
Command: npx skills add https://github.com/ChenyCHENYU/wl-skills-kit --skill dict-sync-chenychenyu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Keeping backend data dictionaries consistent with frontend module definitions is error-prone when done manually: modules get duplicated, labels drift from values, and writes hit the wrong environment. This Skill makes the module dicts.ts file the single source of truth and reconciles it with the backend through a preview-then-confirm workflow. ## Core Features & Use Cases - Project-wide discovery and reconciliation: Scans all src/views/**/dicts.ts files, builds a backend index, and produces a safe-additive plan that only adds missing modules, dictionaries, and items while blocking on any name, order, or value/label drift. - Bootstrap for legacy projects: Aggregates existing api.md dict-contracts via wls_dict_bootstrap to create local dicts.ts files without guessing enumerations from code. - Guarded writes: Every publish requires environment verification (gatewayPath, sysAppNo), a preview with a planHash, explicit user confirmation, and post-write re-query; conflicts like DICT_MODULE_HIDDEN_CONFLICT halt execution with guided remediation. - Use Case: After adding a new order-status dictionary to src/views/produce/order/dicts.ts, run a project-scope preview, confirm the returned plan hash, and publish only the missing dictionary entries to the SIT environment. ## Quick Start Ask the AI to preview and sync all module dictionaries from the project's dicts.ts files to the backend, confirming the plan hash before any write.

Frequently Asked Questions about dict-sync

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I sync frontend dictionaries to the backend safely?

Define dictionaries in the module dicts.ts file, run a project-scope preview with wls_dict_upsert to get a planHash, then re-invoke with confirmApply and the same hash. The plan is safe-additive: it only adds missing items and blocks on any drift.

How to create dicts.ts for a legacy project that has none?

Run wls_dict_bootstrap, which deterministically aggregates existing api.md dict-contracts into local dicts.ts files after preview confirmation. Code hints like logicValue or useDictOpts are listed as candidates only; enumerations are never guessed.

Why does the backend say a dictionary module already exists but queries cannot find it?

This returns DICT_MODULE_HIDDEN_CONFLICT, usually caused by soft-deleted, cross-tenant, or historical residue records. Do not retry blindly or guess module IDs; either adopt a new globally unique module.code everywhere or have an administrator clean the hidden record.

Can dictionary sync update or delete existing backend entries?

No. The project-level strategy is fixed to safe-additive: it never renames, reorders, modifies existing items, or deletes anything. Extra backend modules, dictionaries, or items are only reported, and any label/value or extension-field drift blocks the entire plan.

What happens if the plan hash changes before confirmation?

Execution re-reads local and remote state before writing; if the hash no longer matches, nothing is written and a fresh preview is required. Interrupted runs are not rolled back destructively—fix the cause and rerun, since completed items are skipped idempotently.