// Post a standard update comment to a GitHub issue that is already in the chat context. Use when the user says "/post-update", asks to update an issue after a fix has landed, or wants issue participants told that the fix will be in the next release and invited to leave feedback once they can test it.
Reimagine this repository from first principles using the current product and user experience as the target. Use when the user says "/expert-reset", asks how the project should be rebuilt if starting again, wants bold architecture or component-structure recommendations, or wants a research-only reset plan unconstrained by current implementation details.
Provide an expert codebase review for this repository. Use when the user says "/expertreview", asks for an expert review, wants refactoring or codebase improvement recommendations, wants consistency and quality assessed, or asks how to reduce duplication, improve component use, preserve the end-user experience, and keep upgrades cleanly migratable.
Alias for the repository pull request review workflow. Use when the user says "/pr-review" or asks to review a newly submitted or open GitHub pull request, document what changed, evaluate code quality, security and integration risk, run the relevant local checks, and recommend whether to merge, request improvements, or hold.
Review a new or open pull request for this repository with an adversarial security and quality lens. Use when the user says "/pr", "/pr-review", "check the new PR", "is this PR safe to merge", "look for malicious code", "review outside contribution", "should I merge this PR", or asks for reasons not to merge a pull request.
Summarize user-facing project changes from the last 7 days. Use when the user says "/updates", asks for recent updates, wants a changelog-style summary, or wants the most important feature changes from the past week.
| name | post-update |
| description | Post a standard update comment to a GitHub issue that is already in the chat context. Use when the user says "/post-update", asks to update an issue after a fix has landed, or wants issue participants told that the fix will be in the next release and invited to leave feedback once they can test it. |
Post a short, friendly GitHub issue comment saying the change will be included in the next release and asking the reporter to leave feedback after testing.
Identify the GitHub issue from the current chat context.
Confirm the target issue is in this repository unless the chat clearly points somewhere else.
Post this comment, adjusting only the greeting if the reporter's name is obvious:
Thanks for reporting this. The fix has been merged and will be included in the
next release.
Once you have a chance to try that release, please leave feedback here and let
us know whether it resolves the issue for you.
Do not close the issue. The project owner wants to test or receive feedback before issues are closed.
After posting, reply with the issue number and a short confirmation. If the platform returns a comment URL, include it.
Prefer the GitHub app/connector when available. If not, use the GitHub CLI from the repository checkout, for example:
gh issue comment <issue-number-or-url> --body-file <temporary-body-file>
Use a temporary file for the comment body to avoid shell quoting mistakes.