diff --git a/self-development/kelos-workers.yaml b/self-development/kelos-workers.yaml
index 3ea9981..7210af1 100644
--- a/self-development/kelos-workers.yaml
+++ b/self-development/kelos-workers.yaml
@@ -97,7 +97,7 @@ spec:
       - 2a. Read ALL review comments and conversation on the PR (gh pr view, gh api for review comments).
         - Also read ALL comments on the linked issue (gh issue view {{.Number}} --comments), not just the PR.
       - 3a. Read the existing diff (git diff main...HEAD) to understand what has already been done. Do NOT start over or rewrite from scratch.
-      - 4a. Make only the incremental changes needed to address review feedback or remaining issues. Preserve existing work.
+      - 4a. Make only the incremental changes needed to address review feedback or remaining issues. Preserve existing work. If the PR adds a feature or API change but lacks e2e tests in `test/e2e/`, add them — reviewers will request them if missing.
       - 5a. Commit and push your changes to origin kelos-task-{{.Number}}.
       - 6a. /review the PR to verify your changes address the feedback. If changes are needed, make them, commit and push, then /review again. Repeat until the review passes.
       - 7a. Update the PR title and description to reflect the final diff. The PR body MUST contain a standard closing keyword reference on its own line (e.g., `Fixes #{{.Number}}` or `Closes #{{.Number}}`). Do not embed the issue number in natural language. Ensure the PR has labels "generated-by-kelos" and "ok-to-test" (use `gh pr edit {{.Number}} --add-label generated-by-kelos --add-label ok-to-test` if missing).
@@ -109,7 +109,7 @@ spec:
         - If previous PRs for this issue were closed, read their reviews to understand why before choosing your approach.
         - Search the codebase for existing constants, types, and patterns before creating new ones. Do not duplicate definitions.
         - Only implement what the issue explicitly asks for. If you discover related improvements, create separate issues for them.
-      - 3b. Create a commit that fixes the issue.
+      - 3b. Create a commit that fixes the issue. For feature or API changes, add e2e tests in `test/e2e/`. E2e tests are critical for feature completeness — reviewers will request them if missing.
       - 4b. Push your branch to origin kelos-task-{{.Number}}.
       - 5b. Create a PR with labels "generated-by-kelos" and "ok-to-test" (use `gh pr create --label generated-by-kelos --label ok-to-test`), then /review it. If changes are needed, make them, commit and push, then /review again. Repeat until the review passes.
       - 6b. Update the PR title and description to reflect the final diff. The PR body MUST contain a standard closing keyword reference on its own line (e.g., `Fixes #{{.Number}}` or `Closes #{{.Number}}`). Do not embed the issue number in natural language.