send-it

# Send It / Stage It When the user says **"send it"**: ## 1. Stage and pre-commit - Run `git status` to see all changed and untracked files. - Only stage files that were **created or modified as part of this task**. Use `git add <file>...` with explicit paths. - If there are unstaged changes in files **not related to this task**, list them and ask the user what to do (stage them too, ignore, stash, etc.). Do not silently include unrelated changes. - Run `uv run pre-commit run --all-files` to validate staged changes. - If pre-commit hooks fail, fix every reported issue, re-stage the fixes, and re-run. Repeat until all hooks pass. ## 2. Ask: stage only or commit? Use the **AskQuestion** tool to ask the user: > **"All pre-commit hooks pass. What would you like to do?"** > > - **Stage only** — leave changes staged for local review > - **Commit and push** — commit, push, and open/update a PR If the user chose **Stage only**, stop here. ## 3. Commit - Run `git diff --cached` and `git log --oneline -5` to review staged changes and match the repo's commit style. - Write a concise commit message summarizing the changes. - Run `git commit` with that message. ## 4. Sync and push - Run `git pull origin main` to merge latest main into the branch. - Run `git pull origin` to sync the current branch (ignore errors if the remote branch doesn't exist yet). - Run `git push -u origin HEAD` to push (sets upstream if needed). ## 5. PR creation (if needed) - Check if a PR exists: `gh pr view --json url --repo cognitedata/toolkit 2>/dev/null`. - **If no PR exists**, suggest creating one: - Ask the user for the Jira ticket ID. - Propose a title: `[TICKET-ID] Description of changes`. - Draft a body by reading `.github/pull_request_template.md` and filling it in using `git log main..HEAD --oneline`. - **Do not include Jira ticket IDs in the Changelog entries** — they have no public interest and clutter the changelog. The ticket ID belongs only in the PR title. - **Always ask the user which bump type applies** using the AskQuestion tool: > **"What bump type should this PR use?"** > - **Patch** — backwards-compatible bug fix or small improvement > - **Skip** — no version bump (e.g. docs, CI, test-only changes) - Reflect the answer in the PR body's Bump section: check the chosen option, leave the other unchecked. Both checkboxes must always be present: `- [x] Patch` / `- [ ] Skip` or `- [ ] Patch` / `- [x] Skip`. - Show the proposed PR title and body, and **ask for confirmation** before creating it. - If the user confirms, create the PR as a **draft**: ```bash gh pr create --title "..." --body "..." --base main --draft --repo cognitedata/toolkit ``` - After creation, verify the PR body doesn't contain "Made with Cursor". If it does, suggest the user disable this in Cursor settings: **Settings > General > uncheck "Include 'Made with Cursor' in PRs"**. - Comment "/gemini review" on the PR to request a review from Gemini. ## 6. Monitor CI - Launch a **background agent** (`subagent_type="shell"`) to run `gh pr checks --watch --repo cognitedata/toolkit`. - When checks complete, report back: **green** (all passing) or **red** (with names of failed checks). - **If all checks pass**, mark the PR as ready for review: `gh pr ready --repo cognitedata/toolkit`. - **If checks fail:** - For each failed check, fetch its logs with `gh pr checks --repo cognitedata/toolkit` and `gh run view <run-id> --log-failed --repo cognitedata/toolkit`. - **Transient failures** (network timeouts, flaky tests, rate limits, runner issues): re-run the failed job once with `gh run rerun <run-id> --failed --repo cognitedata/toolkit`. - **Non-transient failures** (lint errors, test assertions, type errors, build failures): read the logs, fix the underlying code issue, then run the full "send it" flow again (stage, commit, push, monitor).