Label linked issues when a PR is submitted or approved

[codente]

Ports bb-plugin's issue-labeling automation into this repo. This is the assistant repo's first GitHub Actions workflow — there was no .github/ directory before.

What it does

On a non-draft PR, it parses the PR body for fixes/closes/resolves #N and labels each linked open issue:

Event	Label applied
pull_request (opened, synchronize, reopened, edited)	status: has pull request
pull_request_review submitted and approved	status: approved

Both labels were created in this repo to match bb-plugin's colors and descriptions.

Combined rather than two files

bb-plugin keeps these as separate workflows (pr-submitted-add-label.yml and pr-approved-add-label.yml), but their issue-parsing and labeling bodies are identical — the only real difference is which label gets applied. So this is one job with both triggers, picking the label from context.eventName.

Two incidental improvements fall out of the merge:

• The approval path gets the open/unlocked issue guard that bb-plugin's submitted workflow has but its approval workflow doesn't, so it no longer tries to label closed or locked issues.
• bb-plugin's approval check ran as a shell step writing to $GITHUB_ENV for a later if: to read. That collapses into the job-level if:, dropping a step and the env round-trip.

Deliberate differences from bb-plugin

• runs-on: ubuntu-latest instead of [self-hosted, general]. This repo is public and has no self-hosted runners registered to it. Pointing a public repo's pull_request workflow at a self-hosted runner would let any fork PR execute on our hardware, and this job is a single GitHub API call with no build step — there's nothing to gain from the self-hosted lane.
• The status: ready for human review removal step is omitted. bb-plugin's approval workflow drops that label after a human approves, but it's set by bb-plugin's AI-review workflow, which this repo doesn't have. The step would be permanently dead here. Worth adding if that workflow ever comes over.
• actions/github-script@v6 is kept as-is to match bb-plugin, though it runs on the deprecated Node 16 and will need a v7 bump at some point.

Testing

A workflow can't be exercised before it's on GitHub, so this PR is its own test: it's a same-repo PR, so the pull_request half runs against this branch on open. It has no fixes #N in the body, so the expected result is a clean run logging No linked issues found in PR body. Approving it should then fire the pull_request_review half to the same no-op.

One thing I couldn't determine ahead of time: fork PRs get a read-only GITHUB_TOKEN on the pull_request event, so labeling silently no-ops for them (the script catches and logs it). Whether the same restriction applies to pull_request_review is unclear to me — the triggering actor there is a reviewer on the base repo, not the fork author. Observable on the first fork PR approval. Org-member branch PRs are unaffected either way.

🤖 Generated with Claude Code