update MD by dispatch event pingcap/docs i18n-ja-release-8.5

Author: github-actions

markdown-pages/ja/tidb/release-8.5/.agents/skills/docs-pr-metadata-guard/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: docs-pr-metadata-guard
+description: Use when creating or editing pull requests in pingcap/docs so the PR template sections, version checkboxes, related-link fields, HTML comments, and description structure stay intact. Trigger on tasks involving PR creation, PR body updates, version selection, cherry-pick label decisions, or translating a PR from docs-cn.
+---
+
+# Docs PR Metadata Guard
+
+Use this skill for `pingcap/docs` GitHub pull request metadata work. The goal is to preserve the repository-required PR description structure while editing only the mutable fields.
+
+Before changing a PR body, read `.github/pull_request_template.md`.
+
+## Workflow
+
+1. Write PR titles and descriptions in English.
+2. For a new PR, start from `.github/pull_request_template.md` instead of writing the body from scratch.
+   - Copy the template into a local Markdown file and fill in the mutable fields.
+   - Submit with `gh pr create --body-file <local-file>`, or use `gh pr create -T .github/pull_request_template.md` to let `gh` load the template as the starting body text (the `-T` / `--template` flag for `gh pr create` takes a file path).
+   - Review the local file against the template before calling `gh`.
+3. Fill in the required sections with concrete information.
+   - **What is changed, added or deleted? (Required)**: describe what changed and why in clear, specific language. Do not leave this blank or fill it with a generic placeholder.
+   - **Which TiDB version(s) do your changes apply to? (Required)**: check at least one version checkbox. Follow the affected-version rules in `.agents/shared/repo-conventions.md`:
+     - Default to `master` only for general improvements, wording fixes, missing-content additions, and corrections not tied to a specific released behavior.
+     - Check the affected release branch(es) together with `master` when the change involves version-specific behavior, compatibility changes, changed defaults, or fixes in published docs.
+   - **What is the related PR or file link(s)?**: fill in the translation source link under `This PR is translated from:` when the PR is a translation from `docs-cn`. Fill in other reference links such as product PRs, issues, or related doc PRs under `Other reference link(s):`.
+   - **AI agent involvement**: when this section is present in the template, keep it intact. Check its checkbox only when the changes were primarily made by an AI agent on behalf of the PR author; otherwise leave it unchecked.
+   - **Do your changes match any of the following descriptions?**: check all that apply. If the change needs different wording on another branch, check `Need modification after applied to another branch` and comment `/label version-specific-changes-required`.
+4. Choose the correct base branch.
+   - Default to `master` for most documentation PRs.
+   - Use `release-8.5` for TiDB Cloud documentation changes (see `.agents/shared/repo-conventions.md` for TiDB Cloud conventions).
+   - Use a specific `release-X.Y` branch when the change is scoped to a single published version and does not apply to `master`.
+5. For an existing PR, update only the mutable sections.
+   - Safe targets: the description text under "What is changed, added or deleted?", the version checkboxes, the related-link fields, and the description checkboxes.
+   - Do not rename headings, reorder sections, or rewrite the template wholesale.
+6. Preserve hidden HTML comments exactly.
+   - Keep `<!--Tell us what you did and why.-->` unchanged.
+   - Keep `<!-- Fill in "x" in [] to tick the checkbox below.-->` unchanged.
+   - Keep `<!--Reference link(s) will help reviewers review your PR quickly.-->` unchanged.
+   - Keep `<!-- If yes, please comment "/label version-specific-changes-required" below to trigger the bot to add the label. -->` unchanged.
+   - Do not delete or rewrite any template comment that explains contributor behavior or bot behavior.
+7. Preserve the "Tips for choosing the affected version(s)" guidance block.
+   - The bold tips paragraph and the `CONTRIBUTING.md` link between the version heading and the checkboxes are part of the template structure. Do not delete, rewrite, or move them.
+8. Handle the first-time contributors' checklist correctly.
+   - If the contributor is not a first-time contributor, remove the entire "First-time contributors' checklist" section as the template instructs.
+   - If the contributor is a first-time contributor, keep the section and check the CLA checkbox after signing.
+9. Prefer file-based edits for GitHub metadata.
+   - Materialize the intended PR body into a local Markdown file.
+   - Review that file against the PR template before calling `gh`.
+10. After any PR body update, re-read the PR to verify the structure is intact.
+
+## Version checkbox rules
+
+The version checkboxes in the PR template follow a specific order from newest to oldest. When filling them in:
+
+- Do not add or remove version lines. The template defines the canonical list.
+- Do not reorder the version lines.
+- Check only the versions where the change should apply.
+- If a version is not in the template list, do not invent a new checkbox line.
+
+## Cherry-pick and label conventions
+
+- When a change applies to multiple versions, prefer a single PR on the latest applicable branch and use cherry-pick labels for remaining maintained versions.
+- Cherry-pick labels follow the pattern `needs-cherry-pick-release-X.Y` (e.g. `needs-cherry-pick-release-8.5`, `needs-cherry-pick-release-7.5`). There is also `needs-cherry-pick-master` for cherry-picks to master.
+- If branch-specific wording differences are expected, check `Need modification after applied to another branch` and add the `requires-version-specific-changes` label so cherry-pick reviewers know follow-up edits are required.
+- Use the repository's cherry-pick label workflow. Do not invent a custom multi-branch process.
+- Common non-cherry-pick labels for PRs:
+    - `type/bugfix`, `type/enhancement`, `type/refactor`, `type/compatibility-or-feature-change` for change type.
+    - `area/*` labels (e.g. `area/tidb-cloud`, `area/planner`, `area/br`) for the documentation area.
+    - `translation/from-docs-cn` when the PR is translated from a `docs-cn` PR.
+    - `translation/welcome` to invite community translation; `translation/no-need` when translation is not needed.
+
+## Quick checks
+
+- The PR body contains the "What is changed, added or deleted? (Required)" heading with a non-empty description below it.
+- At least one version checkbox is checked under "Which TiDB version(s) do your changes apply to? (Required)".
+- The version checkbox section preserves the template's canonical version list and order.
+- The "Tips for choosing the affected version(s)" paragraph and the `CONTRIBUTING.md` link are present between the version heading and the checkboxes.
+- The related-link fields (`This PR is translated from:` and `Other reference link(s):`) are present, even if left at their default values.
+- The `AI agent involvement` section is present when defined by the template, and its checkbox accurately reflects whether an AI agent primarily made the changes on the PR author's behalf.
+- The "Do your changes match any of the following descriptions?" section is present with its checkboxes intact.
+- The first-time contributors' checklist is either correctly filled in or removed entirely as instructed.
+- The base branch matches the change scope: `master` by default, `release-8.5` for TiDB Cloud, or a specific `release-X.Y` for version-scoped fixes.

