translation-audit

Layer 2 + 4 + 5 owner for review of an existing (source, target) pair in translation-toolkit. Reads an intake-spec produced by translation-intake (Layer 1) — or auto-infers one from the source — parses both source and target independently, skips Layer 3 (no DRAFT / REFLECT / IMPROVE — the user-provided target is the unit under review), runs the full M1 + M2 + S1 + S2 + I1 gate matrix with stricter tier semantics, and emits a diff report plus an audit-trail.json. Read-only — never rewrites the target, never writes back to the source format.

This is the only skill in the toolkit whose output is a review document, not a translated artifact.

Inputs

• source — file path (any format the toolkit can parse: .po / .json / .xliff / strings.xml / .strings / .md / .mdx / plain text) or an inline source string.
• existing target — file path or inline string (REQUIRED — distinguishes this skill from translation-i18n, translation-doc, translation-creative, all of which produce a target). Source format and target format MAY differ — e.g. source PO + target XLIFF in a migration audit, or source markdown + target plain text in a vendor delivery review.
• intake-spec — from translation-intake. If invoked directly without one, run intake against the source first (--intake flag) before continuing. Intake-spec carries mode / register / strategy / domain / intent / locale pair, all of which inform the strictness of S2 and the framing of I1.
• glossary_path (optional) — repo-local project glossary (L1 tier of the 4-tier resolver). Defaults to <caller_repo>/docs/i18n/glossary-{target_locale}.md; missing → fall through to L2 bundled glossary in glossary/.

Service-interface contract (the four shared fields plus web_search) is defined in the design spec §Service Interface; no per-skill duplication here.

When to use