songolge-lab

---
name: i18n-change-workflow
description: Reusable i18n workflow for coding agents. Verifies locale completeness, hardcoded text, placeholders, pluralization, fallback behavior, formatting, translation consistency, and localization-related UI regressions.
---

# i18n Change Workflow

Act as the i18n/l10n specialist layer for the active task.

This skill adds localization-specific constraints and verification. It does not replace the repository's normal implementation, audit, Git, or approval workflow. Follow the active workflow's mutation boundary: during implementation or remediation, apply the required i18n changes; during a read-only audit or review, use these criteria without modifying repository state.

## 1. Inspect the existing i18n system first

Before changing localized behavior:

- read applicable `AGENTS.md` and project documentation;
- identify the current i18n library or project-native mechanism;
- identify supported locales, source/default locale, locale resource locations, fallback behavior, and locale-selection/persistence logic;
- inspect nearby existing keys and call sites before choosing new key names or structures;
- identify project-specific rules for translations, formatting, generated resources, or validation.

Prefer the existing project architecture. Do not introduce a new i18n library, resource format, or parallel translation mechanism unless the task requires it and the repository has no suitable existing mechanism.

Do not treat one framework convention as universal. Follow the repository's actual conventions.

## 2. Classify text before localizing it

Determine whether each changed string is actually user-facing.

Typical localization candidates include:

- visible UI labels, buttons, headings, menus, dialogs, empty states, validation messages, and user-visible errors;
- accessibility labels and descriptions;
- notifications and user-facing system messages;
- placeholders, helper text, onboarding copy, and tooltips;
- user-visible content generated from application-owned templates.

Do not automatically localize:

- identifiers, translation keys, API names, URLs, paths, commands, SQL, regexes, or protocol values;
- developer-only logs, diagnostics, stack traces, and test fixture text;
- brand names, product names, codes, or terms that project rules intentionally preserve;
- externally supplied runtime content unless the task explicitly covers it.

When classification is ambiguous and affects product meaning, preserve the current behavior and surface the ambiguity rather than guessing.

## 3. Preserve the project's key and resource model

For new or changed user-facing text:

- use the project's translation mechanism instead of introducing hardcoded display text when localization is expected;
- follow the existing key naming and namespacing convention;
- prefer stable semantic keys over keys derived from full display sentences unless the project intentionally uses source-text keys;
- update every supported locale required by project rules or the current task;
- preserve unrelated locale entries and target-only data unless deletion is explicitly intended;
- do not silently rename or delete existing keys merely for stylistic consistency.

Treat the project's declared source/default locale as canonical only if the repository actually uses that model.

Missing translations must follow the project's established fallback policy. Do not invent a new fallback policy silently.

## 4. Preserve interpolation, pluralization, and message structure

Translation structure is part of the contract.

- Preserve the same required placeholders/arguments across locale variants.
- Do not translate placeholder names, format tokens, markup, or control syntax.
- Use the project's plural/select/ICU mechanism when grammar depends on count, gender, case, or other locale-sensitive variation.
- Avoid assembling sentences from separately translated fragments when word order or grammar can vary by language.
- Avoid string concatenation that assumes English word order or spacing.
- Preserve intentional markup, escaping, and line-break semantics.

If a source message changes its arguments or message structure, verify every affected locale rather than updating only the visible source text.

## 5. Keep locale-sensitive values locale-aware

When the changed UI contains locale-sensitive values, use the project's existing locale-aware formatting facilities for relevant:

- dates and times;
- numbers and percentages;
- currencies;
- units;
- relative time;
- list formatting;
- plural categories.

Do not hardcode separators, decimal conventions, date ordering, currency placement, or English-only plural assumptions when locale-aware behavior is expected.

## 6. Protect locale selection and fallback behavior

When the task touches locale switching, initialization, persistence, or fallback:

- preserve the project's supported-locale list and normalization rules;
- verify default-locale behavior;
- verify persistence if the project stores the user's language choice;
- verify unsupported or missing locales degrade through the intended fallback path;
- avoid mixed-language UI caused by missing keys or stale cached locale data;
- ensure lazy-loaded locale resources are awaited or synchronized correctly when applicable.

Do not change locale-detection precedence without an explicit requirement.

