SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsmaintain-translated-skills

maintain-translated-skills

Writing & research

View repository

Updated 10-16 09:44

About this skill

Maintain Translated Skills

Use this skill when maintaining a localized version of a skill repository.

Use this skill to maintain a localized version of a skill repository.

This skill is for content localization, not Git fork synchronization.

This skill is forcontent localization, not Git fork synchronization.

Core Rule

Translate natural-language prose. Preserve behavior-critical content exactly.

Translate natural-language descriptions; behavior-critical content must be preserved as-is.

Preserve:

  • directory names and skill folder names
  • slash commands and CLI commands
  • code blocks and inline code
  • file paths, URLs, package names, tool names, API identifiers, and env vars
  • YAML, JSON, TOML, and frontmatter keys
  • SKILL.md frontmatter name values
  • labels, issue states, or terms that the target repo policy marks as protected

Preserve directory names, skill names, commands, code, paths, URLs, package names, tool/API/env identifiers, structured configuration keys, frontmatter name, and the protected terms declared in the policy.

When unsure whether a span affects behavior, preserve it and flag it for review.

When unsure whether something affects behavior, preserve it as-is and flag it for maintainer review.

Required Target Policy

Before changing a translated repo, find its policy file:

.skill-localization/policy.json

If it does not exist, create or ask for one before a broad refresh. For narrow one-file edits, infer cautiously and recommend adding the policy afterward.

Before making changes, first read .skill-localization/policy.json. A broad refresh cannot lack a policy; a narrow single-file modification may be cautiously inferred, but adding a policy should be recommended.

Read references/policy-schema.md from this skill repo when you need field details.

When field details are needed, read this skill repository's references/policy-schema.md。

Read references/localized-readme-pattern.md before creating or rewriting a target repo README.

Before creating or rewriting the target repository's README, first read references/localized-readme-pattern.md。

Workflow: Initial Localization Setup

  1. Inspect the source repo and target repo shape.
  2. Create .skill-localization/policy.json in the target repo.
  3. Set upstreamRepo, localizedRepo, locale, public/private buckets, manifests, index files, protected patterns, and validation commands.
  4. Translate prose-bearing files.
  5. Keep executable support files only when they are needed by the translated repo.
  6. Update README and bucket indexes to describe the localized repo as a real user entry, not as translation notes only.
  7. Run the portable validator and target repo validation commands.

Initial localization: first establish the policy, then translate prose-bearing files, preserve necessary executable files, update the public index, and finally verify.

Workflow: Upstream Content Refresh

  1. Treat upstream as a content source, not as repository-management authority.
  2. Compare source and target content files to identify new, changed, and removed items.
  3. Translate new and changed natural-language prose.
  4. Preserve protected spans from the target policy.
  5. Keep localized install commands pointed at localizedRepo.
  6. Do not import upstream issue labels, release state, CI policy, branch policy, or maintainer metadata unless the target policy explicitly asks for it.
  7. Update public indexes and manifests according to publicBuckets, privateBuckets, indexPaths, and manifestPaths.
  8. Record a concise sync note in the target README when that repo uses one.
  9. Run validation and report review flags.

Upstream refresh: treat upstream as a content source, do not import upstream repository governance state; synchronize the public index and manifest according to the policy.

Workflow: Index And Manifest Maintenance

Public skills are the skills under publicBuckets.

Public skills are determined by publicBuckets .

For each public skill:

  • it should appear in configured public indexes
  • it should appear in configured manifests
  • README entries should link the skill name to its SKILL.md

Every public skill should appear in the public index and manifest, and README entries should link to the corresponding SKILL.md。

For each private skill:

  • it must not appear in public indexes
  • it must not appear in public manifests
  • it may still have a bucket README if the target repo intentionally documents private/internal content

Private, draft, deprecated, or personal skills should not enter the public index and public manifest.

Workflow: Review And Release

Run the portable validator:

node /path/to/skills-localizer-zh-CN/scripts/validate-translated-skills.mjs --root /path/to/translated-repo

Then run the target repo's validationCommands.

First run the portable validator, then run the verification commands in the target repository's policy.

Final report should include:

  • changed files
  • translated files
  • copied or preserved files
  • removed or stale files
  • index and manifest changes
  • validation results
  • review flags
  • invariant checks for install paths, code blocks, frontmatter, paths, identifiers, and Markdown structure

The final report should list changes, translations, preserved/copied items, deletions/stale items, index/manifest, verification results, review flags, and key invariants.

Output Discipline

Do not paste full command output into README files.

Do not paste full command output into the README.

When rewriting README files, make the first viewport useful to target-language users: identity, problem solved, install command, and immediate next action. Keep translation strategy, sync logs, and validation notes secondary.

When rewriting the README, the first screen should serve target-language users first: who I am, what problem I solve, how to install, and what to do immediately after installation. Put translation strategy, synchronization records, and verification notes later.

Keep maintainer-facing sync notes concise.

Keep maintenance records brief.

Prefer small, reviewable patches. Do not bundle unrelated repo-management changes into a localization refresh.

Prefer small, reviewable patches; do not mix unrelated repository governance changes into a localization refresh.