Menü
A skill that localizes contents into given locales.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Build, preview, and verify the Copilot Workshops Astro + Starlight workshop site before committing or opening a PR. Use whenever an author or agent is about to build the site, run a local preview/dev server, check links with lychee, confirm the page-count invariant, run the pre-commit verification sequence for any change under `docs/` (content) or `website/` (tooling), or make a PR-time consistency pass to catch structural drift (renamed paths, stale skill/instruction references, inaccurate CI claims, out-of-date structure trees).
Publish presentations and web content to GitHub Pages. Converts PPTX, PDF, HTML, or Google Slides to a live GitHub Pages URL. Handles repo creation, file conversion, Pages enablement, and returns the live URL. Use when the user wants to publish, deploy, or share a presentation or HTML file via GitHub Pages.
Render-validate the built Copilot Workshops site in a real browser using the Playwright MCP server. Use as an optional deeper QA pass — after the static checks in build-and-verify-docs — to confirm pages actually render: navigate the built routes, assert HTTP 200, catch console/hydration errors, find broken images, confirm Starlight Markdown features rendered, and optionally screenshot key pages. Trigger when asked to "validate the built site", "check the pages render", "do a browser/visual QA pass", or before opening a PR that changes rendered output.
Find workshop lessons that should change alongside an edit. Scans a diff (staged, unstaged, or a branch range) of the Copilot Workshops docs, extracts what changed, then searches the rest of docs/** for duplicated or parallel passages that now risk drifting out of sync — prose that used to be a shared partial and is now copied across pages, the same concept taught across the VS Code / CLI / App / Cloud harnesses, and cross-references to the changed page. Use after editing lesson content under docs/, before committing or opening a PR, or whenever asked to "check content alignment", "find related content to update", "what else should change", or "check for drift". Reports candidate files with line ranges and rationale; it does NOT edit content.
All changes to code must follow the guidance documented in the repository. Before any issue is filed, branch is made, commits generated, or pull request (or PR) created, a search must be done to ensure the right steps are followed. Whenever asked to create an issue, commit messages, to push code, or create a PR, use this skill so everything is done correctly.
| name | localizations |
| description | A skill that localizes contents into given locales. |
A skill that localizes contents into given locales.
The skill takes input content and a list of target locales. It then translates the content into each specified locale, providing localized versions for each.
.
└── docs/ ← workshop content (source + locale outputs)
├── README.md ← landing page (source; slug: index)
├── <harness>/ ← English lessons (source)
│ ├── README.md ← harness landing (source; slug: <harness>)
│ └── *.md
├── _images/ ← shared assets (not localized)
└── <locale>/ ← localized output, direct child of docs/
├── README.md ← locale landing (slug: <locale>)
└── <harness>/
├── README.md ← localized harness landing (slug: <locale>/<harness>)
└── *.md
Here are the contents in scope for localization:
docs/ and its subdirectories — the workshop landing (docs/README.md) and the per-harness lessons (docs/<harness>/**/*.md).Do not treat _images/ (shared assets) or any configured locale-root directory as source input.
Files already under docs/<locale>/ are outputs, not inputs—never treat configured locale-root directories as source content to be localized again.
Target locales are defined in the rules directory as markdown files in this skill (rules/ko-kr.md, for example). To determine which locales to process, list the files in rules/: each <locale>.md file corresponds to exactly one supported target locale. Each locale has its own set of rules and guidelines for translation, ensuring that the localized content is appropriate for the target audience.
Locale identifiers use lowercase with a hyphen (for example, ko-kr). This is the canonical casing for both the rules filename and the output directory in this skill; keep them consistent.
All localized workshop content is stored directly under the repo-root docs/ content directory, with each locale having its own subdirectory. For example, Korean content is stored in docs/ko-kr/.
Locale directories must be direct children of docs/ so Starlight (configured in website/astro.config.mjs) recognizes them and renders its language selector. Do not add an intermediate localizations/ directory.
There are three cases for localization. To detect which case applies, compare the source tree against the existing docs/<locale>/ tree, and use the git history of the source files to detect changes:
docs/<locale>/, then run git diff (or git log) on the source file to find what changed since the localized version was last produced. Update only the affected sections of the localized document; do not re-translate unchanged sections unnecessarily.The process runs in two passes. First, the content is analyzed to identify key phrases and context. Then the translator agent performs the initial localization, followed by a review-and-refinement pass by the evaluator agent to ensure quality and consistency.
The
translatorandevaluator"agents" are roles/personas, not external tools. If no dedicated sub-agents are available, perform them as sequential personas: first adopt the translator role to produce the draft, then adopt the evaluator role to critique and refine that draft against the locale rules. Repeat the refinement loop until the evaluator's criteria pass.
Regardless of locale, the following must be preserved exactly and not translated:
title). Exception — the slug key on landing pages (README.md): the site routes each folder landing via its slug, so a localized landing must carry a locale-prefixed slug rather than the English one. Rewrite it: a locale root (docs/<locale>/README.md) uses slug: <locale>, and a localized harness landing (docs/<locale>/<harness>/README.md) uses slug: <locale>/<harness>. Never copy the English slug: index / slug: <harness> verbatim into a localized file — that would collide with the English route.Translate human-language prose, including comments inside code blocks where they are explanatory (per the locale rules). Keep heading order and document structure stable.
Heading anchors follow the localized text. When a heading is translated, its auto-generated anchor/slug changes with it—this is expected. The requirement is that same-document anchor links keep resolving: whenever you translate a heading, update every in-page link that targets it (](#...)) to the localized heading's new slug. Do not leave a link pointing at the original English slug once the heading is translated, and do not preserve an English anchor that no longer matches its heading. Anchors that point into non-localized files (or external URLs) keep their original target.
Image and asset paths point to the original assets unless a localized asset exists. Because localized files live under docs/<locale>/, rewrite source-relative paths as needed so they still resolve to the shared asset (for example, an app lesson at docs/<locale>/app/2-foo.md uses ../../_images/x.png to reach docs/_images/). Only point at a localized asset when a corresponding translated image actually exists under the locale tree. Either way, the link must resolve to a real file.
Use the translator agent to perform the localization. It should follow the rules and guidelines defined for each target locale document in the rules directory.
Use the evaluator agent to assess the quality of the localized content. The evaluator checks for accuracy, cultural relevance, and overall quality, following the rules and guidelines defined for the target locale in the rules directory.
The evaluator scores the localized document against the locale's Evaluator Scoring Rubric (defined in the locale's rules/<locale>.md). The rubric uses two tiers: Tier A hard-fail criteria that must score 5, and Tier B graded criteria (1–5) that must score 4 or 5. A document passes only when every applicable Tier A criterion scores 5 and every applicable Tier B criterion scores ≥ 4. If anything falls short, return the document to the translator with specific notes and re-run the translate → evaluate loop until it passes, escalating to a human after the rubric's iteration cap.
rules directory (one <locale>.md per supported locale). Do not localize into unsupported locales.docs/<locale>/), unless a corresponding localized asset exists (see Markdown and formatting preservation).docs/<locale>/.