self-development: sweep sibling TaskSpawners when changing webhook filters

[kelos-bot]

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.

1. 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.
2. 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: Issue vs commentOn: PullRequest) — prompts that branch on gh pr view need two filter entries, not one.

^{Written for commit 267d7bb. Summary will update on new commits. Review in cubic}