OneRange

Grok for Developers: Core — Grok Build in the Terminal

Grok Build for working developers: sign in and choose a model, give the agent the right context with AGENTS.md and .grok/rules, control it with permission modes and allow/deny rules, run agentic coding tasks with planning and review discipline, use sandbox profiles for untrusted code, connect tools with MCP servers, work in large codebases, and decide when Grok in Cursor or another editor is the better fit

What this course covers

The course runs across 10 topics, each one a short adaptive session rather than a recorded lecture. The tutor explains the idea, works an example, checks understanding, and adjusts the next step to the answer given.

  • Getting set up: sign-in and choosing a model — Install Grok Build from the official overview, run grok in a practice repo and sign in through the browser (or set XAI_API_KEY, or use grok login --device-auth on a remote machine). Choose a model with -m, /model or a default in ~/.grok/config.toml, and run grok inspect to see which rules, skills, hooks and MCP servers it found.
  • Giving Grok Build context: AGENTS.md and .grok/rules — Write AGENTS.md with build and test commands, conventions and never-do rules, and add focused *.md files in .grok/rules/. Grok Build also reads CLAUDE.md and .cursor/rules/, reads from the repo root down to your working directory, and the deeper file wins on conflict; there is no GROK.md.
  • Permission modes and allow/deny rules — Ask (the default) prompts before actions, Plan only plans, Auto lets a classifier approve safe tools where available, and Always-approve runs tool calls without asking; Shift+Tab cycles them. Add allow and deny rules in config or with --allow/--deny: deny always wins, and risky commands like rm and git push still prompt even after a remembered "always allow".
  • Agentic coding tasks with planning — Use /plan (or Shift+Tab into Plan mode) so only the plan file can change until you approve it, then have Grok Build implement a small feature with tests, step by step. Keep each task small and give it a clear way to check its own work.
  • Review discipline: diffs, rewind and branches — Decide whether to accept, change or reject each part of an agent's diff, and split out unrelated or risky edits. Work on a branch or worktree and commit often: git is your real undo, and /rewind only takes the session back to an earlier turn — it does not undo commands that already ran.
  • Sandbox profiles and untrusted repositories — The sandbox is off by default; turn it on with --sandbox or [sandbox] profile (workspace, devbox, read-only, strict). For untrusted code use strict with narrow allow rules and a custom deny list for ~/.ssh, .env and keys, and remember child-network blocking only works on Linux.
  • Connecting tools with MCP servers — Add servers with grok mcp add (stdio, or --transport http for remote servers) or in [mcp_servers.<name>] in config.toml, choosing user or --scope project. Keep tokens out of files with ${VAR} expansion or OAuth, check with /mcps and grok mcp doctor, and prefer read-only tools.
  • Working in large codebases: compacting, effort and the explore subagent — Keep long sessions on track with /compact (Grok Build also auto-compacts as context fills), set reasoning effort with /effort, and use the built-in explore subagent, which can read and search but cannot edit or use the shell, to map a big repo before changing it.
  • Grok in Cursor and other editors: when to use which — Grok models are available in Cursor (if your plan includes them), GitHub Copilot and Warp, and Grok Build can run inside editors that support the Agent Client Protocol (grok agent stdio). Choose the editor agent for in-editor edits and Grok Build for terminal-first tasks with its own rules, permissions and sandbox; Cursor still recommends its own Composer model for everyday coding.
  • Capstone: an end-to-end feature with review — Take one ticket from plan to reviewed change in Grok Build on a branch: AGENTS.md in place, the right permission mode and deny rules, an MCP tool for context, tests passing, and a reviewed diff with nothing risky bundled in.

Skills you build

Results are measured against named skills in the OneRange taxonomy of more than 10,000 skills, so a manager sees proficiency per skill rather than a completion tick.

Who it is for

Software developers and technical builders. The material is pitched at intermediate level, and takes roughly 180 minutes at a typical pace. Because every session adapts, someone who already knows a topic moves through it quickly instead of sitting through an explanation they do not need.

It sits in the Tool: Grok track of the Vero AI Catalog, and can be assigned to one person, a team, or the whole company.

How it is delivered and assessed

Delivery is conversational and interactive, including guided lab, branching scenario, code lab exercises. There is no video to sit through and no slide deck to click past.

Understanding is checked with a tool assessment of 5 items, with a pass mark of 70%.

Administrators can copy this course into their own library and adapt it — edit the outline, change the duration, swap the assessment format, or ground it in internal documentation so answers cite the company's own source material.

Also in this track

  • What's New in Grok for Everyone — A short refresher on the latest Grok for Everyone updates
  • Grok: Core — Skills, Connectors & Automations — A hands-on working level for experienced Grok users in any role. Set Grok up the way you work, get precise answers from long documents, teach Grok your recurring tasks with Skills, bring work in through the connectors and Office or Google add-ins your company allows, track news with sourced search, and put recurring jobs on a schedule with Automations. No code, no command line, no admin settings.
  • What's New in Grok for Developers — A short refresher on the latest Grok Build and Grok API updates for developers
  • Grok for Developers: Essentials — Code Review Playbook — A focused playbook for reviewing code with Grok. Learners attach a pull request written by a coding agent to a grok.com chat, ask for severity-ranked, line-referenced findings on correctness, security, risky edits and missing tests, then check each finding against the code instead of trusting it. They leave with a review prompt they can reuse and a short, defensible set of review comments. About 45 minutes including the final.
  • Grok for Developers: Essentials — Refactoring & Migration Playbook — A focused playbook for safe refactoring and migration with Grok. Learners pin a legacy reminder job's behaviour with characterisation tests, then use a grok.com chat to rename, extract a helper and move off a deprecated Python date function in small steps, checking the tests after each one. They leave with a step-by-step refactor pattern and a migration that changes nothing users see. About 45 minutes including the final.
  • Grok for Developers Pathway — Grok for developers from coding in chat to Grok Build in the terminal, agentic engineering, and guarded production integrations on the Grok API. Also includes 4 optional playbooks (Testing, Code Review, Refactoring & Migration, Docs & Onboarding) to take any time after Essentials; they don't count toward the certificate.

Related

Frequently asked questions

How long does this course take?

It runs roughly 180 minutes at a typical pace. Because every session adapts, someone who already knows a topic moves through it quickly instead of sitting through an explanation they do not need.

How is it assigned to a team?

An administrator assigns it from the Vero dashboard to one person, a team, a department or the whole company, and sees progress and results per person and per skill.

Can we customise it with our own documents and terminology?

Yes. Administrators can copy this course into their own library and adapt it — edit the outline, change the duration, swap the assessment format, or ground it in internal documentation so answers cite the company's own source material.

Course code TUL-GRK-DEV-201.