feat: welcome first contributors when PR opens

[trueberryless]

🧭 Context

I noticed we already have a welcoming messages for new contributors, however this message is not sent until the PR is merged. This way, maintainers are unknowingly during PR review that this is the first PR of the person. Therefore, I created a second action which writes and immediate message to the PR as soon as it gets opened.

📚 Description

This PR adds a new workflow which uses https://github.com/zephyrproject-rtos/action-first-interaction as this fork is more performant and flexible (see example issue) than the official action. It gives the new contributor confidence and tells them what all those bot messages mean, so they are not overwhelmed.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Mar 24, 2026 6:40am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Mar 24, 2026 6:40am
npmx-lunaria	Ignored		Mar 24, 2026 6:40am

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: babbfac3-c535-4855-84e0-411643cc76ec

📥 Commits

Reviewing files that changed from the base of the PR and between f7ad8ca and bf5396d.

📒 Files selected for processing (1)

• .github/workflows/welcome-open.yml

✅ Files skipped from review due to trivial changes (1)

• .github/workflows/welcome-open.yml

---

📝 Walkthrough

Walkthrough

Renames the workflow display name in .github/workflows/welcome-close.yml from welcome to Claim Contributor Message. Adds a new workflow .github/workflows/welcome-open.yml named “Welcome Message” that triggers on pull_request_target events of type opened for the main branch, grants pull-requests: write permission, and defines a greeting job (conditioned on github.repository equalling npmx-dev/npmx.dev) which runs on ubuntu-latest and executes zephyrproject-rtos/action-first-interaction pinned to a specific commit SHA with a multiline pr-opened-message.

Suggested reviewers

• whitep4nth3r

🚥 Pre-merge checks | ✅ 1

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description check	✅ Passed	The pull request description clearly explains the context, motivation, and implementation details of adding a new welcome workflow for first-time contributors.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[ghostdevv]

Maybe we could do both messages? The opentelling them to ask any questions they might have and/or join the discord and then the close message telling them congratulations and you can go to here to get a contributor role

[trueberryless]

Maybe we could do both messages? The opentelling them to ask any questions they might have and/or join the discord and then the close message telling them congratulations and you can go to here to get a contributor role

Awesome idea, so many welcomes, I'm almost overwhelmed.

[trueberryless]

I also adapted the new action to use a fork of the first-interaction action, because the original is not as performant (because it's not using the /search API) and would fail when no issue_message is passed. See more in this issue.

[ghostdevv]

I think they could be part of the same .yml file and then we could use the if on the job to detect the event? Not 100% though

[trueberryless]

I think they could be part of the same .yml file and then we could use the if on the job to detect the event? Not 100% though

I don't like putting them in one action because it adds a lot of unnecessary overhead that can cleanly be avoided because we have two different GitHub events (opened vs closed). So why not keeping them separated?

[ghostdevv]

I think they could be part of the same .yml file and then we could use the if on the job to detect the event? Not 100% though

I don't like putting them in one action because it adds a lot of unnecessary overhead that can cleanly be avoided because we have two different GitHub events (opened vs closed). So why not keeping them separated?

I lean towards one just to reduce the file count in the workflows dir - I thought that if we're using the if thing then it won't cost us anything?

[trueberryless]

I lean towards one just to reduce the file count in the workflows dir - I thought that if we're using the if thing then it won't cost us anything?

I wouldn't consider myself an expert in how GitHub Actions optimize such conditional steps or jobs. I was just thinking about the maintenance of one bigger workflow vs two smaller ones. But I guess more files in the workflow folder also doesn't make maintenance easier, so I would be okay to combine the two (it's just more prune to errors as always with GitHub Actions, let the trail and error begin 😅)

[ghostdevv]

I lean towards one just to reduce the file count in the workflows dir - I thought that if we're using the if thing then it won't cost us anything?

I wouldn't consider myself an expert in how GitHub Actions optimize such conditional steps or jobs. I was just thinking about the maintenance of one bigger workflow vs two smaller ones. But I guess more files in the workflow folder also doesn't make maintenance easier, so I would be okay to combine the two (it's just more prune to errors as always with GitHub Actions, let the trail and error begin 😅)

Yeaaa GitHub actions is ✨ fun ✨ - oki let's just leave it as two and if we need to we can merge them together later

[ghostdevv]

I also adapted the new action to use a fork of the first-interaction action, because the original is not as performant (because it's not using the /search API) and would fail when no issue_message is passed. See more in this issue.

where'd you find the fork? could we just use actions script like the close one?

[trueberryless]

We have been using the fork action for quite some time now in Starlight (ref) and it runs flawlessly (apart from yesterdays changes, where I tried to use the official action, but it's too restrictive).

I advise to use the fork one instead of a new script as it already works. You can also read many benefits of in this PR from HiDeoo.

[ghostdevv]

We have been using the fork action for quite some time now in Starlight (ref) and it runs flawlessly (apart from yesterdays changes, where I tried to use the official action, but it's too restrictive).

I advise to use the fork one instead of a new script as it already works. You can also read many benefits of in this PR from HiDeoo.

ah sweet, let's do it

[trueberryless]

fix: buy glasses

😂😂😂 I just can't anymore 🤣🤣🤣

[ghostdevv]

fix: buy glasses

😂😂😂 I just can't anymore 🤣🤣🤣

this is why they invented squash merging 😌 😂