markdown-pages/ja/tidb/release-8.5/AGENTS.md

@@ -0,0 +1,70 @@
+# Repository Agents Guide
+
+This repository is the source for the English TiDB documentation maintained in `pingcap/docs`.
+
+Use this file as the entrypoint for agent work in this repository.
+
+## Working approach
+
+Before making changes:
+
+1. Use `.agents/README.md` as the map of the repo-local AI guidance.
+2. Use a matching skill in `.agents/skills/` when the task is workflow-specific.
+3. Keep edits minimal and scoped to the requested task.
+4. Reuse existing wording, structure, and terminology unless there is a clear reason to change them.
+
+When rules conflict, follow this priority order:
+
+1. Direct user instructions
+2. Repository rules in this file
+3. Task-specific instructions in the selected skill
+4. General writing preferences
+
+## Start here
+
+Read `.agents/README.md` first when you need the current layout of repo-local AI guidance.
+
+## Use the repo skills
+
+Use the workflow-specific skills in `.agents/skills/` when they match the task:
+
+- `docs-pr-metadata-guard`: guard PR template structure when creating or editing pull requests — version checkboxes, required sections, HTML comments, related-link fields, and cherry-pick conventions
+
+If no existing skill matches the task, follow this file and keep the change narrowly scoped.
+
+## Repository expectations
+
+- Preserve the repository's Markdown, heading, list, link, and front matter conventions.
+- Use lowercase file names and separate words with hyphens, for example, `x-y-z.md`, unless the existing file path already follows a different required pattern.
+- Reuse existing approved terminology and phrasing whenever possible.
+- Prefer consistency with surrounding documents over stylistic rewrites.
+- Respect the repository's version and branch rules.
+- Prefer existing scripts, workflows, and repository patterns over ad hoc reinvention.
+
+## Content guardrails
+
+- Do not change technical meaning unless the task explicitly requires it.
+- Do not silently rewrite commands, code samples, configuration names, API fields, UI strings, or JSON unless they are part of the requested task or are clearly incorrect.
+- Do not expand the scope from a local fix into a broad rewrite unless the user asks for that.
+- Do not introduce new terminology when an established term already exists in the repository.
+
+## Validation
+
+When the task changes Markdown, run relevant checks when practical:
+
+- `./scripts/markdownlint <files>`
+- `./scripts/verify-links.sh` for link-sensitive changes
+
+If a full-repo check is too expensive for the task, validate only the files you changed.
+
+## Commit and PR boundaries
+
+- Do not commit, push, create branches, or open PRs unless the user explicitly asks for it.
+- Before any write action that affects Git history or GitHub state, make sure the requested scope is clear.
+- When reporting completed work, summarize changed files, key decisions, and any issues that still need human review.
+
+## Scope discipline
+
+Keep changes scoped to the requested task and avoid mutating unrelated files.
+
+When a requested change might affect other docs, note the possible cross-file impact and only update additional files when the user asks or the selected skill explicitly requires it.