A label is a second way to ask either bot for a review

[henokteixeira]

The fact, measured

Both reusable workflows guard their only job with:

if: >-
  github.event.action == 'review_requested' &&
  github.event.requested_reviewer.login == inputs.reviewer_login &&
  ...

On shemaobt/facilitator-desk that condition can never be met. Every pull request there is opened by @henokteixeira, and GitHub refuses a review request aimed at a pull request's own author — 422 Review cannot be requested from pull request author. So Henokinho has never reviewed anything on that repository.

The runs are not missing, which is the part worth knowing: #66, #67, #68 and #69 each have a Henokinho Review run, fired by the review request aimed at @joaocarvoli, that finishes skipped in one or two seconds on the login test. From the outside it looks configured and working.

The change

A label_name input, and a second arm on the job's if:

if: >-
  (
  (github.event.action == 'review_requested' && github.event.requested_reviewer.login == inputs.reviewer_login)
  ||
  (github.event.action == 'labeled' && github.event.label.name == inputs.label_name)
  )
  && github.event.pull_request.draft == false
  && !endsWith(github.event.pull_request.user.login, '[bot]')

Additive, and the existing way in is untouched. The review request is still the org's own shape and is what works the day a pull request comes from somebody else; the login test is scoped to its own arm because a labeled event carries no requested_reviewer at all. Draft and bot-authored pull requests are excluded on either way in, as before.

No caller changes behaviour by this merge. A caller reaches the label arm only by putting labeled into its own on: pull_request: types:. Every caller that has not still dispatches on review_requested alone, whatever label_name defaults to. The default is the bot's own name rather than an empty string, so that a caller that does opt in and forgets to name a label does not get a run that starts, skips and looks identical to the guard working.

Joãozinho takes the same change. The two files are deliberately one shape copied rather than a shared abstraction, and fixing one of them is exactly how that copy starts to diverge. I read both before touching either: they differ in bot_login / verdict_mode / max_turns, none of which touches this.

Four sentences that would have gone stale

Each said the bot runs only on a review request, and each is rewritten here rather than left behind the diff:

• the if comment in both workflows — including the note that a team request leaves requested_reviewer null, which is still true and is now scoped to the arm it belongs to;
• the prompt in both workflows, which told the bot why it was running;
• README.md, which is the one-paragraph description of how either bot fires;
• henokinho/review-style.md, which is binding spec the bot reads.

The YAML detail that nearly shipped wrong

The readable version of that if — inner clauses indented to show the nesting — parses, lints clean, and is not one expression. >- folds only across lines at the same indentation; a more-indented line keeps its newline, so what would reach GitHub is a multi-line string. Caught by parsing the file and counting lines in the result, not by reading it. Every line of the expression now sits at one indentation, and the reason is written beside it.

What holds this

• actionlint clean on henokinho-review.yml. joaozinho-review.yml reports one SC2129 style warning that is pre-existing — same single finding on main, only the line number moves — in a run: block this PR does not touch.
• The folded if was read back out of the parsed YAML and is a single line in both files.
• henokinho/tests/test-check-bot-login.sh — 1 behaviour, 0 failed. henokinho/tests/test-collect-prior-passes.sh — 7 behaviours, 0 failed.
• Nothing here proves a run. The caller side is shemaobt/facilitator-desk#69, whose trigger already carries labeled; that pull request is where labelling produces a real review, and it cannot until this merges.

[linear-code]

ENG-613