chore: add repository maintenance skills (#9915)

Author: Laffery

.agents/skills/changelog-collect/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: changelog-collect
+description: Collect and draft NG-ZORRO changelog entries between releases or branches. Use when asked to compare release ranges, collect PR changes, or prepare changelog content before release staging.
+---
+
+# NG-ZORRO Changelog Collection
+
+Use this skill to analyze a release range and prepare a reviewable changelog draft. Use `version-release` for version bumps, release branches, Azure publishing, and writing the final release files.
+
+Establish the range from the requested tags or branches. Inspect the commits in that range and associated pull requests when available; use the complete branch delta, not commit subjects alone. Compare changed public APIs, documentation, and user-visible behavior when a commit message is ambiguous.
+
+Draft entries in the existing root [`CHANGELOG.md`](../../../CHANGELOG.md) style:
+
+- group public changes under the conventional generated headings such as Features, Bug Fixes, Performance Improvements, and Breaking Changes;
+- keep component scopes and API identifiers accurate;
+- describe the effect on library users rather than the implementation; and
+- retain issue or PR references when they identify the public change.
+
+Exclude pure formatting, CI, routine tooling, internal refactors, and tests unless they change the distributed package, public API, documented behavior, accessibility, or performance in a user-relevant way. Treat dependency updates case by case: retain them only when their externally visible consequence is known.
+
+Call out breaking changes, deprecations, and migration requirements explicitly. Present the range, draft entries, excluded changes, and unresolved items for review before editing changelog files. Do not change versions or stage a release as part of collection.

.agents/skills/commit-msg/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: commit-msg
+description: Generate a conventional commit message for staged NG-ZORRO changes. Use when asked for a commit message, a git commit title, or a summary of staged changes.
+---
+
+# NG-ZORRO Commit Message
+
+Generate a commit message from the change that will actually be committed. Inspect `git status --short`, `git diff --cached --stat`, `git diff --cached`, and recent commit subjects before drafting it. If nothing is staged, say so; include unstaged changes only when the user asks.
+
+Follow `commitlint.config.js` and `CONTRIBUTING.md` as the authoritative format:
+
+- use `type(scope): subject`, with an optional scope;
+- choose one of `build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `release`, `revert`, `style`, or `test`;
+- use `module:<component>` for a component scope, or one of `showcase`, `release`, `packaging`, `changelog`, and `schematics` where applicable;
+- write an imperative, lower-case subject without ending punctuation, keeping each line within 100 characters; and
+- add a body or footer only when the user asks, the change needs motivation, or it carries a breaking-change or issue-closing reference.
+
+Summarize the common intent of the entire staged set rather than listing files or copying the last commit. If the staged set has unrelated changes, point out the split before recommending a deliberately broad subject.
+
+Return only the proposed subject by default. Explain the choice only when requested.

.agents/skills/create-pr/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: create-pr
+description: Prepare or create an NG-ZORRO pull request using the repository template. Use when asked to open, draft, summarize, or create a PR for branch changes.
+---
+
+# NG-ZORRO Pull Request
+
+Prepare a PR from the whole branch delta, not only the working tree or most recent commit. Inspect the current branch, remotes, its probable base, `git log <base>..HEAD`, and `git diff <base>...HEAD`. Use a user-specified base when present; otherwise infer it from repository state and flag uncertainty. `master` is the normal contribution target, while release and maintenance PRs must follow the project release workflow.
+
+## Target repository
+
+Open contribution PRs against `NG-ZORRO/ng-zorro-antd`; use `master` unless the user specifies another target. Resolve the PR destination independently of local remote names, which are not part of the workflow contract. Compare against the target repository's base branch, inspect that repository for an existing matching PR, and identify the owner and branch for the cross-repository head.
+
+When presenting a PR proposal, state the target repository and base branch alongside the head in `<owner>:<branch>` form. After confirmation, re-check all three values before pushing and creating the PR.
+
+Read and fill [`.github/PULL_REQUEST_TEMPLATE.md`](../../../.github/PULL_REQUEST_TEMPLATE.md) rather than inventing a body structure. Preserve its sections, remove instructional comments, and check only items supported by the branch contents and validation actually performed.
+
+Draft:
+
+- an English title that summarizes the branch's principal user-visible change and follows the repository's commit-message convention;
+- the PR type matching the main outcome;
+- current and new behavior, including the linked issue when known;
+- an accurate breaking-change decision and migration information when applicable; and
+- other information that helps review, such as focused validation or screenshots for visible changes.
+
+Treat site-only, documentation-only, test-only, CI, and internal maintenance changes as such; do not manufacture user-facing behavior or release notes for them. For a release PR, defer to `version-release`.
+
+Present the proposed target repository, base branch, head, title, body, and any assumptions for user confirmation before pushing a branch or calling `gh pr create`. Then create the PR only with the confirmed content.

.agents/skills/feature-sync/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: feature-sync
+description: Sync an Ant Design React component or feature into NG-ZORRO. Use when checking or porting upstream APIs, behavior, styles, demos, documentation, or tests.
+---
+
+# Ant Design React Sync
+
+Turn upstream functionality into an Angular implementation that fits NG-ZORRO's public API and maintenance model. Follow the repository's `AGENTS.md` first; it is the source of truth for the current Angular coding standards and global quality requirements.
+
+## Establish the Upstream Contract
+
+Inspect official upstream source and documentation before changing code. Read demos, tests, and changelog entries when they clarify the requested scope.
+
+Establish:
+
+- the public API, defaults, input boundaries, and deprecations;
+- user-observable behavior, including interaction states, keyboard behavior, semantics, and animation;
+- styling, theme tokens, and composition model; and
+- the upstream version that introduced the target capability.
+
+Use source and documentation as the contract. Changelog entries provide version and historical context, not a substitute for either. Distinguish an upstream capability that has not yet been ported from behavior that currently diverges from upstream.
+
+## Map to Angular
+
+Do not translate React source line by line. Preserve the public semantics while choosing the smallest, clearest Angular boundary.
+
+Decide deliberately:
+
+- how React props, callbacks, children, refs, and context map to Angular public APIs and composition;
+- whether the capability belongs in a component, directive, service, or existing extension point;
+- whether it needs browser-only DOM access, layout measurement, or side effects, and how it remains compatible with SSR and render timing; and
+- whether Angular CDK or an existing NG-ZORRO public utility already solves the problem.
+
+Translate upstream CSS-in-JS styling into the repository's Less theme variables and mixins. Keep theme defaults in Less; use ordinary inline styles only for public inputs whose values are genuinely runtime-dependent. Introduce CSS custom properties only when an existing integration specifically requires runtime inheritance or consumer customization.
+
+When framework differences prevent a one-to-one mapping, choose an Angular API consistent with established repository patterns and document intentional differences.
+
+## Integrate
+
+Study comparable components before deciding the necessary integration points. Update public exports, styles, demos, documentation, tests, and site-generation inputs only when the feature requires them.
+
+Treat generated artifacts according to the repository's tracking policy. Change the source of a generation pipeline instead of editing its output directly.
+
+## Verify
+
+Verify the upstream contract that was ported, not only implementation details.
+
+1. Start with focused tests for defaults, critical states, and boundary inputs.
+2. Run the repository checks, builds, and documentation generation appropriate to the changed surface.
+3. Inspect generated output when the work affects presentation, interaction, or documentation.
+4. Use `git diff --check` to catch whitespace and patch errors.
+
+## Deliver
+
+State the upstream scope that was synchronized, intentional framework differences, and the validation performed. Stage, commit, push, or create a pull request only when the user explicitly requests it.

.agents/skills/issue-reply/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: issue-reply
+description: Triage and draft replies for NG-ZORRO GitHub issues. Use when asked to review, answer, label, close, or maintain issues.
+---
+
+# NG-ZORRO Issue Reply
+
+First read the issue body, labels, linked issues or pull requests, and discussion. Classify the report as a reproducible bug, feature request, usage question, duplicate, or insufficient/invalid report. Check existing component documentation, APIs, demos, issues, and changelog entries before deciding that functionality is absent or a regression is unresolved.
+
+Write in the language used by the reporter's issue body. Keep the response specific, polite, and actionable. Do not promise an implementation date or acceptance of a feature.
+
+Apply the repository's community policy from `CONTRIBUTING.md` and `.github/nz-boot.yml`:
+
+- For a bug without a minimal reproduction, request a StackBlitz reproduction or minimal repository and use the configured `Need Reproduce` / `Need More Info` flow.
+- For a valid reproducible bug, recommend the appropriate component label; use `Component: <component>` where the report is clearly owned by one component.
+- For a feature request, check whether an existing API already solves the scenario before discussing a new API. Major features need an issue discussion; small features may be proposed as a PR.
+- For a usage question, help with a documented API when possible; otherwise direct support questions to the channels named in `CONTRIBUTING.md`.
+- For a duplicate, point to the canonical issue and explain the closure succinctly.
+- Do not close uncertain bugs, active discussions, or valid feature requests. The repository's no-response automation handles stale `Need More Info` issues after seven days.
+
+For any request that would comment, label, assign, reopen, or close an issue, first produce a triage summary and proposed response/actions. Perform GitHub mutations only after the user confirms the proposal.

.agents/skills/test-review/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: test-review
+description: Review the value of NG-ZORRO tests. Use when asked whether a test should be kept, rewritten, or removed, especially for duplicated coverage or implementation-detail assertions.
+---
+
+# NG-ZORRO Test Review
+
+Review tests for the public contract they protect; this is a review task, not a request to add tests or change production code. Inspect the relevant issue, documentation, demos, implementation, and nearby Vitest specifications as needed. Do not run tests unless the user asks for execution evidence.
+
+State the claimed contract in observable terms: given a condition, a consumer should observe a result. A useful expected value has an independent source such as a reported regression, public API, documented behavior, accessibility semantics, browser behavior, or a user-visible result.
+
+Prefer assertions on rendered DOM, ARIA semantics, emitted outputs, public API behavior, and interaction outcomes. Treat assertions of private helpers, intermediate state, temporary classes, CSS custom properties, or isolated style declarations as implementation-coupled unless the test has an independent visual or compatibility contract.
+
+Check whether an existing spec already protects the same condition. Classify each reviewed test as:
+
+- **Keep** — independently specified, externally observable, and non-duplicative.
+- **Rewrite** — the intended regression is valid but its assertion is coupled to implementation.
+- **Remove** — the expected value is derived from the same implementation, only proves existence, or duplicates an existing contract.
+
+Lead with the classification and give the few strongest reasons. Offer a rewrite direction only when requested.

.agents/skills/version-release/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: ng-zorro-version-release
+name: version-release
 description: NG-ZORRO/ng-zorro-antd repository release workflow. Use this skill whenever the user mentions 发版, 发布版本, release, release PR, stage-release, 升级版本号, changelog 发布准备, Azure publish, 部署官网, GitHub Release, or asks to prepare or execute an NG-ZORRO version release. This skill is project-specific and should be preferred over generic npm publish guidance.
 ---
 

.claude/skills

@@ -0,0 +1 @@
+../.agents/skills