Menu
Update, add, or delete i18n translation nodes while keeping every accompanying language file structurally in sync. Use /translate for translation files of any format, locale drift, missing keys, or user-facing copy changes.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | translate |
| description | Update, add, or delete i18n translation nodes while keeping every accompanying language file structurally in sync. Use /translate for translation files of any format, locale drift, missing keys, or user-facing copy changes. |
| license | MIT |
| metadata | {"author":"damacus"} |
Use /translate whenever a task updates, adds, renames, or deletes a node in a
translation file. This applies to translation files of any format, including
YAML, JSON, TOML, properties, gettext, and framework-specific locale formats.
A translation-tree change is incomplete until the equivalent node change has been made in every accompanying language.
This remains true when the request names only one locale file: treat that file as the starting point, then inspect and update the repository's other locales.
For example, if en.yml changes and the repository also contains Spanish,
Polish, and Welsh locale files, update all four files in the same change. Do not
update only the source or default locale.
%{name}, {{name}},
printf-style placeholders, and format-specific escaping.zero, one, few, many, and other.yq.Do not silently copy source-language text into other locales unless the project explicitly uses source text as its fallback policy. If a translation is ambiguous or domain-specific, call that out rather than inventing terminology.
The bundled checker compares node paths and node kinds. It ignores translated
values and normalizes a single top-level locale key, so en.greeting and
es.greeting are treated as the same logical path.
From the directory containing this SKILL.md, run the checker with only a
reference file to discover locale-named sibling files having the same extension:
./scripts/check_locale_sync.sh /path/to/project/config/locales/en.yml
Pass files explicitly for split directories, mixed extensions, or locale layouts the discovery rule cannot infer safely:
./scripts/check_locale_sync.sh \
/path/to/project/locales/en/messages.yml \
/path/to/project/locales/es/messages.yml \
/path/to/project/locales/pl/messages.yml \
/path/to/project/locales/cy/messages.yml
The checker requires mikefarah yq v4 and accepts formats it can parse, such as
YAML, JSON, TOML, XML, properties, and INI. For formats yq cannot parse, such
as gettext PO, use the format's native validation tooling and manually verify
the same node set across all languages.
Decide whether planned implementation work should ship as one pull request, independent pull requests, or a stack of small ordered pull requests, then plan, build, review, revise, and land the stack safely. Use when a change is too large for effective review, later work must continue on an evolving baseline before earlier pull requests merge, AI-generated code needs deliberate review boundaries, or the user mentions stacked PRs, PR stacks, dependent PRs, gh-stack, bottom-up review, or splitting implementation across branches.
Design, build, review, or test command-line interfaces that work well for humans, scripts, agents, pipes, and CI. Use when defining command trees, arguments and flags, stdout/stderr contracts, human and structured output, exit codes, prompts, configuration precedence, destructive-action safeguards, TTY behavior, completion, or CLI compatibility. Also use when a TUI needs a stable non-interactive command surface. Language-agnostic core with optional TypeScript implementation references.
Design, audit, and evolve repository, source, module, and package structures so real ownership, runtime, dependency, and change boundaries are easy to see and enforce. Use when deciding where code belongs; reorganizing flat or layer-first trees; structuring by feature, route, screen, command, workflow, use case, bounded context, or capability; evaluating DDD or ports-and-adapters placement; planning safe folder migrations; or reviewing package and import direction. Do not activate for ordinary file moves whose destination is already established by the repository.
Design, build, review, or refine responsive Terminal User Interfaces (TUIs), especially Rust Ratatui and Ruby TTY/cli-ui applications. Use for TUI state and event architecture, terminal layout, navigation, keyboard and text-input behavior, async data loading, accessibility, rendering, resizing, empty/error/loading states, or visual polish. When the product also exposes scriptable commands, use cli-design alongside this skill for the CLI contract.
Choose and revise Codex model and reasoning effort for multi-stage engineering work. Use when deciding between Sol, Terra, and Luna; balancing judgment, cost, and latency; delegating bounded implementation or research to subagents; planning a model handoff; or escalating work after uncertainty, risk, or failed attempts increase. Apply at the start of substantial coding tasks that have independently executable work, not to trivial tasks where delegation overhead exceeds the work.
Prepare, verify, and publish a scoped GitHub pull request. Use when the user asks to commit local work, push a feature branch, or create or verify a GitHub PR. This workflow always uses main as the PR base branch.