## 7. Translation quality

When generating or editing translations:

- preserve meaning, intent, tone, and product terminology rather than translating mechanically word-for-word;
- use surrounding UI context to resolve ambiguous short labels;
- preserve approved product names, technical terms, and glossary decisions;
- keep placeholders and markup intact;
- avoid adding claims, meaning, politeness level, or functionality not present in the source;
- flag uncertain, culturally sensitive, legal, safety-critical, or brand-sensitive wording for human confirmation instead of pretending certainty.

If the repository contains a glossary, terminology file, translation memory, or established translations, prefer that evidence over a newly generated alternative.

Read `references/i18n-review-checklist.md` when doing a broad locale addition, translation review, or release-oriented localization change.

## 8. Check UI and layout risk

Localized text can change layout even when the translation is correct.

For affected UI, consider when relevant:

- longer labels and multi-line wrapping;
- narrow mobile widths and responsive layouts;
- CJK line breaking and glyph coverage;
- text truncation and ellipsis;
- buttons, tabs, badges, dialogs, tables, and fixed-width containers;
- font fallback;
- accessibility labels;
- right-to-left direction, mirroring, and logical CSS/layout properties when an RTL locale is in scope.

Do not add RTL-specific work when no RTL locale is supported or requested, but do not ignore it when an RTL locale is part of the task.

Use visual or UI verification when the changed text can plausibly affect layout. A successful locale-file check alone does not prove the UI is correct.

## 9. Verify with project-native checks

Use the repository's existing i18n validators, tests, linters, builds, and UI checks first.

Verify the relevant subset of:

- locale-key completeness/parity;
- missing or blank translations;
- placeholder/argument parity;
- plural/select structure;
- fallback behavior;
- locale switching and persistence;
- locale-aware formatting;
- absence of newly introduced hardcoded user-facing strings in the changed scope;
- build/type/lint/test health;
- layout behavior for affected screens.

For plain JSON locale catalogs, `scripts/check_json_locales.py` may be used as an additional deterministic check. It checks duplicate JSON keys, key parity, value types, blank strings, and common brace-style named placeholder/ICU argument parity. Placeholder detection is intentionally narrow and heuristic; confirm reported mismatches against the project's actual message syntax. It is not a semantic translation review and does not replace project-native tooling.

Do not claim repository-wide i18n completeness from a narrow file or static check.

## 10. Completion criteria

An i18n change is complete only when, for the requested scope:

- the intended user-facing strings use the project's localization mechanism;
- required locale resources are updated;
- placeholders and message structure remain compatible;
- relevant formatting/fallback/switching behavior is preserved;
- project-native verification passes, or limitations are explicitly reported;
- plausible layout regressions have been checked when the UI is affected;
- unresolved translation or product-language ambiguity is reported rather than guessed.

Keep the final report concise. State what locale behavior changed, which locales/resources were touched, what validation actually ran, and any remaining translation or UI limitations.
FILE:references/i18n-review-checklist.md
# i18n Review Checklist

Use this reference for broad locale additions, translation review, or release-oriented localization work. Apply only items relevant to the project and requested scope.

## Coverage

- Inventory the user-visible surfaces in scope.
- Confirm every intended translation candidate is represented by the project i18n mechanism.
- Distinguish deliberate source-language preservation from accidental untranslated text.
- Report dynamic/external/non-text surfaces that cannot be verified from repository resources.

## Resource integrity

- Required keys exist in the locales covered by the task.
- No unrelated locale entries were deleted or rewritten.
- Value types match where the resource format requires them to match.
- Empty translations are intentional or reported.
- Generated locale resources are regenerated only through the project-approved command.

## Message contracts

- Named placeholders and ICU/select arguments are preserved.
- Markup, escapes, formatting tokens, and intentional line breaks remain valid.
- Plural/select branches follow the project's library and locale rules.
- Sentences are not built from fragments that assume source-language word order.

## Language quality

- Meaning and user intent match the source.
- Terminology is consistent with existing product language and glossary decisions.
- Short labels are interpreted using screen/action context, not in isolation.
- Tone, formality, capitalization, and punctuation fit the target locale and existing product voice.
- Brand/product names and deliberately preserved terms remain unchanged.
- High-risk ambiguity is surfaced for human confirmation.

