Pair Gemini CLI with Your Shell Workflow

Turn terminal output into useful next steps

Gemini CLI fits naturally into a shell workflow: your existing commands collect evidence, and the assistant helps explain it. Start with focused tasks such as reviewing a diff, interpreting a failed build, or drafting a commit message. Keep execution and verification visible so you can judge each suggestion against the actual project.

This tutorial uses Bash, Git, npm, and a repository you can safely experiment with. The same pattern works for application code, infrastructure scripts, and documentation.

1. Install Gemini CLI

Use a supported Node.js release, such as Node.js 22 or later, and install the CLI with npm install -g @google/gemini-cli. Then run gemini --version and gemini --help to confirm installation and inspect the options available in your installed release.

Open your project with cd /path/to/project, then run git status --short. Knowing which files already have changes makes it easier to distinguish your work from edits the assistant proposes.

2. Configure your API connection

ApiCabin is an AI API relay for indie developers and small teams. One key provides pay-as-you-go access across multiple providers, including models such as Gemini 2.5 Flash and Gemini 3.1 Pro. It supports Gemini CLI alongside other development tools. Sign up at https://apicabin.ai, create a key, and open its current Gemini CLI configuration instructions.

ApiCabin's API address is https://api.apicabin.ai. Follow its instructions for the exact Gemini-compatible base URL, authentication variables, and model identifier. Gemini CLI uses Google's API conventions, so an OpenAI-compatible endpoint alone does not establish compatibility. Avoid guessing a path or treating a display name as an API model identifier.

If the supplied configuration uses GEMINI_API_KEY, load it in Bash with read -rsp 'API key: ' GEMINI_API_KEY; export GEMINI_API_KEY; printf '\n'. This keeps the value out of the typed command and shell history. Apply the documented endpoint configuration, then test with gemini -p 'Reply with exactly: connection ready'.

3. Pipe a small, explicit input

Start with a change review: git diff --cached | gemini -p 'Review the staged diff supplied on standard input. Identify likely bugs, missing edge cases, and useful tests. Explain findings without editing files.'

The pipe supplies the staged diff, while -p runs a noninteractive prompt. Staging selected files first gives you a convenient way to control the review's scope. If nothing is staged, the input will be empty; check with git diff --cached --stat before sending it.

Review the patch yourself for credentials, customer data, and generated noise. Smaller inputs usually produce more relevant feedback and reduce unnecessary API usage.

4. Capture failures before asking for help

Run your test command and save its output: npm test > /tmp/project-tests.log 2>&1. Immediately capture its status with test_status=$?. Replace npm test with your project's actual test command.

Then ask for a diagnosis: tail -n 160 /tmp/project-tests.log | gemini -p 'Explain the failure in this test output. Separate observed evidence from hypotheses and suggest the smallest next diagnostic step.'

Keeping capture and analysis separate preserves the test's exit status. A successful assistant response does not mean the tests passed. Inspect the saved status with printf 'Test exit status: %s\n' "$test_status", and retain the full log if the excerpt omits important context.

5. Make a reusable shell helper

Add this Bash function to your shell configuration: gexplain() { gemini -p 'Explain the supplied terminal output. Identify the likely cause and suggest one concrete next check.'; }

After reloading that configuration, use tail -n 100 /tmp/project-tests.log | gexplain. Keep helpers focused: separate functions for explanations, diff reviews, and commit drafts are easier to maintain than one oversized prompt.

6. Verify before committing

Apply the changes you accept, rerun the relevant tests, and inspect git diff. For interactive sessions, check the CLI's current approval settings and read tool requests before allowing commands that modify files or affect external systems.

Use shell tools to establish facts and Gemini CLI to interpret them. A reliable loop is simple: collect a bounded input, ask a specific question, inspect the recommendation, and verify the result locally.