Enhance immediate-response workflow with Copilot features

[eyalgal]

Refactor GitHub Actions workflow to improve PR and issue responses with Copilot integration.
This pull request significantly enhances the .github/workflows/immediate-response.yaml workflow by splitting and improving the automation for responding to pull requests and issues. It introduces a Copilot-powered triage process for new issues, providing intelligent, actionable feedback to reporters and surfacing potentially related issues to reduce duplicates. The PR also updates the PR response message to set clearer expectations for contributors.

---

Before the change?

Comment with a generic message on new Issues/PRs.

After the change?

Workflow restructuring and messaging improvements:

• Split the previous single respond job into two distinct jobs: respond-to-pr for pull requests and triage-issue for issues, each with tailored triggers and permissions.
• Updated the PR response comment to clearly set expectations for contributors, mentioning both Copilot and human reviews, and improved message formatting.

Copilot-powered issue triage automation:

• Added a new triage-issue job that uses a GitHub Actions script to:
  • Analyze the issue type (bug, feature, documentation) based on the title.
  • Check for missing or placeholder responses in required and optional template fields.
  • Extract affected Terraform resources from the issue body.
  • Search for potential duplicate issues using keywords and resource names.
  • Fetch the latest release notes for context.
• Integrated a call to the GitHub Copilot Models API to generate a concise, actionable follow-up comment for the issue reporter, focusing on missing information and next steps.

Pull request checklist

• Schema migrations have been created if needed (example)
• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[github-actions]

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[Copilot]

Pull request overview

This PR refactors the .github/workflows/immediate-response.yaml GitHub Actions workflow to split PR vs issue automation and add Copilot Models–powered issue triage to generate more actionable, template-aware follow-up comments.

Changes:

• Split the prior combined responder into respond-to-pr (PR greeting) and triage-issue (issue triage + response).
• Updated PR greeting message to set expectations around Copilot + human triage.
• Added issue triage logic (template completeness checks, duplicate search, release context) and a Copilot Models API call to produce concise follow-up questions.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[austenstone]

Left two comments: one on missing [MAINT] handling in the issue-type parsing, and one small fix on the bot name (github-actions[bot]).

[robert-crandall]

I want to hold off on this PR. I view this as a cool and clever use case for what Copilot can do, but I do not want to experiment on this repository with unproven Copilot uses. This repository is already under-staffed, and potential improvements like this come with a real risk of increasing workload instead of reducing it. For now, let's implement Copilot only when it has proven its value. For example, I view CCR as a proven value.

When coming back to this PR, some non-exhaustive thoughts:

• I don't think this organization has Copilot enabled. That needs to be resolved before implementing this or CCR.
• The logic to review issues should move to a new file, and actions should call that file. That will make it easier to test and to review.
• The model chosen, gpt-40-mini, should be a variable

[eyalgal]

@robert-crandall I hear the concern about experimenting on an under-staffed repo, but I'd push back a bit on the framing here.

The current workflow is actively unhelpful: it promises "reviews twice a week, every Monday and Friday" which hasn't been true in a long time, and gives zero triage value. A maintainer's first touch on every issue is spent asking for basic info that the template already requested. With 40-50 new issues a month, that adds up fast.

This isn't an aggressive use of Copilot. It's template validation, duplicate search, and targeted follow-up questions. I simulated it against real issues from this repo, and in every case it asked for exactly what maintainers end up asking manually, sometimes hours later. I'm happy to share those simulations.

I'll monitor it closely after merge and we can roll back immediately if it creates noise instead of reducing it. But waiting for "proven value" on a workflow that replaces something already broken feels like the wrong bar.

Re: the specific suggestions: extracting the logic into a separate file and making the model a variable are good improvements, but I'd treat those as follow-ups rather than blockers. The workflow works as-is, and for this use case gpt-4o-mini is the right fit. On Copilot being enabled: I requested a Copilot review on this very PR and it ran successfully, so it's enabled in some capacity. Happy to verify the exact scope, but it shouldn't block merging.