Gemini coding workflow

A working connection should lead to reviewable code and verification records. This walkthrough uses Gemini for one small change in an existing repository. For the editor route, see VS Code setup; existing CLI users can follow Gemini CLI setup.

#1. Check repository state

In the target project's terminal:

git status --short
git diff --stat

Record existing changes and tell the model to preserve them. Give a specific goal such as “Fix date formatting for empty string input” instead of “Optimize this project.”

#2. Read before writing

In a new Cline task or Gemini CLI session:

Inspect this repository without modifying files.
Find its package manager, startup command, relevant tests,
and the date formatting implementation and call sites.
Preserve existing uncommitted changes.
Explain the cause using actual files, then propose a minimal change plan.

Verify the cited files and commands exist. Do not accept paths guessed from a common project structure. In Cline, discuss in Plan mode before switching to Act, and check both modes use Passion8.

#3. Provide stable project instructions

In Cline, use project rules for build commands, language and acceptance requirements; see Cline setup. Gemini CLI can use GEMINI.md at the repository root:

# Project instructions

- Read existing code and tests before editing.
- Preserve unrelated working tree changes.
- Use the package manager specified by the lockfile.
- Reuse existing helpers and avoid unrelated refactors.
- Run relevant existing checks after the change.
- Report the exact commands, results and any unverified behavior.

Run /memory show in the CLI to confirm loading, and /memory refresh after editing rules. Do not assume Cline reads GEMINI.md automatically; clients use different rule entry points.

#4. Limit edits and tests

After approving the plan:

Fix the edge case using the approved plan.
Change only the related implementation and necessary existing tests.
Do not upgrade dependencies or edit other modules.
Show the diff, then run the relevant checks that actually exist in this project.

Review file writes and commands individually. If a database migration, deployment or unrelated dependency installation appears, return to the plan to establish its necessity.

#5. Verify yourself

git diff --check
git diff --stat
git diff

Confirm implementation, tests and file scope match the goal. Check tests actually ran successfully and identify skipped checks. When no tests exist, describe the manual verification used; a completion message is not a passing test.

#Context and cost

Ask the model to locate files through names and focused searches before reading relevant content. Avoid sending the entire repository every time. Start a new conversation when the goal changes; file content and tool output in long conversations also consume tokens. Check calls and billing in Passion8; client estimates are supplementary.

For tool failures, distinguish connection problems from model capabilities. If ordinary text fails, return to API setup. If only tools fail, inspect the Cline format, account channel and exact error. Google search or hosted Grounding is not required for local file reads.

#Verified sources

Checked: 2026-10-11.

• Gemini CLI configuration and contextual memory
• Gemini CLI IDE integration