system-vocabulary-review

Review and rewrite user-visible UI copy to replace internal technical terms with canonical product vocabulary.

Updated Apr 4, 2026
One-click install
npx skills add https://github.com/SleyiW/iWana-neXt --skill system-vocabulary-review-sleyiw
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: system-vocabulary-review
Source: https://github.com/SleyiW/iWana-neXt/tree/main/.agents/skills/system-vocabulary-review
Command: npx skills add https://github.com/SleyiW/iWana-neXt --skill system-vocabulary-review-sleyiw

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? User-facing screens, seeds, tests, and docs often leak internal technical terms like tenant, MOD00, WFM, enums, or permission keys, confusing non-technical users and fragmenting product language across modules. ## Core Features & Use Cases - Canonical Vocabulary Mapping: Provides a dictionary translating internal terms (tenant, UserRole, AccessProfile, MOD00, WFM, NOC) into friendly product names (empresa, categoria base, perfil de acceso, Configuracion). - Mandatory Review Flow: An 8-step workflow covering audience identification, term mapping, rewriting from the user's task perspective, and fixing copy at the source of truth (seeds, contracts, shared helpers) rather than patching JSX. - Checklist and Anti-Rationalization Rules: A review checklist plus a table of common excuses ("it's just a test", "the backend sends it that way") with the correct response, ensuring tests, mocks, and E2E specs adopt the new vocabulary. - Use Case: Before shipping a new settings section, run the review to catch raw enum values and internal module names, rewrite error messages with actionable next steps, and update backend seeds and E2E expectations to match. ## Quick Start Review the copy in this new settings screen and rewrite any internal or technical terms using the canonical product vocabulary.

Frequently Asked Questions about system-vocabulary-review

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

FAQPage Schema
How do I remove technical jargon from user-facing UI copy?

Identify the target audience, list all visible terms, map each technical term to its canonical product name, and rewrite phrases around the user's task. Fix copy at the source of truth such as backend seeds or shared helpers rather than patching individual components.

What should I replace terms like tenant, WFM, or NOC with in product UI?

Use the canonical dictionary: tenant becomes empresa or organizacion, WFM becomes Operaciones de campo, NOC becomes Monitoreo operativo, and MOD00 becomes Configuracion. Roles like TECHNICIAN map to Tecnico de campo.

Should tests and E2E specs use the friendly product vocabulary?

Yes. Tests fix the visible contract, so mocks and E2E expectations must use canonical names instead of legacy fixtures. If tests keep old copy, the product will regress to the old vocabulary.

When is it acceptable to keep a technical term in the UI?

Only for enum names, tables, migrations, internal routes, and versioned contracts where changing them breaks compatibility, or in technical docs that explicitly explain the term. Necessary technical terms shown to users must include simple, actionable context.

How do I write better error messages for non-technical users?

Translate the technical failure into plain language and add a next step when the user can act. For example, replace 'API no disponible' with 'No pudimos cargar la informacion. Reintenta en unos minutos.'