verify-changesets workflow fails and missing changesets are not guided

[aradhyacp]

Bug Description

Changeset workflow fails for fork contributors + missing changeset guidance

Hi team,

While creating PRs and reviewing PRs from other contributors, I noticed a couple of recurring issues related to the changeset workflow. Initially I did not pay much attention to it, but after seeing it repeatedly across multiple PRs, I thought it would be good to bring it into notice.

---

1. Workflow fails for fork PRs when a changeset is included

Whenever a PR from a fork includes a .changeset/*.md file, the Verify Changesets workflow fails immediately with:

Error: Input required and not supplied: app-id

From what I understand, this happens before the actual validation runs and seems related to the GitHub App secrets not being available for fork-based PR workflows.

Because of this, contributors who correctly include a changeset end up getting a failing workflow.

---

2. Missing changesets are not enforced or guided

Changesets are mentioned as required, but currently PRs without a changeset do not trigger any workflow or guidance.

Maybe instead of silently passing, the workflow could leave a small friendly reminder comment like:

"Dear developer, please attach a changeset — it helps us a lot with release management."

This could help contributors understand the expectation without confusion.

---

Just wanted to report this since it seems to affect contributor experience repeatedly across PRs.

Thanks

Steps to Reproduce

1. Fork the repository and create a new branch
2. Add a .changeset/*.md file in the PR
3. Open a PR from the forked repository to vercel/streamdown:main
4. Observe the Verify Changesets workflow failure:

Run actions/create-github-app-token@v1
/home/runner/work/_actions/actions/create-github-app-token/v1/dist/main.cjs:42555
  throw new Error("Input required and not supplied: app-id");

Error: Input required and not supplied: app-id
    at Object.<anonymous> (/home/runner/work/_actions/actions/create-github-app-token/v1/dist/main.cjs:42555:9)
    at Module._compile (node:internal/modules/cjs/loader:1521:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1623:10)
    at Module.load (node:internal/modules/cjs/loader:1266:32)
    at Module._load (node:internal/modules/cjs/loader:1091:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:164:12)
    at node:internal/main/run_main_module:28:49

Node.js v20.20.2

5. Create another PR without a changeset file
6. Notice that no workflow guidance/check runs for missing changesets

Expected Behavior

• PRs from fork contributors that include a changeset should successfully run the verify-changesets workflow
• If a PR does not include a changeset, contributors should receive a friendly reminder/guidance message instead of no feedback

Example suggestion:

"Dear developer, please attach a changeset — it helps us a lot with release management."

Actual Behavior

• PRs containing .changeset/*.md files fail immediately because GitHub App secrets are unavailable in fork PR workflows
• PRs without changesets bypass the workflow entirely and receive no guidance or reminder

Code Sample

Streamdown Version

2.5.0

React Version

19.2.6

Node.js Version

No response

Browser(s)

No response

Operating System

None

Additional Context

This seems to affect external contributors repeatedly when opening PRs from forks. The changeset validation itself does not appear to run because the workflow fails earlier during GitHub App token generation.

[aradhyacp]

pull_request_target would probably solve the failing workflow issue in this case since repository secrets become available there.

But I also understand that using pull_request_target carelessly is basically a way to shoot your own leg if untrusted PR code ever gets executed in that privileged context.

Recent supply-chain worm attacks were propagated through this exact pattern (“Pwn Request”-style workflows), where malicious fork PRs abused privileged GitHub Actions pipelines to poison caches/artifacts and eventually compromise release infrastructure.

So I was wondering if there is another safer approach here for handling fork contributor validations without relying on pull_request_target directly.