Most "getting started with Claude Code" guides stop at npm install. That is not getting started. That is just installing a binary.

The actual question is: how do you set up your terminal so that giving an agent a goal feels easier than typing the code yourself?

That is what I call the antigravity workflow. Once you have it, you stop reaching for autocomplete. Delegation becomes the default.

Step 1 — Install (30 seconds)

# Requires Node.js >= 18
npm install -g @anthropic-ai/claude-code

# Verify
claude --version

That is it. No SaaS dashboard, no OAuth dance, no IDE extension to debug. The first time you run claude in a project, it asks for your Anthropic API key and stores it in ~/.claude/.

Step 2 — Initialize the project

In your project root:

cd my-project
claude

# Inside the Claude prompt
> /init

/init creates a .claude/ folder with:

• settings.json — model, max tokens, tool permissions.
• CLAUDE.md — the project's "system prompt" (read every session).
• agents/ — definitions of sub-agents you build over time.

This folder is the single most underused feature of Claude Code. Most people leave CLAUDE.md empty. That is the equivalent of hiring a senior engineer and forgetting to tell them what your product does.

Step 3 — Write a real CLAUDE.md

A good CLAUDE.md is shorter than you think. Three sections:

# Project context
- What the product is, in 2 sentences.
- Tech stack: framework, language version, key libraries.
- Where the deployment runs (Vercel / AWS / on-prem).

# Conventions
- Test command: `pnpm test`
- Lint command: `pnpm lint`
- "Never modify files in `app/_generated/`."

# Definition of done
- All tests pass, lint clean, no `console.log` in production paths.

Claude Code reads this file at the start of every session. You are essentially shipping a permanent context window.

Step 4 — The antigravity habit

Here is the workflow shift that took me from "AI is a toy" to "AI ships features":

The key shift: the terminal is the IDE. The diff is what you review, not the file. You stop reading code top-to-bottom; you read diffs.

Step 5 — Permissions you actually want

By default Claude Code asks before running shell commands. After your first session you will be tempted to --yes everything. Don't.

Instead, edit .claude/settings.json:

{
  "tools": {
    "shell": {
      "allow": [
        "pnpm test",
        "pnpm lint",
        "pnpm build",
        "git status",
        "git diff *",
        "ls *",
        "rg *"
      ],
      "deny": [
        "rm -rf *",
        "git push *",
        "npm publish *"
      ]
    }
  }
}

This is the actual sweet spot: the agent runs anything non-destructive without asking, but never touches the irreversible stuff.

Step 6 — Slash commands you should have on day one

Out of the box you get /init, /agents, /compact, /clear, /help. The two I use the most:

• /compact — when the context window starts to bloat, this re-summarises the conversation while keeping decisions intact. It is the difference between a 4-hour session and a 4-message session.
• /agents — opens the sub-agent picker. We will go deep on this in Article 5.

Add these custom commands in .claude/commands/ later in the series — most teams build at minimum a /review, /test-and-fix, and /release-notes once they get fluent.

What "antigravity" actually means

The name is borrowed from a friend who said: "Once Claude Code is set up right, work doesn't fall on me. It floats."

Concretely, that translates into three things:

• You stop micromanaging. You give a goal, not a step list.
• You trust the loop. Read, plan, write, test, iterate — you let it run.
• You only intervene at decision points. Architecture, naming, contract design.

Everything else — boilerplate, refactors, test wiring, dependency wrangling — is the agent's problem now.

---

Next article: Writing Prompts That Work. Because "make it better" is not a prompt. We will look at the four-part structure that makes Claude Code actually finish what you ask it to do.