## Locale behavior

When applicable, verify:

- default locale;
- explicit locale switching;
- persistence across reload/restart;
- unsupported-locale fallback;
- missing-key fallback;
- lazy-loaded resource behavior;
- date/time/number/currency/unit formatting;
- locale normalization such as `en-US` vs `en` according to project rules.

## UI and accessibility

When affected, check:

- narrow-screen overflow;
- wrapping, truncation, and fixed-height containers;
- buttons/tabs/badges with longer translations;
- CJK line-breaking and font glyphs;
- screen-reader/accessibility labels;
- RTL direction and mirroring only when RTL locales are in scope.

## Evidence and limitations

A passing resource check proves only what it actually checked. It does not by itself prove:

- translation quality;
- runtime locale switching;
- visual correctness;
- complete coverage of inline/dynamic/non-text content;
- correct external/CMS content.

State those limitations explicitly when they matter.
FILE:scripts/check_json_locales.py
#!/usr/bin/env python3
"""Deterministic structural checks for JSON locale catalogs.

Checks:
- duplicate object keys while parsing
- missing/extra leaf paths relative to a source locale
- source/target leaf type mismatches
- blank target strings
- common named placeholder / ICU argument parity

This intentionally does not judge translation quality and is not a general
hardcoded-string scanner.
"""

from __future__ import annotations

import argparse
import json
import re
import sys
from pathlib import Path
from typing import Any, TypeAlias

ARG_RE = re.compile(r"\{\s*([A-Za-z_][A-Za-z0-9_.-]*)\s*(?:[,}])")
PathPart: TypeAlias = str | int
JSONPath: TypeAlias = tuple[PathPart, ...]


class JSONObjectPairs(list):
    """Marker type preserving JSON object pairs so duplicates remain detectable."""


def _object_pairs_hook(pairs: list[tuple[str, Any]]) -> JSONObjectPairs:
    return JSONObjectPairs(pairs)


def path_label(path: JSONPath) -> str:
    """Render an unambiguous JSON-style path without conflating dots in keys."""
    if not path:
        return "$"
    pieces: liststr = []
    for part in path:
        if isinstance(part, int):
            pieces.append(f"[{part}]")
        else:
            pieces.append(f"[{json.dumps(part, ensure_ascii=False)}]")
    return "$" + "".join(pieces)


def _normalize_json(value: Any, path: JSONPath = ()) -> Any:
    if isinstance(value, JSONObjectPairs):
        out: dict[str, Any] = {}
        seen: setstr = set()
        for key, child in value:
            if key in seen:
                raise ValueError(f"duplicate key at {path_label(path + (key,))}")
            seen.add(key)
            out[key] = _normalize_json(child, path + (key,))
        return out
    if isinstance(value, list):
        return [
            _normalize_json(child, path + (index,))
            for index, child in enumerate(value)
        ]
    return value


def load_json(path: Path) -> Any:
    try:
        with path.open("r", encoding="utf-8") as f:
            raw = json.load(f, object_pairs_hook=_object_pairs_hook)
        return _normalize_json(raw)
    except (OSError, json.JSONDecodeError, ValueError) as exc:
        raise ValueError(f"{path}: {exc}") from exc


def flatten(value: Any, path: tuple[str, ...] = ()) -> dict[tuple[str, ...], Any]:
    """Flatten JSON objects using tuple paths so literal dots in keys stay distinct."""
    out: dict[tuple[str, ...], Any] = {}
    if isinstance(value, dict):
        for key, child in value.items():
            out.update(flatten(child, path + (key,)))
    else:
        outpath = value
    return out


def value_kind(value: Any) -> str:
    if isinstance(value, bool):
        return "boolean"
    if value is None:
        return "null"
    if isinstance(value, str):
        return "string"
    if isinstance(value, (int, float)):
        return "number"
    if isinstance(value, list):
        return "array"
    return type(value).__name__


def arguments(value: Any) -> setstr:
    if not isinstance(value, str):
        return set()
    return set(ARG_RE.findall(value))


