Implemented OSS contribution gating with GitHub Actions

Summary

Closed, Completed

Plan
Outlined experiment for OSS contribution gating.
Plan
Build
Provided GitHub Actions implementation for PR gating.
Build
Understand
Verified contributor roles via GitHub event payload.
Understand
Build
Bootstrapped approved contributors list from merged PRs.
Build
Edit
Fixed WASM loading and updated packaging scripts.
Edit

here's an idea:

Strongly recommended reading by @tldraw on how to deal with OSS contributions in the age of agents.

I think I'm going to setup a little experiment in pi-mono along these lines, using a simple GH hook.

New contributor sends PR > PR gets automatically closed if they contributors GH habdle is not in the approved PR submitters file in the repo, with a comment to open an issue first, requesting a concise, minimal description of what they want to do and why
New contributor opens issue. If it passes requirements (not slop), I as the maintainer comment with lgtm, and a little GH hook puts their GH handle in the approved PR submitters file in the repo. They now become an approved PR submitter
Approved contributor sends PR, PR does not get closed, because they are in the approved list of PR submitters
If someone abuses their privilege, they get removed from the approved PR submitter list again

At no point is an approved contributor given access to the repo directly. The fine blog post alludes to the fact, that we may no longer need external contributions in code form. This possibly makes sense for established projects. But for new projects, code contributions are a signal.

I'm currently the only person with write access to the repo. Eventually I'd like to onboard high quality contributors, who I can trust not to slop up the code base, spreading out the load. Having them send actual code changes allows me to pick worthy individuals.

This aligns with the ideas expressed in @marlene_zw 's thread from yesterday by @giuseppegurgone

GitHub could actually introduce this concept of "approved PR submitter", but I suppose that'd take a while. A low tech solution like above seems simple enough to build and has good ergonomics.

tell me how we can implement this

The user wants to implement a GitHub webhook-based system for managing PR submissions from new contributors. Let me break down the requirements:

A file in the repo listing approved PR submitters (GitHub handles)
A GitHub webhook that triggers on PR creation:
- If submitter is NOT in the approved list → close PR with a comment directing them to open an issue first
- If submitter IS in the approved list → let PR stay open
Manual process: maintainer reviews issues, comments "lgtm" or similar, which triggers adding the user to the approved list
Ability to remove users from the list if they abuse privileges

Implementation options:

GitHub Actions - Most straightforward, no external server needed
- Trigger on pull_request opened event
- Check if author is in approved list file
- If not, close PR and comment
- Trigger on issue_comment event
- If maintainer comments with magic word, add user to approved list
External webhook server - More complex, requires hosting

GitHub Actions seems like the right choice here. Let me outline the implementation:

Files needed:

.github/APPROVED_CONTRIBUTORS - simple text file with one GitHub handle per line
.github/workflows/pr-gate.yml - workflow to check PRs
.github/workflows/approve-contributor.yml - workflow to add contributors when maintainer approves

Let me think through the logic:

PR Gate workflow:

