Claude Code starts with one command inside your project, and the quality of a session depends on whether your prompts point it at something real it can go check.
1Claude Code Runs Inside Your Project
You launch it with claude from your project's root directory, and it operates with that directory as its working context — it can list files, read them, search across them, and edit them, all scoped to that project.
2It Grounds Itself Before Acting
A well-behaved agentic session reads the relevant files first — the failing test, the implementation, sometimes related callers — before proposing an edit. This is what makes its first answer more reliable than a chat model's: it's reasoning from your actual code, not your description of it.
3Step-by-Step Breakdown
Your First Real Session. You start Claude Code from inside a project directory with a single command: claude. From there it's a conversation, but every turn can involve it actually reading files, searching the codebase, and proposing edits — not just producing text.
It Reads Before It Writes. Given that prompt, Claude Code doesn't immediately edit anything. It first reads src/tasks.test.js to see the actual failing assertion, then reads src/tasks.js to see the actual current implementation — grounding itself in your real code before proposing anything.
Why does Claude Code read both the test file and the implementation file before proposing a fix, instead of just editing based on your one-sentence prompt?
- →It grounds the fix in the actual failing assertion and the actual current implementation, rather than guessing at what 'the failing test' means from the prompt alone.
- →It's a hardcoded requirement to open at least two files per session, regardless of the task.
Notice the Difference in Your Own Prompt. Write the prompt you'd actually give Claude Code to fix a specific failing test in a real project, then compare it to a vague version. The difference isn't length — it's whether you're naming a real, locatable thing in the codebase.
Approving the Change. Before Claude Code edits a file or runs a command, it shows you exactly what it's about to do and asks for approval — this is the permission system, and it's the safety rail that makes agentic access trustworthy. The next lesson covers that loop in full.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
N/A — terminal-based tool.
N/A — terminal-based tool.
N/A — terminal-based tool.
N/A — terminal-based tool.
Accessibility (A11y)
1Name Real Symptoms, Not Vague Feelings
A prompt like 'sumTaskHours returns NaN when a task has null hours' is both more accessible to parse and more actionable than 'something's wrong with the totals' — precision helps the model and helps anyone reading the session transcript later.
SEO Implications
- 1
Target 'how to start a Claude Code session' and 'Claude Code first prompt example' separately
New users search for the literal startup command and for concrete example prompts as two different intents.
Best Practices
Name a File, Function, or Exact Error in Your First Prompt
Prompts that reference something locatable in the codebase let Claude Code start from a grounded read instead of spending a turn asking you to clarify what you mean.
Frequent Bugs
Opening a session with a vague, symptom-only prompt like 'the export button is broken.'
Name the actual file, component, or error message where you observed the problem — 'the export button in src/ExportButton.jsx throws on an empty list' gives Claude Code a real starting point.
Real-World Examples
Vague vs. Specific First Prompt
One developer opened a session with 'fix the bug in tasks.' Claude Code had to ask which bug, in which file. A second developer opened with 'sumTaskHours in src/tasks.js returns NaN when hours is null' — Claude Code read the file and proposed a fix in the same turn.
// Vague: "fix the bug in tasks"
// Specific: "sumTaskHours in src/tasks.js returns NaN when hours is null"