def check_pair(source_path: Path, target_path: Path, allow_extra: bool) -> int:
    source = flatten(load_json(source_path))
    target = flatten(load_json(target_path))

    findings: list[tuple[str, str]] = []

    source_keys = set(source)
    target_keys = set(target)

    for key in sorted(source_keys - target_keys):
        findings.append(("ERROR", f"missing key: {path_label(key)}"))

    if not allow_extra:
        for key in sorted(target_keys - source_keys):
            findings.append(("WARN", f"extra key: {path_label(key)}"))

    for key in sorted(source_keys & target_keys):
        src = source[key]
        dst = target[key]
        label = path_label(key)
        src_kind = value_kind(src)
        dst_kind = value_kind(dst)

        if src_kind != dst_kind:
            findings.append(
                ("ERROR", f"type mismatch at {label}: source={src_kind}, target={dst_kind}")
            )
            continue

        if isinstance(dst, str) and dst.strip() == "":
            findings.append(("WARN", f"blank target string: {label}"))

        src_args = arguments(src)
        dst_args = arguments(dst)
        if src_args != dst_args:
            missing = sorted(src_args - dst_args)
            extra = sorted(dst_args - src_args)
            details: liststr = []
            if missing:
                details.append(f"missing={missing}")
            if extra:
                details.append(f"extra={extra}")
            findings.append(("ERROR", f"argument mismatch at {label}: {', '.join(details)}"))

    print(f"SOURCE: {source_path}")
    print(f"TARGET: {target_path}")
    if not findings:
        print("PASS: no structural findings")
        return 0

    for severity, message in findings:
        print(f"{severity}: {message}")

    errors = sum(1 for severity, _ in findings if severity == "ERROR")
    warnings = sum(1 for severity, _ in findings if severity == "WARN")
    print(f"SUMMARY: {errors} error(s), {warnings} warning(s)")
    return 1 if errors else 0


def main() -> int:
    parser = argparse.ArgumentParser(
        description="Check JSON locale catalogs for structural parity."
    )
    parser.add_argument("source", type=Path, help="source/default locale JSON")
    parser.add_argument("targets", nargs="+", type=Path, help="target locale JSON file(s)")
    parser.add_argument(
        "--allow-extra",
        action="store_true",
        help="do not warn about target-only keys",
    )
    args = parser.parse_args()

    try:
        statuses = [check_pair(args.source, target, args.allow_extra) for target in args.targets]
    except ValueError as exc:
        print(f"ERROR: {exc}", file=sys.stderr)
        return 2

    return 1 if any(status != 0 for status in statuses) else 0


if __name__ == "__main__":
    raise SystemExit(main())
FILE:README.md
# i18n-change-workflow

Repository-local Agent Skill for safe i18n/l10n changes.

Suggested location:

`.agents/skills/i18n-change-workflow/`

The optional JSON checker is intentionally narrow and deterministic. It detects duplicate JSON keys and structural mismatches, plus heuristic common brace-style placeholder mismatches; it does not translate text or claim semantic/visual completeness.

---
name: implementation-workflow
description: Implement code changes with disciplined scope control, repository-state preservation, relevant verification, and concern-scoped commits. Use when implementing, fixing, refactoring, or remediating an existing codebase.
---

# Implementation Workflow

Implement the requested change safely, minimally, and in a reviewable form.

## Scope and priority

Follow the current task, applicable repository instructions such as `AGENTS.md`, and established project conventions.

Do not expand scope merely because adjacent improvements are possible.

This skill governs implementation and remediation. Independent post-implementation review belongs to `post-implementation-audit`.

## 1. Inspect before changing

Before editing:

- understand the requested behavior and acceptance criteria;
- inspect the relevant existing implementation;
- inspect repository status when Git is available;
- identify pre-existing modified, staged, deleted, or untracked files.

Treat unrelated existing changes as protected.

Do not overwrite, discard, normalize, or accidentally include unrelated work.

## 2. Decide whether a plan is needed

Proceed directly when the task is small, localized, low-risk, and sufficiently clear.

For substantial work, use an implementation plan first unless an approved plan already exists.

Work is substantial when it involves meaningful architectural uncertainty, multiple interacting components, migrations, public contracts, broad behavioral changes, or significant security/reliability risk.

When a new plan is required, produce the plan and stop before modifying the repository so it can be reviewed.

Do not create ceremonial plans for trivial work.

