Make a checked repository change with Gemini CLI

Start Gemini CLI in the checkout you intend to change. Choose a small failure with an observable result, and keep unrelated local changes out of the exercise.

This walkthrough uses the retry-delay example: the first retry waits two seconds, while the requirement says one. The caller numbers retries from one. Use the repository's actual test command and a branch or worktree appropriate to your normal development process.

Inspect the project context

Keep stable project facts in GEMINI.md: source directories, check commands, important contracts, and how to report incomplete verification. Use /memory show to inspect the loaded instruction text. After editing context files, /memory reload reloads them.

For a small JavaScript package, useful instructions might be:

# Development context

- Retry attempts are numbered from one.
- Preserve the thirty-second delay cap.
- Locate the test command in package.json before running it.
- Check the original failure and report the commands and exit status.

A file's presence does not prove its contents were loaded. Compare the memory display with the rules you expected.

Plan the change interactively

Launch with gemini --approval-mode=plan, or use /plan in the interactive session. Plan Mode normally limits activity to research and plan artifacts; custom policies can alter that boundary.

Give it a concrete request:

Find why the first retry waits two seconds. Trace how the caller numbers attempts, identify the smallest correction, and propose checks for attempts 1, 2, and 6. Preserve the cap. Show the affected files and unresolved decisions before implementing.

Review the actual proposed change. It should distinguish a caller-numbering problem from a formula problem and explain which evidence settles that choice. Approve the concrete implementation when it fits your task.

For automation, read the separate programmatic guide. Headless planning has different transition behavior; this interactive review sequence is not a human approval mechanism inside an unattended command.

Check the implementation in its real workspace

Let the agent make the agreed change, then inspect the diff and run the focused check. Follow with the relevant repository checks. Record which checkout and revision produced the results.

For the sample formula Math.min(1000 * 2 ** (attempt - 1), 30000), the expected delays are one second, two seconds, and thirty seconds. Invalid attempts need an explicit contract; the agent should not add one silently.

What goes wrong

The session may start in the wrong directory, load stale instructions, or propose a fix before finding the caller. A plan may include broader cleanup that has little to do with the failure.

Resolve the directory or evidence problem first. Review any added scope before execution, and use the repository's permission and integration policy.

How to check

Confirm the original code fails the first-delay check and the changed code passes it. Inspect the diff for an altered cap or retry count. Verify the reported command ran in the checkout containing that diff.

Try the relevant application behavior yourself when the change affects a user flow. Keep failed checks and unresolved contract questions with the review.