# Gemini coding workflow

> Move from read-only analysis to planning, edits and verification using Cline or API-key Gemini CLI.

URL: https://docs.passion8.cc/en/docs/gemini/workflow
Language: en
Publisher: Passion8

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](https://docs.passion8.cc/en/docs/gemini/vscode); existing CLI users can follow [Gemini CLI setup](https://docs.passion8.cc/en/docs/gemini).

## 1. Check repository state

In the target project's terminal:

```bash
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:

```text
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](https://docs.passion8.cc/en/docs/cline). Gemini CLI can use `GEMINI.md` at the repository root:

```markdown
# 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:

```text
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

```bash
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](https://docs.passion8.cc/en/docs/gemini/api). 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](https://geminicli.com/docs/reference/configuration/)
- [Gemini CLI IDE integration](https://geminicli.com/docs/ide-integration/)