## 3. Implement narrowly

Once implementation is authorized:

- make the smallest coherent change that satisfies the task;
- preserve existing architecture and conventions unless the task intentionally changes them;
- prefer existing mechanisms over unnecessary parallel abstractions;
- avoid unrelated refactoring, cleanup, renaming, formatting churn, dependency changes, or speculative improvements;
- preserve unrelated changes in files that must also be edited.

Do not weaken tests, validation, error handling, or existing guarantees merely to make the new implementation pass.

## 4. Preserve repository state

Do not discard existing work to obtain a clean repository.

Unless explicitly required and authorized, do not use destructive or history-rewriting operations such as:

- `git reset`
- `git restore`
- `git stash`
- `git clean`
- rebase
- amend
- squash
- other history rewriting

Work around unrelated dirty state instead of erasing it.

## 5. Verify the implementation

Use the smallest relevant verification first, then expand when scope or risk warrants it.

Relevant verification may include targeted tests, static analysis, linting, type checking, builds, or repository-specific checks.

Add or update tests when needed to prove changed behavior.

Test meaningful behavior and failure paths rather than merely mirroring implementation details.

Never claim verification that was not actually performed.

If relevant verification cannot run, report the limitation rather than assuming success.

## 6. Create commits only when authorized

Create commits only when explicitly authorized by the current task or applicable repository instructions.

When commits are authorized:

- each commit must represent one coherent concern;
- keep unrelated implementation, cleanup, formatting, documentation, and refactoring concerns separate unless inseparable;
- keep commits independently understandable, reviewable, and reasonably revertible;
- use meaningful commit messages.

Before each commit:

1. inspect repository state;
2. identify exactly which changes belong to the concern;
3. stage only those changes;
4. inspect the staged diff;
5. commit only after confirming its scope.

Prefer explicit file or hunk staging.

Do not use broad staging such as `git add .` when it could capture unrelated changes.

Do not rewrite existing commits unless explicitly requested.

## 7. Finish and hand off

Before declaring implementation complete:

- confirm the requested behavior and acceptance criteria are addressed;
- run relevant final verification;
- inspect the final diff for accidental or unrelated changes;
- report unresolved limitations honestly.

For substantial implementations, hand off to `post-implementation-audit` after implementation changes stop.

If the audit reports findings:

1. return to an implementation/remediation phase;
2. fix only supported findings with the smallest coherent change;
3. verify the remediation;
4. run `post-implementation-audit` again.

Repeat until the audit is `CLEAR` or an unresolved limitation is explicitly reported.

Small, localized changes need an independent audit only when the task, repository instructions, or risk justifies one.

## Output

At completion, concisely report:

- what changed;
- important implementation decisions;
- verification actually performed;
- material limitations or unresolved issues;
- commits created, if any.

Do not reproduce this workflow as a checklist in the final response.

---
name: post-implementation-audit
description: Read-only audit of completed code changes. Use after implementation or remediation to verify requirements, correctness, regressions, relevant verification, and commit scope. Do not use to implement or fix changes.
---

# Post-Implementation Audit

Independently audit completed code changes using available evidence.

This workflow is read-only. Find meaningful problems when they exist; do not manufacture findings.

## Scope and boundary

Follow the current task, applicable repository instructions such as `AGENTS.md`, and the actual implementation context.

Do not broaden the audit merely because additional review is possible.

Do not implement, remediate, refactor, stage, commit, or intentionally modify repository state while this workflow is active.

If a required verification step would intentionally modify tracked files, do not run it during the audit. Report it as a verification limitation and return that work to an implementation/remediation phase.

Unexpected side effects from otherwise appropriate verification commands must be reported, not reverted or cleaned up.

Do not create an audit file unless explicitly requested.

## 1. Establish target and baseline

Determine what change is actually being audited before judging it.

When Git is available, prefer the baseline in this order:

1. explicit baseline or commit range from the task;
2. a known implementation start point supported by context;
3. clearly attributable staged or working-tree changes.

Never select an arbitrary number of recent commits as the baseline.

Distinguish implementation changes from pre-existing or unrelated repository changes.

If the boundary cannot be established reliably, state the limitation and audit only what can be attributed with reasonable confidence.

