self-development: scope kelos-planner, kelos-reviewer, and kelos-api-reviewer with commentOn

Closed
KE
3mo ago
+9-4

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

Adds the commentOn filter field (introduced in #1081) to the three remaining webhook-driven TaskSpawners that previously relied on prompt-side workarounds or no guard at all:

  • kelos-planner.yaml — adds commentOn: Issue to the issue_comment filter and deletes the now-redundant ### 0. Confirm the target is an issue prompt block. /kelos plan typed on a PR is now rejected at the webhook layer instead of spawning an Opus task that bails at step 0.
  • kelos-reviewer.yaml — adds commentOn: PullRequest to the issue_comment filter. /kelos review typed on a plain issue can no longer spawn a task whose prompt unconditionally calls gh pr view and git diff origin/main...HEAD. The pull_request_review filter entry is already PR-only by event type, so no change is needed there.
  • kelos-api-reviewer.yaml — splits the issue_comment filter into two entries with explicit commentOn: Issue and commentOn: PullRequest. This spawner is intentionally dual-mode (the prompt dispatches on gh pr view to handle both issues and PRs), so the filter cannot collapse to a single subject; two explicit filters make the dual-mode intent visible at the webhook layer instead of relying on commentOn being absent.

kelos-squash-commits.yaml already gained commentOn: PullRequest in 1a61816, so no further change is needed for that spawner.

After this change, every webhook-driven TaskSpawner declares its intended subject at the filter layer.

Which issue(s) this PR is related to:

Fixes #1089

Special notes for your reviewer:

  • Supersedes #1060 (the older proposal to add a step-0 prompt guard plus a safer branch fallback for kelos-reviewer); #1060 can be closed once this lands.
  • The kelos-reviewer branch template already uses the safe {{with index . "Branch"}}{{.}}{{else}}main{{end}} fallback, so no change is needed there.
  • For kelos-api-reviewer, the prompt-side gh pr view dispatch is retained because both subjects are accepted on the same event/bodyPattern and the prompt still needs to know which subject it is handling.

Does this PR introduce a user-facing change?

NONE