Grok coding workflow

After connecting Grok, use a small task with clear acceptance criteria to verify coding capabilities. Complete VS Code setup or Grok Build installation first.

#1. Define the task and boundaries

At the project root:

git status --short
git diff --stat

Tell the model which files already contain changes. A suitable first task is “Fix empty input handling in this function using existing tests.” Avoid a repository-wide refactor as your first trial.

#2. Start with read-only analysis

In Cline or Grok Build:

Inspect this project without modifying files.
Find the target function, its call sites and existing tests.
Explain the actual cause, then propose a minimal change plan.
Preserve uncommitted changes and use the package manager specified by the lockfile.

Check that it read the implementation instead of guessing from file names. Use Plan mode in Cline if useful, and confirm the provider remains Passion8 after switching to Act.

#3. Put rules in the client's correct location

Cline: use its own project rule entry point; see Cline multi-model setup.

Grok Build: add an AGENTS.md at the repository root:

# Project instructions

- Read the implementation and relevant tests before editing.
- Preserve unrelated local changes.
- Follow the existing naming and formatting conventions.
- Do not upgrade dependencies for a small bug fix.
- Run the relevant existing checks and report their real results.
- Report changed files and unverified behavior.

Official Grok Build loads project rules along the directory tree, with deeper files taking precedence on conflicts. A monorepo can have package-specific AGENTS.md files. Check discovered rules and configuration sources with:

grok inspect

AGENTS.md is a Grok Build rule mechanism; do not assume every third-party extension reads the same file.

#4. Edit, approve and verify

After approving the plan:

Fix the bug using the approved plan.
Change only the target implementation and necessary tests.
Do not edit other modules.
Show the diff, then run this project's relevant existing checks.

Review writes before approving test commands. Grok Build can also run a single task with your configured Passion8 alias:

grok -p "Explain the target function and existing tests without editing files" -m passion8-grok

Here passion8-grok is the custom model section alias from installation, not a new model ID.

#5. Inspect before accepting

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

Confirm the fix addresses the original bug, tests actually ran and no unrelated changes were added. The model's report should list changed files, test commands and results, and unverified behavior. Finish one goal before starting the next task.

#Long context and tool boundaries

The official 500k window is not a reason to send the entire repository every time. Prefer search and focused reads, keeping relevant files in context. Check client budgets, automatic compaction and channel limits separately. Reduce context when a long conversation fails.

Cline file, terminal and MCP tools run in the client. xAI hosted Web Search and X Search use different interfaces. Function calling alone does not establish their availability through Passion8. For a text connection check, see Grok API. Console records establish usage and model routing.

#Verified sources

Checked: 2026-10-11.

• Grok Build project rules
• Grok Build custom models and inspect
• Grok 4.7 capabilities