Do not invent missing requirements, acceptance criteria, history, or implementation boundaries.

## 2. Verify requirements, correctness, and regressions

Trace available requirements and acceptance criteria to the implementation.

Check for meaningful issues such as:

- missing or partial behavior;
- incorrect requirement interpretation;
- regressions or unintended behavior changes;
- scope creep or unrelated modifications;
- incorrect logic or state transitions;
- relevant error or failure paths;
- plausible boundary, lifecycle, async, concurrency, persistence, caching, or integration problems.

Inspect enough surrounding code to understand the changed behavior.

Only investigate risk areas that are plausible for the implementation.

Review security, performance, data integrity, or deployment concerns only when the change makes them relevant.

Do not report subjective style preferences or speculative possibilities as defects.

A maintainability concern is a finding only when it creates a concrete correctness, reviewability, change-safety, or long-term engineering risk.

## 3. Verify evidence

Run the smallest relevant set of non-mutating verification commands needed for confidence.

Expand verification when scope or risk warrants it.

Never claim that a command, test, path, or behavior was verified unless it actually was.

If important verification cannot be completed, record:

- what was not verified;
- why;
- what confidence is lost.

A verification limitation is not automatically a finding.

Treat it as a finding only when the missing verification itself violates an explicit requirement or represents a concrete defect.

## 4. Review commits when applicable

When commits are part of the audited implementation, verify that each represents one coherent concern and is independently understandable, reviewable, and reasonably revertible.

Report material problems such as:

- unrelated concerns mixed together;
- hidden scope expansion;
- accidental unrelated changes;
- misleading commit boundaries;
- excessive size that materially harms reviewability or rollback safety.

Do not require commits when none were authorized or expected.

## 5. Complete the full audit

Do not stop at the first issue.

Complete the full in-scope review and collect every meaningful finding supported by evidence.

Each finding must be backed by code, diff, test output, command output, reproducible behavior, or a credible demonstrated failure path.

Distinguish fact from inference.

After completing the audit, report the result and stop. Do not remediate findings.

## Severity

Use severity only for actual findings:

**Critical** — catastrophic failure, severe security compromise, irreversible data loss/corruption, or fundamentally unusable core behavior.

**High** — major incorrect behavior, serious regression, significant security/reliability failure, or failure of an important requirement.

**Medium** — real actionable defect with bounded impact.

**Low** — minor but legitimate defect with limited concrete impact.

Do not use `Low` for optional polish or subjective preference.

## Result

Use exactly one primary result:

### CLEAR

Use when:

- no meaningful finding remains;
- intended behavior is sufficiently established;
- relevant verification completed successfully;
- no material unexplained verification gap remains;
- no material scope contamination exists.

### FINDINGS

Use when one or more meaningful implementation findings exist.

Verification limitations may be reported alongside `FINDINGS`.

### INCOMPLETE

Use when no meaningful implementation defect has been established, but missing context or important verification prevents a reliable `CLEAR`.

Do not treat absence of discovered defects as proof of correctness.

## Re-audit

When previous findings are available, preserve their identifiers and mark each:

- `RESOLVED`
- `UNRESOLVED`
- `NOT VERIFIED`

Verify the underlying issue, not only its visible symptom, and check whether remediation introduced regressions.

Then perform a fresh audit of the affected scope.

Do not invent prior finding IDs when they are unavailable.

## Output

Start with:

**Result:** `CLEAR` / `FINDINGS` / `INCOMPLETE`

Briefly state:

- scope audited;
- baseline used;
- important evidence inspected;
- verification commands actually executed;
- material limitations.

For each new finding include:

**ID:** `AUDIT-001`  
**Severity:** Critical / High / Medium / Low  
**Evidence:** concrete supporting evidence  
**Impact:** concrete failure or risk  
**Recommended remediation:** smallest appropriate correction  
**Verification:** how a re-audit can prove resolution

For re-audited findings also include:

**Status:** RESOLVED / UNRESOLVED / NOT VERIFIED

For `INCOMPLETE`, state what evidence is missing.

For `CLEAR`, state that no meaningful findings remain and summarize the evidence supporting that conclusion.

Do not invent owners, deadlines, metrics, findings, or recommendations merely to make the report appear more comprehensive.