Your First Session

Open Grok in a folder, send a clear goal, approve a tool if asked, and check that the result is correct.

Finish Getting Started first
Prerequisites

Complete Getting Started so grok runs and you can sign in. You do not need to know how to program yet—we use tiny practice files.

Abstract view of chat history and input bar
Top: conversation history (scrollback). Bottom: where you type (prompt).

Open a session safely

  1. Open your terminal (the text command window from Lesson 1).
  2. Go to a project folder

    For practice, reuse the lab folder:

    cd ~/tmp/grok-lab

    If that folder does not exist, recreate it as in Lesson 1. For real work later, cd into your game or app folder instead.

  3. Start Grok

    Type grok and press Enter. Wait until you can type at the bottom of the screen.

What you will see
  • A large history area (may be empty or show a welcome).
  • A typing area at the bottom—this is the prompt.
  • Your words appear in the history after you press Enter.

Why start inside a project folder? Grok focuses on the files around you. Starting in the right folder prevents it from editing the wrong place.

What happens when you send a message (the “turn”)

One turn is one full round of work:

  1. You send a goal

    You type what you want and press Enter. Clear goals work better than vague ones (examples below).

  2. Grok plans and uses tools

    A tool is an action Grok takes: open a file, edit a file, run a command, or search the web. You will see each action appear in the history area above as it happens.

  3. You may get a permission question

    By default Grok often asks before changing files or running shell commands. That is intentional safety—not an error.

  4. Grok continues until the goal is met—or asks you something

    If your message said “run the tests and fix failures,” a good run keeps going until tests pass or it truly cannot.

  5. You reply with the next instruction

    Conversations are multi-turn. Each new message can refine the work.

How to write instructions Grok can follow

Grok is powerful, not psychic. A strong message has five parts. You can write them as a short list:

Goal: what “done” looks like for a human user
Context: which files matter (or “look around first”)
Constraints: rules (no new libraries, keep the same style, …)
Non-goals: what to leave alone
Verification: how to prove it worked (a command or manual check)
Plain English translation

Goal = the outcome. Context = where to look. Constraints = guardrails. Non-goals = do not wander. Verification = the test you will believe.

Too vague

“Fix the game, something is broken.”

Clear enough to act

“Open hi.js. Change the greeting from hi to hello. Do not create new files. When done, show me the full file contents.”

When you know file names and tests exist, include them:

Vague (real project)

“Combat is wrong.”

Strong (real project)

“In combat-helpers.js, critical hits seem to add strength twice. Add a failing test if tests exist, fix the formula, run the project’s test command until it passes.”

Point at files with @

Typing @ in the prompt opens a file picker (a searchable list of files). This attaches those files to your message so Grok does not have to guess which file you mean.

  1. Click in the prompt (bottom).
  2. Type @.
  3. Start typing a file name (for example hi).
  4. Use arrow keys to highlight a file, press Enter to attach it.
  5. Finish your sentence after the attachment, then send.
@hi.js
Please add a comment at the top that says practice file.

Useful patterns (you will grow into these):

@src/main.js           # whole file
@src/main.js:10-50     # only lines 10–50
@src/                  # browse a folder
@!.env                 # include a hidden file (the ! matters)

Why bother? Attaching the right file is the #1 way beginners get accurate edits on the first try.

When Grok asks permission

A permission prompt is a pause that asks you to allow a tool. Read it. If the command looks destructive (deleting everything, force-pushing git, weird network calls), deny and ask Grok to explain.

Ask mode (default)
Grok asks before many edits and shell commands. Best while learning.
Always-approve (sometimes called YOLO)
Skips most questions. Faster; only use on machines and projects you fully trust. Toggle later with /always-approve or the keyboard shortcut covered in the keyboard lesson. You can also start with grok --yolo.
Auto mode
A middle ground: safe actions may auto-run; riskier ones still ask. Available when enabled as /auto.
Simple safety rule

While learning: stay in default ask mode. Never always-approve on a folder full of secrets or on someone else’s untrusted project.

Always say how to check the work

If you do not define “done,” Grok may stop too early or polish the wrong thing. Put the check in the message:

  • Command check: “Run npm test and fix until it passes.” (Only if that project uses npm tests—ask Grok how to test if you are unsure.)
  • File check: “Show me the full contents of hi.js when finished.”
  • Human check: “I will open index.html in a browser; there must be no errors in the console.”

This single habit separates toy demos from reliable engineering with an AI pair.

Change course while Grok is working

  • Cancel: Press Esc to stop the current turn (in normal setups). Your draft text is usually kept.
  • Queue a follow-up: While Grok is busy, type another message and press Enter—it often waits in line for after the current turn.
  • Correct course: After it finishes, say exactly what to stop doing: “Ignore styling. Only fix the test failure.”

You will learn more keys in the Keyboard lesson. For now, Esc and clear follow-ups are enough.

Guided lab — a complete mini session

  1. Enter the lab folder and start Grok
    cd ~/tmp/grok-lab
    grok
  2. Attach the file and give a full instruction

    Type @, select hi.js, then send:

    @hi.js
    Goal: print both a greeting and the current year.
    Constraints: keep this as a simple script; do not add libraries.
    Verification: show me the final file contents in your reply.
  3. Approve edits if asked — read the proposal first.
  4. Read Grok’s reply — does it show the final file? If not, send: “Please print the full final contents of hi.js.”
  5. Optional rename — type /rename first-session-lab and Enter so you can find this chat later.
  6. Leave cleanly — type /quit when finished (or leave the window open if you are continuing to the next lesson).
If something goes wrong
  • @ does nothing: Click the bottom prompt first so it is focused, then type @.
  • Grok edited the wrong file: Say “Revert that. Only edit hi.js.” Better: use @ next time.
  • You approved something scary: Stop with Esc. Ask Grok to undo. If you use Git (later), restore from version control.
Done when

You can start Grok in a folder, send a goal with verification, use @ at least once, handle a permission prompt calmly, and understand what a “turn” is.

First wins ✓

If the lab worked, you have two real wins: Grok is installed, and you can run a full session with a goal, @file, and a permission check. Next big win: finish a First Game or First App walkthrough (express path). Screen and Keyboard lessons help if the terminal feels new—skip them only if you already know the UI.

What to do next

Next: The Grok Screen, then the keyboard lesson. After Beginner, ship a game or app walkthrough.

Self-check

Answer to confirm you understood this lesson. You can still mark the lesson complete after.

1. What is a “turn”?
2. Opening a page in this site counts as…
3. What should a strong prompt include?