Triggers on: pull_request types: [opened]
Gets PR author
Reads APPROVED_CONTRIBUTORS file
Also needs to check if author is a collaborator/owner (don't want to block the maintainer)
If author not in list and not a collaborator → close PR with comment

Approve Contributor workflow:

Triggers on: issue_comment created
Checks if commenter is a maintainer/collaborator
Checks if comment contains magic phrase (e.g., "lgtm" or "/approve-contributor")
If both conditions are met, add the issue author to APPROVED_CONTRIBUTORS file

This approach keeps things simple—just GitHub Actions and a text file, no external infrastructure needed.

This is a solid approach. Here's how to implement it with GitHub Actions (no external server needed):

Architecture

.github/APPROVED_CONTRIBUTORS - plain text file, one GitHub handle per line
.github/workflows/pr-gate.yml - closes PRs from unapproved contributors
.github/workflows/approve-contributor.yml - adds contributors when you comment a magic phrase on their issue

Implementation Details

PR Gate Logic:

Triggers on pull_request: [opened]
Skips repo collaborators (you and future trusted maintainers)
Checks if PR author is in the approved list
If not: closes PR with a friendly comment pointing them to open an issue

Approve Contributor Logic:

Triggers on issue_comment: [created]
Checks if commenter has write access to repo
Checks for magic phrase like /approve in comment
If both: commits the issue author's handle to the approved list

Edge cases to handle:

Bots (dependabot, etc.) should be auto-approved or skipped
Collaborators should bypass the check entirely
The workflow needs write permissions to commit to the approved list file

Trade-offs

GitHub Actions approach:

Free, no hosting
Runs in repo context, easy to audit
Can be slow (seconds to close a PR)

Alternative: GitHub App with webhook:

Faster response
More control
Requires hosting somewhere

Want me to write the actual workflow files? The Actions approach is simpler to start with and can always be replaced later if needed.

do we have access to handles from people that are actually part of the repo contributor list? then anyone from the "team" can "lgtm"

The user is asking whether GitHub Actions can check if the person commenting is a collaborator/contributor with write access to the repo, so that any team member (not just the owner) can approve new contributors by commenting "lgtm".

Yes, this is possible. GitHub Actions provides context about the commenter, and you can use the GitHub API to check their permission level on the repo.

There are a few ways to do this:

github.event.comment.author_association - This gives you values like OWNER, MEMBER, COLLABORATOR, CONTRIBUTOR, etc. This is available directly in the event payload.
GitHub API call to check collaborator permissions - You can call GET /repos/{owner}/{repo}/collaborators/{username}/permission to get the exact permission level.

The author_association field is the simplest approach:

OWNER - Repository owner
MEMBER - Member of the organization that owns the repo
COLLABORATOR - Has been invited to collaborate
CONTRIBUTOR - Has previously committed to the repo (but not necessarily a collaborator)
FIRST_TIMER - First time contributor
FIRST_TIME_CONTRIBUTOR - First contribution to this repo
NONE - No association

For this use case, we'd want to check for OWNER, MEMBER, or COLLABORATOR - these are people with actual repo access.

Let me give the user a concise answer.

Yes. GitHub provides author_association in the event payload for comments. Values include:

OWNER - repo owner
MEMBER - org member (if org repo)
COLLABORATOR - invited collaborator

So the workflow can check:

yaml

if: >  contains(fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'), github.event.comment.author_association)  && contains(github.event.comment.body, '/approve')

if: >  contains(fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'), github.event.comment.author_association)  && contains(github.event.comment.body, '/approve')

Anyone you've added as a collaborator to the repo can then /approve on issues.

There's also a CONTRIBUTOR association (has previous commits merged), but that's weaker since it doesn't imply trust, just past contributions. Probably want to stick with the three above.

Want me to write the workflow files now?

we also need to bootstrap the approved list with gh accounts that previously got their PRs merged

The user wants to bootstrap the approved contributors list with people who have already had PRs merged to the repo. This makes sense - existing contributors shouldn't be blocked.

I can use the GitHub CLI to get this information. Let me check what contributors have had PRs merged to pi-mono.

I could use:

gh pr list --state merged --json author to get merged PR authors
Or git log to get commit authors

Let me fetch this info first to show them who would be on the list.

Good point. Let me check who's already contributed:

Good, I have the list of people who have had PRs merged. Now I can create:

The APPROVED_CONTRIBUTORS file with these handles
The PR gate workflow
The approve contributor workflow

Let me write these files. I should probably exclude badlogic from the approved list since they're the owner and will bypass the check anyway via the collaborator check. Actually, it doesn't hurt to include them.

Let me write all three files.

Got 19 contributors with merged PRs. Here's the full implementation:

/var/folders/49/l4171l3n219_xwq30fmyzr8w0000gn/T/TemporaryItems/NSIRD_screencaptureui_jP3SLl/Screenshot\ 2026-01-18\ at\ 11.53.17.png gh shows +80 contributors, so this list seems wrong

You're right, I only got PR authors. Let me check commit authors instead:

That's 82 contributors from the GitHub API. Let me write the complete implementation:

Done. Three files created:

.github/APPROVED_CONTRIBUTORS - 81 existing contributors (excluding badlogic since you'll bypass as collaborator anyway)

.github/workflows/pr-gate.yml

Uses pull_request_target (needed to have write access to close PRs from forks)
Skips bots and collaborators
Checks against approved list (case-insensitive)
Closes unapproved PRs with instructions

.github/workflows/approve-contributor.yml

Triggers when OWNER, MEMBER, or COLLABORATOR comments /approve on an issue
Adds issue author to the approved list
Commits directly to main
Comments confirmation

To remove someone who abuses the privilege: just delete their line from APPROVED_CONTRIBUTORS manually.

You might also want a CONTRIBUTING.md that explains this process. Want me to add that?

i want lgtm to be the trigger word not /approved

Editedapprove-contributor.yml

Also need to update the PR close message:

Editedpr-gate.yml

Done. Both files updated. The trigger word is now lgtm (case-insensitive since contains() is case-sensitive by default in GitHub Actions expressions, but the string literal will match if the comment contains "lgtm" anywhere).

Actually wait, contains() in GitHub Actions expressions IS case-insensitive. Let me double check... No, actually it's case-sensitive. So "LGTM" won't match "lgtm". The user might want case-insensitive matching.

Actually let me check the GitHub docs... The contains function in GitHub Actions is case-insensitive for strings. So "LGTM", "lgtm", "Lgtm" would all match. Good.

Done. Now any collaborator commenting lgtm (case-insensitive) on an issue will add that issue's author to the approved list.

do a deep review of the files we just wrote, identify any bugs or issues and report them here

Listing review notes and potential bugs

Identified several issues: the APPROVED_CONTRIBUTORS header wrongly mentions /approve; GitHub Actions' contains is case-insensitive but may need word boundaries to avoid false matches; pull_request_target permissions lack issues: write though it's needed; caution advised against checking out during pull_request_target; main branch is assumed but should use the repo's default branch dynamically; approved contributors list is static from main which might affect fork PRs; bot skipping logic may miss some bots; comment body indentation includes unintended spaces from templates; author_association values can misrepresent actual permissions especially for collaborators outside the org.

Reporting approval workflow issues

Found that approvals can come from org members without repo access due to missing collaborator permission checks; the lgtm trigger matches partial phrases like "not lgtm," risking false approvals; bot-authored issues can receive unintended approvals; the comment links to CONTRIBUTING.md may be problematic if missing; reopening PRs doesn't trigger checks for newly approved contributors; concurrent commits to the approved list lack conflict handling; commit success isn't verified before commenting; pull_request_target permissions lack needed contents: read and issues: write, causing API call failures; hardcoded main branch refs ignore repo default branches; and documentation wrongly states /approve in headers while referencing lgtm.

Deep review findings:

Wrong trigger text in header
.github/APPROVED_CONTRIBUTORS still says “commenting /approve” but the trigger is now lgtm.
pr-gate.yml permissions are too narrow
You set only pull-requests: write. The workflow also calls:
- repos.getContent which needs contents: read
- issues.createComment which needs issues: write
  Without those, the workflow will fail.
approve-contributor.yml uses author_association as a permission check
MEMBER can include org members with no repo access. That lets any org member approve contributors.
Better: call repos.getCollaboratorPermissionLevel and check for admin or write.
Default branch hardcoded to main
Both workflows read or checkout main. If the repo default branch changes, they break. Use context.payload.repository.default_branch or github.event.repository.default_branch.
lgtm matching is too loose
contains(..., 'lgtm') matches phrases like “not lgtm” or “lgtm? no”. If you want strict approval, use a regex for ^lgtm$ or a command like /lgtm.
PR close comment link is relative
../blob/main/CONTRIBUTING.md might not render correctly in issue comments. Use an absolute link.

If you want, I can fix these.

please fix

Refining approval workflow and file editing

I'm updating file editing to use full reads and edits rather than partial writes, adjusting header comments and permissions, and planning to modify the approval flow to always run on issue comment creation. I'll move author association checks into a GitHub script step for clarity, use a case-insensitive 'lgtm' check in the job condition to skip unnecessary runs, and add stricter regex validation in the script itself.

Defining strict LGTM check and permission gating

I'm adding a regex to strictly match 'lgtm' in comments and enforcing collaborator permission checks before proceeding. The PR gate workflow will use the repository's default branch dynamically and include precise permissions. For the approval workflow, I'll implement output flags from the script to conditionally run commit and comment steps, avoiding unnecessary actions when permissions or LGTM checks fail.

EditedAPPROVED_CONTRIBUTORS

Refining contributor approval workflow

I'm rewriting the approval action to carefully handle outputs and conditional logic, adding try/catch around permission checks to treat non-collaborators as skipped, and ensuring correct checks for existing approvals before updating the approved list.

Adding conditional commit and comment steps

I'm implementing commit and comment steps that run only if a contributor was successfully added, avoiding duplicate approval comments by checking the update step's output.

Summary:

Updated .github/APPROVED_CONTRIBUTORS header to say lgtm.
Fixed pr-gate.yml permissions, default branch handling, and absolute CONTRIBUTING.md link.
Hardened approve-contributor.yml with exact lgtm match, real collaborator permission check, default branch checkout, and guarded commit/comment steps.

No tests run.

ok, now we also need a CONTRIBUTING.md or whatever is the defaulft file for that. ask me questions how it should look and what hsould be in it.

What should CONTRIBUTING.md include? Please specify:

Tone and length.
Steps for new contributors.
Issue template requirements and what counts as slop.
Any restrictions on AI use.
Where to document the lgtm approval flow.
Any other rules (tests, formatting, changelog, commit messages).

ask again opus you are better at writting

The user wants me to ask better, more thoughtful questions about what should go in the CONTRIBUTING.md file. Let me think about what I need to know to write a good one.

Key questions:

What's the project about and who's the target contributor?
What's the tone - friendly, strict, technical?
The approval flow is unique - how prominently should it be featured?
What technical requirements exist (tests, linting, etc.)?
What makes a good issue vs slop?
Any AI/agent usage policy?
PR expectations - size, scope, testing?
Communication preferences?

Let me ask these in a clear, direct way.

Questions for CONTRIBUTING.md:

The approval gate - Should this be front and center as the first thing people see, or buried in a "Before your first PR" section?
What makes a good issue? - You mentioned "concise, minimal description." Any specific structure you want (problem/solution format)? Examples of good vs bad issues?
AI/agent policy - Do you want to explicitly state expectations around AI-generated contributions? The PR gate message mentions "AI slop will be closed" but should the guide expand on what that means?
Technical requirements - Should contributors run npm run check before submitting? Any test expectations? Do you want them to update CHANGELOG.md or do maintainers handle that?
PR scope - Preferences on PR size? One issue per PR? Rebasing vs merge commits?
What's off-limits? - Any areas of the codebase where you don't want external contributions? Features you'll reject outright?
Communication style - Where should contributors ask questions if they're unsure (issues, discussions, Discord)?
Length/tone - Short and punchy, or thorough? Friendly, neutral, or "read this carefully or get rejected"?

biggest concern is: contributors must understand what the code changes do and how they interact with the rest of the system. just sending any old agent generated slop does not do.

approval gate should be explained concisely.
can be free form, must NOT be ai generated slop with dozens of paragraphs. should use human voice at least in the intro. technical descriptions can be generated by agent, but must be as concise as possible. if it doesn't fit on a single screen, it is likely bad.
ai generated code changes in PR form (once approved) are fine, as long as the contributor can explain what it does and how it interacts with the rest of the code.
yes, npm run check must pass, ./test.sh must pass. if contributor adds a new provider to pi-ai, they must add all the required tests as outlined in AGENTS.md
pr scope is not needed
anything that does not conform to pi's philosophy (minimal core, anything else should be an extension) is unlikely to get approved or merged
issues or discord
short, punchy, friendly. goal with contributing.md is to minimize the amount of time i need to spend on wading through AI slop

The user wants a concise, punchy CONTRIBUTING.md that:

Explains the approval gate concisely
Sets expectations about AI slop - contributors must understand their code
Allows AI-generated code if contributor can explain it
Technical requirements: npm run check, ./test.sh must pass
Philosophy: minimal core, extensions for everything else
Communication: issues or Discord
Tone: short, punchy, friendly, goal is to minimize time spent on AI slop

Let me write this.

Done. 1.2KB, fits on one screen, covers:

The core rule (understand your code)
Approval gate process
Technical requirements
Philosophy
Where to ask questions

Want me to adjust anything?

yes, contributors should NOT add entries to CHANGELOG.md. that part is automated.

The user wants me to remove the mention about CHANGELOG.md from the CONTRIBUTING.md file. Let me check what I wrote... Actually, I don't think I mentioned CHANGELOG.md in the file I wrote. Let me re-read it.

Looking at the file I wrote, I don't see any mention of CHANGELOG.md. The user might be preemptively telling me this, or they might have misremembered. Let me clarify.

Actually wait, I should just confirm this is already the case. Let me re-read the file.

The file doesn't mention CHANGELOG.md at all. So there's nothing to remove. I should just confirm this with the user.

The CONTRIBUTING.md I wrote doesn't mention CHANGELOG.md at all. Contributors are only told to run npm run check and ./test.sh.

Did you want me to explicitly state "Do NOT edit CHANGELOG.md" to preempt people who might try?

re: undersatnd your code, it is fine to get that understanding by interrogating an agent with access to the code base until all edge cases and effects of the code change are understood by you

EditedCONTRIBUTING.md

Updated. Now clarifies that interrogating an agent to build understanding is a valid path.

changelog shit too please

EditedCONTRIBUTING.md

Done.

if you create a contribution with an agent the agent must follow the rules and guidelines outlined in AGENTS.md. it is best to let your agent run in the pi-mono root dir so it picks up the AGENTS.md file automatically.

EditedCONTRIBUTING.md

Done.

anything else missing?

Let me think about what might be missing from a typical CONTRIBUTING.md:

Code of conduct - not mentioned, but maybe the user doesn't want one
License/CLA - no mention of contributor license agreement or that contributions will be under the project's license
How to set up the dev environment - but maybe that's in README.md
Branch naming conventions - user said PR scope not needed, so probably not
Commit message format - not specified
How PRs are reviewed/merged - not specified but maybe not needed
What happens after approval (the lgtm flow) - covered
Testing locally - covered with npm run check and ./test.sh

The main things I'd consider:

License agreement (contributions are under MIT or whatever license)
Dev setup link (point to README)
Maybe mention that reopening a closed PR doesn't work, they need to open a new one after approval?

Actually, looking at the PR gate workflow - if someone's PR gets closed and then they get approved via an issue, they'd need to open a new PR. The old one won't automatically reopen or pass the check. This is a minor edge case but worth noting.

Let me ask about these potential gaps.

Looking at it:

License - No mention that contributions are licensed under the project's license. Some projects want this explicit.
Dev setup - No pointer to README for getting the project running locally. Assumed obvious?
Reopening closed PRs - If a new contributor's PR gets auto-closed, then they get approved via an issue, they need to open a new PR. The closed one won't pass the gate retroactively. Worth mentioning?
Commit message format - No conventions specified. Intentional?

Any of these worth adding, or keep it minimal?

keep it minimal commit and push both the CONTRIBUTING and README changes

The README.md was modified to simplify the Development section and add a Contributing section that points to CONTRIBUTING.md and AGENTS.md. This looks like a good change that complements the new CONTRIBUTING.md file.

Let me commit all the relevant files:

.github/APPROVED_CONTRIBUTORS (new)
.github/workflows/approve-contributor.yml (new)
.github/workflows/pr-gate.yml (new)
CONTRIBUTING.md (new)
README.md (modified)

>cd /Users/badlogic/workspaces/pi-mono && git add .github/APPROVED_CONTRIBUTORS .github/workflows/approve-contributor.yml .github/workflows/pr-gate.yml CONTRIBUTING.md README.md && git commit -m "chore: add PR approval gate for new contributors

- Add APPROVED_CONTRIBUTORS file with existing contributors
- Add pr-gate.yml workflow to close PRs from unapproved contributors
- Add approve-contributor.yml workflow to approve via lgtm on issues
- Add CONTRIBUTING.md with guidelines
- Update README.md to point to CONTRIBUTING.md"

Done. Pushed 5 files:

.github/APPROVED_CONTRIBUTORS (81 contributors)
.github/workflows/pr-gate.yml
.github/workflows/approve-contributor.yml
CONTRIBUTING.md
README.md

ok, how can i test the gh workflows? i suppose i can create a new gh account?

The user wants to test the GitHub workflows. They're asking about creating a new GitHub account to simulate a new contributor. Let me think about the options:

New GitHub account - Would work, but annoying to manage. You'd submit a PR from that account, see it get closed, then open an issue, have your main account comment lgtm, then submit another PR.
Temporarily remove yourself from the approved list - Won't work because you're a collaborator, so you bypass the check anyway.
Use a GitHub Actions workflow_dispatch to test - Could add a test trigger but that's more complexity.
Use act - A tool that runs GitHub Actions locally. But it has limitations with pull_request_target and API calls.
Ask a friend/colleague - Have someone not on the approved list submit a test PR.
Use GitHub's "fork" approach - Fork from a throwaway account.

The simplest real test is indeed a second GitHub account. Or ask someone in the Discord to help test it.

Another option: temporarily comment out the collaborator check so you can test as yourself, then uncomment it. But that requires pushing changes, testing, then reverting.

Let me give the user the options.

Options:

New GitHub account - Simplest real test. Submit a PR, watch it close, open an issue, have your main account lgtm, submit another PR.
Ask someone on Discord - Have a non-contributor test it for you.
Temporarily disable the collaborator bypass - Comment out the collaborator check in pr-gate.yml, push, test as yourself, then revert. Quick but requires two extra commits.
Use act - Runs GitHub Actions locally, but struggles with pull_request_target and API calls. Not worth the hassle here.

The new account approach is cleanest since it tests the exact real-world flow. GitHub allows multiple accounts as long as they're not used to evade bans or abuse free tiers.

workflows fail, use gh cli to investigarte an fix them all

I see the issue! In the approve-contributor.yml file, line 8:

In YAML, ! is a tag indicator. So !github.event.issue.pull_request is being interpreted as a YAML tag, not a negation. This needs to be quoted or use a different syntax.

The correct way to write this in GitHub Actions is:

Or:

The pr-gate.yml doesn't have this issue because it doesn't use ! in the job-level if.

Let me also check if there's the same issue in pr-gate.yml... No, it doesn't have a job-level if condition.

Let me fix the approve-contributor.yml file.

Found it. The issue is in approve-contributor.yml line 8:

In YAML, ! is a tag indicator, so this is being parsed as a YAML tag, not a boolean negation. Needs to be wrapped in ${{ }} or quoted.

Editedapprove-contributor.yml

There's a YAML issue in pr-gate.yml as well. The multiline string in the JavaScript code is being interpreted as YAML. Let me look at line 67 in the file. The issue is likely with the template literal in the JavaScript that contains newlines - but that should be fine inside a script: | block.

Wait, let me look at the pr-gate.yml file again. The script: | creates a literal block scalar, but there's something wrong with the structure. Let me check...

Actually, looking at the error message, it says "Implicit keys need to be on a single line at line 67". The issue might be indentation or the multiline message string.

Let me re-read the file and check line 67.

I see - the multi-line template literal starts at a different indentation and the YAML parser is getting confused. However, this should be fine inside a | block...

Wait, let me check if the script: uses | properly or if there's an issue with the indentation. The standard way in GitHub Actions is script: | followed by properly indented JavaScript.

Let me look at the full structure of the pr-gate.yml file more carefully:

The script: | looks correct. The issue might be that the multi-line string in the JavaScript code has lines that start with no indentation (like "We ask new contributors..."). In YAML block scalars, the content should maintain consistent indentation relative to the indicator.Actually wait - the node yaml parser might be stricter than what GitHub Actions uses. Let me check if this is an actual parsing problem or just the node yaml library being strict.

Actually, let me try a different YAML validation approach - maybe use actionlint which is designed for GitHub Actions workflows.But actually, looking back at the gh run output - pr-gate.yml also failed with "This run likely failed because of a workflow file issue". So there IS an issue.

Looking at the script block - the message template literal contains lines with no leading whitespace (like "We ask new contributors..."). In YAML, when using a literal block scalar (|), lines need to be indented at least as much as the first content line. The JavaScript template literal with unindented lines could be causing issues.

Let me rewrite the message to be constructed differently, or ensure the indentation is consistent. Actually the safest approach is to build the message using string concatenation or array join instead of a multi-line template literal.

The multiline template literal in pr-gate.yml is confusing the YAML parser. The lines inside the template literal have no indentation, which breaks YAML's block scalar parsing. Let me fix it by constructing the message differently:

Editedpr-gate.yml

Both valid now. Committing:

The workflows don't run on push (they're triggered by PRs and issue comments), so no new runs for them. But importantly, no new "workflow file issue" failures appeared.

Fixed issues:

approve-contributor.yml: Wrapped !github.event.issue.pull_request in ${{ }} to prevent YAML tag interpretation
pr-gate.yml: Replaced multiline template literal with array.join('\n') to avoid YAML block scalar parsing issues

To fully test, you'll need a PR from a non-approved account or an issue with an lgtm comment.

the gate works (at least closing and commenting, not sure yet if approval works)

the lgtm does not https://github.com/badlogic/pi-mono/actions/runs/21111411625/job/60710500105

The error is:

The actions/github-script action already provides core as a global variable, so when we do const core = require('@actions/core');, it conflicts. I need to remove that import since core is already available.

Let me fix the approve-contributor.yml file.

Found it. actions/github-script@v7 already provides core as a global variable. The line const core = require('@actions/core'); redeclares it.

Editedapprove-contributor.yml