Configuration Alignment: kelos-planner, kelos-reviewer, kelos-squash-commits filters miss commentOn — replace prompt-side PR-vs-issue workarounds with the new filter

🤖 Kelos Self-Update Agent @gjkim42

Area: Configuration Alignment

Summary

PR #1081 (merged 2026-05-01) added a first-class commentOn field to GitHubWebhookFilter so spawner authors can scope issue_comment events to plain issues (Issue) or pull requests (PullRequest). Two webhook-driven TaskSpawners — kelos-workers and kelos-pr-responder — already adopted it. Three more (kelos-planner, kelos-reviewer, kelos-squash-commits) still rely on prompt-side workarounds or have no guard at all. This is the follow-up cleanup explicitly deferred by #1081's PR description ("Spawner-prompt cleanups […] are intentionally out of scope per the issue and will follow as separate PRs.").

Findings

1. kelos-planner.yaml — filter accepts both, prompt has a stale step-0 guard

kelos-planner.yaml lines 33–43 lack commentOn on either filter:

- event: issue_comment
  action: created
  bodyContains: /kelos plan
  state: open
  author: gjkim42
- event: issue_comment
  action: created
  bodyContains: /kelos plan
  state: open
  author: kelos-bot[bot]

kelos-planner.yaml lines 86–88 then bail at runtime:

### 0. Confirm the target is an issue
If `gh pr view {{.Number}}` succeeds, this comment was posted on a pull request.
Exit without posting anything in that case.

Every PR comment containing /kelos plan (e.g., a maintainer asking the planner to plan against a PR's open question) spawns a full Opus task that consumes credentials only to exit at step 0. The README documents this spawner as "Webhook: issue comment /kelos plan" — the implementation should match.

Proposed fix:

• Add commentOn: Issue to both filter entries.
• Delete the ### 0. Confirm the target is an issue block (lines 84–88) — the filter now enforces it.

2. kelos-reviewer.yaml — filter accepts both, prompt has no guard (supersedes #1060)

kelos-reviewer.yaml lines 47–56 (the issue_comment filter entries) lack commentOn:

- event: issue_comment
  action: created
  bodyContains: /kelos review
  state: open
  author: gjkim42
- event: issue_comment
  action: created
  bodyContains: /kelos review
  state: open
  author: kelos-bot[bot]

The prompt then unconditionally assumes a PR (lines 92–104, 118, 125, 227): gh pr view, git diff origin/main...HEAD, gh pr review. If /kelos review is posted on a plain issue, the agent burns a full Opus task that can only fail or hallucinate a "PR review" comment. branch: "{{.Branch}}" (line 89) also resolves to empty for plain-issue comments per the README template-variable table.

This was previously tracked in #1060, which proposed a step-0 prompt guard plus a safer branch fallback. The new commentOn filter is a strictly better solution — it stops the spawn at the webhook layer instead of at runtime, mirroring the pattern already established by kelos-workers and kelos-pr-responder.

Proposed fix:

• Add commentOn: PullRequest to both issue_comment filter entries.
• Once that is in place, the unsafe branch: "{{.Branch}}" template and the missing prompt guard from #1060 become moot — the filter guarantees .Branch is a PR head branch. Close #1060 as superseded.

3. kelos-squash-commits.yaml — filter accepts both, prompt is PR-only

kelos-squash-commits.yaml lines 13–17 lack commentOn:

- event: issue_comment
  action: created
  bodyContains: /kelos squash-commits
  state: open
  author: gjkim42

The prompt is entirely PR-focused (git rebase origin/main, git push --force-with-lease, gh pr view, gh pr edit, gh pr ... comment). A /kelos squash-commits posted on a plain issue spawns a Sonnet task that fails at step 4 (gh pr view {{.Number}} --json body) and may post a confusing comment.

Proposed fix:

• Add commentOn: PullRequest to the issue_comment filter entry. The pull_request_review entry is already PR-only by event type.

Why this is consistent

After this change, every webhook-driven TaskSpawner whose intent is single-subject uses the filter to enforce that intent, and prompt-side gh pr view guards exist only in kelos-api-reviewer where they reflect deliberate dual-mode dispatch.

Impact

• Wasted spawns avoided. Today every misrouted /kelos plan, /kelos review, or /kelos squash-commits comment burns an Opus or Sonnet task to bail at step 0. Filter rejection is free.
• Removes the last unguarded gap flagged by #1060.
• Removes 3 lines of redundant prompt logic from kelos-planner (its step 0 guard).
• Single, testable change per TaskSpawner — all three are one-line filter additions plus, for kelos-planner, deleting one stale step-0 block.

Not covered by existing issues

• #979 — covers other filter asymmetries (kelos-bot[bot] author missing on squash-commits; pr-responder review filter missing author restriction; identity collisions on shared kelos-dev-agent). Does not mention commentOn or PR-vs-issue scoping.
• #1060 — covers kelos-reviewer only, with a now-outdated proposed fix (step-0 prompt guard + safer branch fallback). This issue supersedes #1060's proposed approach with the cleaner filter-layer fix and broadens the scope to two more spawners with the same root cause.
• #856 (closed) — kelos-triage label set; unrelated.
• #1081 (merged) — added the commentOn field; explicitly deferred this cleanup.

Start with kelos-planner.yaml, kelos-reviewer.yaml, and kelos-squash-commits.yaml, comparing their issue_comment filters with the commentOn usage already adopted by kelos-workers and kelos-pr-responder. Add the specified Issue or PullRequest scopes, remove the planner's obsolete step-0 guard, and verify that each spawner's filter matches its documented intent; #1060 should then be superseded.