Add noop tool call to changeset generator for skipped PRs

[Copilot]

The changeset generator workflow completes silently when no changeset is needed, making it unclear whether the workflow succeeded or was misconfigured.

Changes

Added early-exit logic with noop tool call

• New step 2 checks if changeset is needed before proceeding
• Calls noop({ message: "No changeset needed: <reason>" }) when skipping
• Stops immediately to avoid unnecessary processing

Defined skip criteria

• Documentation, tests, CI/CD configs, tooling, metadata, internal refactoring → skip
• Bug fixes, features, breaking changes, performance, dependencies → proceed

Example usage

// Agent now does this for docs-only PRs:
noop({
  message: "No changeset needed: documentation-only changes"
})

The workflow already has noop support configured (max: 1). This change ensures the agent uses it appropriately via explicit instructions in the prompt.

Original prompt

Update changelist generator to call the noop tool with a reason message when there is not change to review.

see https://github.com/github/gh-aw/actions/runs/21613937709

Custom agent used: technical-doc-writer
AI technical documentation writer for GitHub Actions library using GitHub Docs voice

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

Updates the Changeset Generator workflow instructions so that when a PR doesn’t warrant a changeset, the agent explicitly calls noop with a reason and exits instead of completing silently.

Changes:

• Adds an early “changeset needed?” decision step with explicit noop({ message: ... }) guidance for skip cases.
• Documents skip/proceed criteria for when to generate a changeset.
• Renumbers subsequent steps to account for the inserted decision step.

Comments suppressed due to low confidence (1)

.github/workflows/changeset.md:78

• Step 2 lists all CI/CD configuration changes under .github/workflows/ and .github/actions/ as "no changeset needed", but later guidance treats new shared workflows as release-note-worthy (patch). If shared workflows live under .github/workflows/, this rule will cause the agent to skip changesets for user-facing workflow/action changes. Please narrow the skip rule (e.g., skip only internal pipeline changes) or explicitly carve out reusable/shared workflows/actions that should still get a changeset.

   - CI/CD configuration changes (.github/workflows/, .github/actions/)
   - Development tooling changes (Makefile, scripts/, build configs)

---

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

[Copilot]

The skip criteria in step 2 says documentation/test/tooling/internal refactors should not require a changeset, but step 4 still categorizes docs/refactoring/tooling as valid patch change types and states they're always patch level. This is contradictory and may lead the agent to both skip and/or generate a changeset for the same PR type. Consider updating step 4 to explicitly apply only "if a changeset is needed" and removing docs/refactoring/tooling from the patch examples (or adjusting the skip criteria accordingly).

Suggested change

	4. **Determine the Change Type**:
	- **major**: Major breaking changes (X.0.0) - Very unlikely, probably should be **minor**
	- **minor**: Breaking changes in the CLI (0.X.0) - indicated by "BREAKING CHANGE" or major API changes
	- **patch**: Bug fixes, docs, refactoring, internal changes, tooling, new shared workflows (0.0.X)
	**Important**: Internal changes, tooling, and documentation are always "patch" level.
	4. **Determine the Change Type (if a changeset is needed)**:
	- **major**: Major breaking changes (X.0.0) - Very unlikely, probably should be **minor**
	- **minor**: Breaking changes in the CLI (0.X.0) - indicated by "BREAKING CHANGE" or major API changes
	- **patch**: Bug fixes, performance improvements, dependency updates that affect functionality, new shared workflows (0.0.X)
	**Important**: When a changeset is required for internal-only, tooling, or documentation-related work (for example, when mixed with user-facing changes), it should always be recorded as "patch" level.

[Copilot]

The instructions say to call noop(...) and "stop immediately" when skipping, but they don’t explicitly say not to append a "Changeset" section to the PR description in that path. To avoid accidental PR-body updates when no changeset was created, consider adding a sentence that the workflow must not call update_pull_request when exiting via noop.