diff --git a/AGENTS.md b/AGENTS.md
index 3c7d869a..1e03a99b 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -7,6 +7,8 @@
 - **Better tests.** Always try to add or improve tests(including integration, e2e) when modifying code.
 - **Logging conventions.** Start log messages with capital letters and do not end with punctuation.
 - **Commit messages.** Do not include PR links in commit messages.
+- **API deprecation notices.** Do not hard-code future API version names (e.g., "will be removed in v1alpha2") — the next version is not yet determined.
+- **New API fields/features.** When adding new API fields or features, always update `self-development/` configs and `examples/` to use the newly added fields.
 
 ## Key Makefile Targets
 - `make verify` — run all verification checks (lint, fmt, vet, etc.).
@@ -20,7 +22,7 @@
 ## Pull Requests
 - **Always follow `.github/PULL_REQUEST_TEMPLATE.md`** when creating PRs.
 - Fill in every section of the template. Do not remove or skip sections — use "N/A" or "NONE" where appropriate.
-- Choose exactly one `/kind` label from: `bug`, `cleanup`, `docs`, `feature`.
+- Choose exactly one `/kind` label from: `bug`, `cleanup`, `docs`, `feature`. The `/kind <label>` line in the PR body automatically applies the label — do not pass redundant `--label kind/...` flags to `gh pr create`.
 - If there is no associated issue, write "N/A" under the issue section.
 - If the PR does not introduce a user-facing change, write "NONE" in the `release-note` block.
 - If the PR introduces a new API field, CRD change, or user-facing feature, write a meaningful release note describing the change — do not write "NONE".
diff --git a/self-development/agentconfig.yaml b/self-development/agentconfig.yaml
index 657975a3..a5dd86e1 100644
--- a/self-development/agentconfig.yaml
+++ b/self-development/agentconfig.yaml
@@ -30,3 +30,5 @@ spec:
     - Logging conventions: start log messages with capital letters and do not end with punctuation
     - Commit messages: do not include PR links in commit messages
     - When making structural changes (adding new files, configs, or components), update related documentation (especially README files) to stay in sync
+    - When adding new API fields or features, always update `self-development/` configs and `examples/` to use the newly added fields
+    - Do not hard-code future API version names in deprecation notices — the next version is not yet determined
diff --git a/self-development/kelos-image-update.yaml b/self-development/kelos-image-update.yaml
index 34e33039..781fc03d 100644
--- a/self-development/kelos-image-update.yaml
+++ b/self-development/kelos-image-update.yaml
@@ -116,7 +116,7 @@ spec:
             gh pr create \
               --title "Update <agent-name> image to <latest-version>" \
               --body-file /tmp/pr-body.md \
-              --label generated-by-kelos --label ok-to-test --label kind/feature
+              --label generated-by-kelos --label ok-to-test
             ```
             The PR body (`/tmp/pr-body.md`) MUST follow `.github/PULL_REQUEST_TEMPLATE.md`:
             - Start with `/kind feature` on its own line
diff --git a/self-development/kelos-workers.yaml b/self-development/kelos-workers.yaml
index 6f5f16f9..ba4ef5a4 100644
--- a/self-development/kelos-workers.yaml
+++ b/self-development/kelos-workers.yaml
@@ -29,6 +29,8 @@ spec:
     - Always try to add or improve tests when modifying code
     - Logging conventions: start log messages with capital letters and do not end with punctuation
     - Commit messages: do not include PR links in commit messages
+    - When adding new API fields or features, always update `self-development/` configs and `examples/` to use the newly added fields
+    - Do not hard-code future API version names in deprecation notices — the next version is not yet determined
 ---
 apiVersion: kelos.dev/v1alpha1
 kind: TaskSpawner