issue-reply

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.