Skip to content

Add pre-push verification, diff checks, and commit squashing conventions #619

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kelos-bot wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add pre-push verification, diff checks, and commit squashing conventions #619

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,9 @@
- **Keep changes minimal.** Do not refactor, reorganize, or 'improve' code beyond what was explicitly requested.
- **For CI/release workflows**, always use existing Makefile targets rather than reimplementing build logic in YAML.
- **Better tests.** Always try to add or improve tests(including integration, e2e) when modifying code.
- **Run `make verify` before pushing.** Always run `make verify` locally to catch lint, fmt, and vet issues before pushing changes.
- **Verify your diff.** Before pushing, run `git diff origin/main --stat` to confirm only files relevant to your task are modified. Revert any unrelated changes.
- **Squash commits.** Squash your commits into a single clean commit before the final push.
- **Logging conventions.** Start log messages with capital letters and do not end with punctuation.
- **Commit messages.** Do not include PR links in commit messages.

Expand Down
3 changes: 3 additions & 0 deletions self-development/agentconfig.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,5 +27,8 @@ spec:
- `make test-integration` — run integration tests
- `make build` — build binary
- Always try to add or improve tests when modifying code
- Run `make verify` before pushing to catch lint, fmt, and vet issues locally
- Before pushing, run `git diff origin/main --stat` to confirm only relevant files are modified — revert any unrelated changes
- Squash commits into a single clean commit before the final push
- Logging conventions: start log messages with capital letters and do not end with punctuation
- Commit messages: do not include PR links in commit messages
11 changes: 7 additions & 4 deletions self-development/kelos-pr-responder.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -81,10 +81,13 @@ spec:
- 2. Read ALL comments on the linked issue referenced by the PR body. First determine the linked issue number from the PR body, then run `gh issue view <linked-issue-number> --comments`. If `KELOS_UPSTREAM_REPO` is set, use `--repo "$KELOS_UPSTREAM_REPO"`.
- 3. Read the existing diff (git diff main...HEAD) to understand what has already been done. Do NOT start over or rewrite from scratch.
- 4. Make only the incremental changes needed to address review feedback or remaining issues. Preserve existing work.
- 5. Commit and push your changes to origin {{.Branch}}.
- 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.
- 7. 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 #123` or `Closes #123`). 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). If `KELOS_UPSTREAM_REPO` is set, include `--repo "$KELOS_UPSTREAM_REPO"`.
- 8. Make sure the PR passes all CI tests.
- 5. Before pushing, verify your changes are clean:
- Run `make verify` to catch lint, fmt, and vet issues locally.
- Run `git diff origin/main --stat` (or `git diff upstream/main --stat` if upstream is set) to confirm only files relevant to the task are modified. Revert any unrelated changes.
- 6. Squash your commits into a single clean commit, then push to origin {{.Branch}}.
Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai bot Mar 9, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: After squashing, a regular git push will be rejected because the rewritten history diverges from the remote. Specify --force-with-lease to make this step actionable (it's also safer than --force since it aborts if someone else pushed in the meantime).

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At self-development/kelos-pr-responder.yaml, line 87:

<comment>After squashing, a regular `git push` will be rejected because the rewritten history diverges from the remote. Specify `--force-with-lease` to make this step actionable (it's also safer than `--force` since it aborts if someone else pushed in the meantime).</comment>

<file context>
@@ -81,10 +81,13 @@ spec:
+      - 5. Before pushing, verify your changes are clean:
+        - Run `make verify` to catch lint, fmt, and vet issues locally.
+        - Run `git diff origin/main --stat` (or `git diff upstream/main --stat` if upstream is set) to confirm only files relevant to the task are modified. Revert any unrelated changes.
+      - 6. Squash your commits into a single clean commit, then push to origin {{.Branch}}.
+      - 7. /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.
+      - 8. 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 #123` or `Closes #123`). 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). If `KELOS_UPSTREAM_REPO` is set, include `--repo "$KELOS_UPSTREAM_REPO"`.
</file context>
Suggested change
- 6. Squash your commits into a single clean commit, then push to origin {{.Branch}}.
- 6. Squash your commits into a single clean commit, then force-push (`git push --force-with-lease`) to origin {{.Branch}}.
Fix with Cubic

- 7. /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.
- 8. 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 #123` or `Closes #123`). 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). If `KELOS_UPSTREAM_REPO` is set, include `--repo "$KELOS_UPSTREAM_REPO"`.
- 9. Make sure the PR passes all CI tests.

Post-checklist:
- If the PR is ready for human review, you need more information, or you cannot make progress, post a PR comment whose first line is `/kelos needs-input` and explain why below it. Maintainers can resume the PR later with `/kelos pick-up`.
Expand Down
22 changes: 14 additions & 8 deletions self-development/kelos-workers.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -98,10 +98,13 @@ spec:
- 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.
- 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).
- 8a. Make sure the PR passes all CI tests.
- 5a. Before pushing, verify your changes are clean:
- Run `make verify` to catch lint, fmt, and vet issues locally.
- Run `git diff origin/main --stat` to confirm only files relevant to the task are modified. Revert any unrelated changes.
- 6a. Squash your commits into a single clean commit, then push to origin kelos-task-{{.Number}}.
- 7a. /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.
Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai bot Mar 9, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: The self-review loop in step 7a adds commits (make them, commit and push) without re-squashing or re-running verification. After a couple of review iterations, the branch will have multiple commits again — the same problem this PR aims to fix. Consider changing the loop to squash before each push, e.g., "make them, squash into a single commit, run make verify, and push."

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At self-development/kelos-workers.yaml, line 105:

<comment>The self-review loop in step 7a adds commits (`make them, commit and push`) without re-squashing or re-running verification. After a couple of review iterations, the branch will have multiple commits again — the same problem this PR aims to fix. Consider changing the loop to squash before each push, e.g., "make them, squash into a single commit, run `make verify`, and push."</comment>

<file context>
@@ -98,10 +98,13 @@ spec:
+        - Run `make verify` to catch lint, fmt, and vet issues locally.
+        - Run `git diff origin/main --stat` to confirm only files relevant to the task are modified. Revert any unrelated changes.
+      - 6a. Squash your commits into a single clean commit, then push to origin kelos-task-{{.Number}}.
+      - 7a. /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.
+      - 8a. 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).
+      - 9a. Make sure the PR passes all CI tests.
</file context>
Suggested change
- 7a. /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. /review the PR to verify your changes address the feedback. If changes are needed, make them, run `make verify`, squash into a single commit, and push, then /review again. Repeat until the review passes.
Fix with Cubic

- 8a. 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).
- 9a. Make sure the PR passes all CI tests.

If no PR exists:
- 2b. Investigate the issue #{{.Number}}.
Expand All @@ -110,10 +113,13 @@ spec:
- 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.
- 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.
- 7b. Make sure the PR passes all CI tests.
- 4b. Before pushing, verify your changes are clean:
- Run `make verify` to catch lint, fmt, and vet issues locally.
- Run `git diff origin/main --stat` to confirm only files relevant to the task are modified. Revert any unrelated changes.
- 5b. Squash your commits into a single clean commit, then push your branch to origin kelos-task-{{.Number}}.
- 6b. 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.
- 7b. 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.
- 8b. Make sure the PR passes all CI tests.

Post-checklist:
- Post a `/kelos needs-input` comment on the issue (gh issue comment {{.Number}} --body "/kelos needs-input") and leave a comment for the reason if any of the following applies:
Expand Down
Loading