self-development: sweep sibling TaskSpawners when changing webhook filters
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Adds two recurring TaskSpawner conventions to self-development/agentconfig.yaml and self-development/kelos-workers.yaml (the two files that carry the inline `agentsMD` rule list seen by the dev/worker agents). Both rules slot under the existing TaskSpawner conventions block.
- Sweep sibling spawners when changing webhook filters / triggers / labels / shared prompt scaffolding. A filter tightening applied to one `self-development/*.yaml` (e.g. adding `commentOn`, narrowing `author`, scoping `bodyPattern`) almost always applies to every other spawner that listens to the same event family.
- Verify dual-mode by reading the prompt before scoping a spawner to `commentOn: Issue` or `commentOn: PullRequest`. A prompt that dispatches on `gh pr view` (or otherwise branches on Issue-vs-PR) needs two filter entries, not one.
Motivating review feedback
Both rules come from PR #1205 (`self-development: scope kelos-planner, kelos-reviewer, and kelos-api-reviewer with commentOn`), where the agent's first iteration only updated two of three sibling spawners and used a single scoped filter on a dual-mode spawner:
- @gjkim42 (review 2026-05-23): "Let'a apply this to kelos api reviewer as well /kelos pick-up" — the first iteration added `commentOn` to `kelos-planner.yaml` and `kelos-reviewer.yaml` but missed `kelos-api-reviewer.yaml`. Rule 1 codifies the "check every sibling" step so this doesn't recur.
- @gjkim42 (review 2026-05-24): "Does kelos api reviewer work for an issue as well? (Based on the prompt?) /kelos pick-up then squash commits" — the agent then had to re-read `kelos-api-reviewer.yaml`'s prompt to discover it dispatches on `gh pr view` and supports both Issue and PR subjects, which is why the final filter ended up with two `issue_comment` entries (one per `commentOn` value). Rule 2 makes "read the prompt first" the default.
The convention block in the two YAMLs is the right home: it already lists TaskSpawner-specific guidance (`{{.Branch}}` handling, `issue_comment` dual-fire, no manual PR checkout) and is the rule set both `kelos-dev-agent` (the self-development agent) and `kelos-workers-agent` actually consume.
Scope notes
- No changes to `AGENTS.md` / `CLAUDE.md`: these are project-wide rules for the main repo, not self-development guidance.
- No changes to other `self-development/*.yaml` spawners: they pull conventions via the shared blocks; only the two files that inline the convention list need editing.
- No code or behavior change — text-only update to two YAML files.
Which issue(s) this PR is related to:
N/A
Special notes for your reviewer:
N/A
Does this PR introduce a user-facing change?
```release-note
NONE
```
Summary by cubic
Added two new recurring TaskSpawner conventions to self-development/agentconfig.yaml and self-development/kelos-workers.yaml based on feedback from PR #1205, where a webhook filter change missed sibling spawners and incorrectly used a single scoped filter on a dual-mode prompt.
- New Features
- Added rule to sweep sibling spawners when changing webhook filters, triggers, labels, or shared prompt scaffolding — before opening a PR, grep the event name across
self-development/and update every match or document intentional exclusions. - Added rule to verify dual-mode by reading the prompt before scoping a spawner to a single subject (
commentOn: IssuevscommentOn: PullRequest) — prompts that branch ongh pr viewneed two filter entries, not one.
- Added rule to sweep sibling spawners when changing webhook filters, triggers, labels, or shared prompt scaffolding — before opening a PR, grep the event name across