self-development: cover all agent runtimes in per-runtime docs

AGENTS.md

@@ -19,6 +19,7 @@
 - **Avoid vacuous substring assertions in printer/formatter tests.** When asserting a `label: value` line is emitted, match against the full `"label: value"` string (or a regex), not the bare value — bare values often collide with the resource's `Name` or other surrounding context in the fixture and pass even when the line is missing.
 - **Keep CRD enum docstrings consistent with the `+kubebuilder:validation:Enum` marker.** If the godoc says "empty matches both", either include `""` in the enum list so `field: ""` is accepted, or rephrase to "Omit to match both" so no one writes the explicit empty form. A docstring that invites a value the API server then rejects is a worse contract than either alternative.
 - **Qualify cross-CRD field references with the owning kind in docs.** In a CRD reference section, write `Task.spec.podOverrides.env` rather than bare `podOverrides.env` when describing a field that lives on a sibling CRD. A reader of one CRD's reference page should be able to locate the cited field without already knowing the layout of the others.
+- **Cover every supported agent runtime in docs that describe per-runtime behavior.** Kelos supports five agent runtimes (`claude-code`, `gemini`, `codex`, `opencode`, `cursor`) and they differ on instruction-file paths, env var names, and CLI flags accepted by the entrypoint. When a doc/README/example describes such per-runtime behavior — e.g., where `spec.agentsMD` is written, which file the agent reads on startup, which API-key variable the entrypoint honors — enumerate the behavior per runtime (one row per `claude-code`/`gemini`/`codex`/`opencode`/`cursor`) or explicitly say "Example uses Claude Code; see `docs/agent-image-interface.md` for the path your agent uses." Writing only the Claude Code path (e.g., `~/.claude/CLAUDE.md`) silently misleads readers running the other four runtimes — they will look for a file the entrypoint never creates. This is the docs analogue of "Parameterize e2e tests across all supported agent types."
 
 ## Key Makefile Targets
 - `make verify` — run all verification checks (lint, fmt, vet, etc.).

self-development/agentconfig.yaml

@@ -43,6 +43,7 @@ spec:
     - Avoid vacuous substring assertions in printer/formatter tests: when asserting a `label: value` line is emitted, match the full `"label: value"` string (or a regex), not the bare value — bare values frequently collide with the fixture's `Name` or surrounding context and pass even when the line is missing.
     - Keep CRD enum docstrings consistent with the `+kubebuilder:validation:Enum` marker: if the godoc says "empty matches both", either include `""` in the enum list so `field: ""` is accepted, or rephrase to "Omit to match both" so no one writes the explicit empty form. A docstring that invites a value the API server then rejects is a worse contract than either alternative.
     - Qualify cross-CRD field references with the owning kind in docs: in a CRD reference section, write `Task.spec.podOverrides.env` rather than bare `podOverrides.env` when describing a field that lives on a sibling CRD. A reader of one CRD's reference page should be able to locate the cited field without already knowing the layout of the others.
+    - Cover every supported agent runtime in docs that describe per-runtime behavior: Kelos supports five agent runtimes (`claude-code`, `gemini`, `codex`, `opencode`, `cursor`) and they differ on instruction-file paths, env var names, and CLI flags accepted by the entrypoint. When a doc/README/example describes such per-runtime behavior — e.g., where `spec.agentsMD` is written, which file the agent reads on startup, which API-key variable the entrypoint honors — enumerate the behavior per runtime (one row per `claude-code`/`gemini`/`codex`/`opencode`/`cursor`) or explicitly say "Example uses Claude Code; see `docs/agent-image-interface.md` for the path your agent uses." Writing only the Claude Code path (e.g., `~/.claude/CLAUDE.md`) silently misleads readers running the other four runtimes — they will look for a file the entrypoint never creates. This is the docs analogue of "Parameterize e2e tests across all supported agent types."
     - PRs that only modify files under `self-development/` are internal agent improvements: use `/kind cleanup` and write "NONE" in the `release-note` block, even when the change fixes a bug or adds a feature in agent behavior. Classify by file location, not by problem nature.
     - TaskSpawner conventions (for `self-development/` YAML files):
       - Prefer webhook-based triggers (`githubWebhook`) over poll-based (`githubPullRequests`) for real-time event-driven tasks

self-development/kelos-workers.yaml

@@ -42,6 +42,7 @@ spec:
     - Avoid vacuous substring assertions in printer/formatter tests: when asserting a `label: value` line is emitted, match the full `"label: value"` string (or a regex), not the bare value — bare values frequently collide with the fixture's `Name` or surrounding context and pass even when the line is missing.
     - Keep CRD enum docstrings consistent with the `+kubebuilder:validation:Enum` marker: if the godoc says "empty matches both", either include `""` in the enum list so `field: ""` is accepted, or rephrase to "Omit to match both" so no one writes the explicit empty form. A docstring that invites a value the API server then rejects is a worse contract than either alternative.
     - Qualify cross-CRD field references with the owning kind in docs: in a CRD reference section, write `Task.spec.podOverrides.env` rather than bare `podOverrides.env` when describing a field that lives on a sibling CRD. A reader of one CRD's reference page should be able to locate the cited field without already knowing the layout of the others.
+    - Cover every supported agent runtime in docs that describe per-runtime behavior: Kelos supports five agent runtimes (`claude-code`, `gemini`, `codex`, `opencode`, `cursor`) and they differ on instruction-file paths, env var names, and CLI flags accepted by the entrypoint. When a doc/README/example describes such per-runtime behavior — e.g., where `spec.agentsMD` is written, which file the agent reads on startup, which API-key variable the entrypoint honors — enumerate the behavior per runtime (one row per `claude-code`/`gemini`/`codex`/`opencode`/`cursor`) or explicitly say "Example uses Claude Code; see `docs/agent-image-interface.md` for the path your agent uses." Writing only the Claude Code path (e.g., `~/.claude/CLAUDE.md`) silently misleads readers running the other four runtimes — they will look for a file the entrypoint never creates. This is the docs analogue of "Parameterize e2e tests across all supported agent types."
     - PRs that only modify files under `self-development/` are internal agent improvements: use `/kind cleanup` and write "NONE" in the `release-note` block, even when the change fixes a bug or adds a feature in agent behavior. Classify by file location, not by problem nature.
     - TaskSpawner conventions (for `self-development/` YAML files):
       - Prefer webhook-based triggers (`githubWebhook`) over poll-based (`githubPullRequests`) for real-time event-driven tasks