Skip to content

Prompt Tuning: /review instructions in workers and pr-responder prompts have no effect and should be replaced with self-reviewΒ #647

@kelos-bot

Description

@kelos-bot

πŸ€– Kelos Self-Update Agent @gjkim42

Area: Prompt Tuning

Summary

The kelos-workers.yaml and kelos-pr-responder.yaml prompts both instruct agents to /review their PRs. This command has no effect β€” agents post /review as PR comments expecting an automated review, but nothing processes this comment. The maintainer explicitly called this out in PR #586: "commenting '/review' doesn't work at all. you have to review your code yourself."

Two PRs attempted to fix this (#599 for workers, #638 for both) but neither has been merged and no issue tracks the underlying problem.

Findings

1. /review is a no-op in all three prompt locations

kelos-workers.yaml, step 6a (existing PR path, line 102):

- 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.

kelos-workers.yaml, step 5b (new PR path, line 114):

- 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.

kelos-pr-responder.yaml, step 6 (line 86):

- 6. /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.

In all three cases, agents interpret this as posting /review as a PR comment (as observed in PR #586 where the agent's first comment was literally /review). This creates noise on PRs and wastes an agent action that accomplishes nothing.

2. Evidence from actual agent behavior

PR #586 β€” The kelos-bot agent posted /review as its first comment on the PR. Maintainer @gjkim42 responded: "commenting '/review' doesn't work at all. you have to review your code yourself."

PR #599 (open) β€” Attempted to fix this in kelos-workers.yaml only, replacing /review with self-review via git diff origin/main...HEAD. Not yet merged.

PR #638 (closed without merge) β€” Attempted to fix this in both kelos-workers.yaml and kelos-pr-responder.yaml. Closed on 2026-03-12.

PR #632 (closed without merge) β€” Attempted to fix this in kelos-pr-responder.yaml only. Cubic-dev-ai flagged a P2 issue: the self-review diff command always used origin/main but step 0 conditionally rebases on upstream/main, meaning the diff base should be consistent with the rebase target.

3. The upstream/main consistency problem in pr-responder

The pr-responder prompt's step 0 conditionally rebases on upstream/main when an upstream remote exists:

if git remote get-url upstream >/dev/null 2>&1; then
  git fetch upstream main
  git checkout {{.Branch}}
  git rebase upstream/main
else
  git fetch origin main
  git checkout {{.Branch}}
  git rebase origin/main
fi

Any self-review step that replaces /review must use the same conditional base β€” upstream/main when the upstream remote exists, origin/main otherwise. PR #632 was flagged by cubic for getting this wrong (hardcoding origin/main).

Proposed Fix

For kelos-workers.yaml (steps 6a and 5b)

Replace /review with self-review using git diff:

Step 6a (existing PR path):

- 6a. Self-review your changes by running `git diff origin/main...HEAD` and reading the full diff. Verify that:
  - Only files relevant to the issue are modified
  - No debug code, TODOs, or unintended changes are included
  - Tests cover the changes where appropriate
  If you find issues, fix them, commit and push, then self-review again.

Step 5b (new PR path β€” after PR creation):

- 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`). Self-review by running `git diff origin/main...HEAD` and reading the full diff. Verify only task-relevant changes are included. If you find issues, fix them, commit and push.

For kelos-pr-responder.yaml (step 6)

Replace /review with self-review that respects the upstream/origin conditional:

- 6. Self-review your changes. Determine the base branch:

if git remote get-url upstream >/dev/null 2>&1; then
BASE=upstream/main
else
BASE=origin/main
fi
git diff $BASE...HEAD

Read the full diff and verify that:
- Only files relevant to the review feedback are modified
- No debug code, TODOs, or unintended changes are included
- Tests cover the changes where appropriate
Do NOT post "/review" as a PR comment β€” it does not trigger anything.
If you find issues, fix them, commit and push, then self-review again.

Relationship to existing issues and PRs

# Type Title Overlap
#599 PR (open) Add self-review and commit hygiene to workers prompt Covers workers only, not pr-responder. Does not address the upstream/main consistency issue.
#638 PR (closed) Replace /review with self-review in agent prompts Attempted both files but closed without merge.
#632 PR (closed) Replace /review with self-review in kelos-pr-responder PR-responder only. Flagged by cubic for hardcoding origin/main.
#592 Issue (open) kelos-workers step 7a uses issue number in gh pr edit Different problem β€” template variable misuse.
#566 Issue (open) PR-creating agents lack local verification step Different problem β€” missing make verify/make test.

None of the existing open issues tracks the /review removal itself. The three PRs that attempted fixes have either stalled or been closed, and two of them had the upstream/main consistency bug. This issue provides a corrected proposal that handles both files with the right diff base logic.

Impact

  • Eliminates noise on PRs β€” agents will stop posting no-op /review comments
  • Adds meaningful self-review β€” agents will actually read their own diff before requesting human review
  • Handles fork workflows correctly β€” pr-responder self-review uses the same base as the rebase step
  • Prompt-only changes β€” no code or CRD modifications needed

/kind cleanup

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions