Claude Code 101: A Practical Learning Guide From First Prompt to Agent Workflows

Claude Code 101: A Practical Learning Guide From First Prompt to Agent Workflows

Claude Code is easy to misunderstand.

At first glance, it looks like another AI tool that writes code. But the real shift is bigger than code generation.

Claude Code is an agentic coding tool. It can read your project, edit files, run terminal commands, use external tools, and work inside an actual development workflow.

That means the most important skill is not "how to ask Claude Code to write code."

The important skill is learning how to delegate work to an AI coding agent with context, boundaries, review, and feedback.

This article is my practical learning guide after going through Claude Code 101. It is not a copy of the course material, and it does not reproduce the official quiz. Instead, it turns the learning path into a public, beginner-friendly guide that moves from simple concepts to advanced workflows.

1. What Claude Code Is

Figure 1: What Claude Code Is

Claude Code is best understood as a coding agent that works inside your development environment.

Unlike a normal chat interface, it can operate closer to the project itself:

• it can inspect files;

• it can understand relationships across a codebase;

• it can edit code;

• it can run commands;

• it can use feedback from command output;

• it can help you move from idea to implementation.

But this does not make it magic.

The agent still needs clear goals, relevant context, boundaries, and review. If you give it a vague request, it may make a vague plan. If you ask it to change too much at once, the output becomes harder to verify.

The first mental model is:

Claude Code is not a code vending machine.
It is a collaborator that needs a well-defined task.

Commands to try:

cd /path/to/project
claude

Use claude when you want an interactive coding session inside the current project.

For one-shot or scripted usage:

claude "explain this project"
claude -p "explain this function"
cat logs.txt | claude -p "explain the failure"

My rule: use interactive claude for real project work, and use claude -p for narrow read-only analysis or scripting.

Reference:

• Claude Code CLI reference

2. How Claude Code Works

Figure 2: How Claude Code Works

Claude Code works through a loop:

understand context -> choose an action -> use tools -> observe results -> continue or ask for help

That loop is what makes it agentic.

A normal chat response ends when the model replies. An agentic coding workflow can continue across multiple steps: reading a file, searching the project, editing code, running a test, seeing an error, and adjusting the approach.

This is powerful, but it creates a new responsibility for the user.

You are no longer only writing prompts. You are managing an agent's working environment.

That means you should care about:

• what context the agent sees;

• what tools it can use;

• what files it is allowed to touch;

• what commands it should ask permission before running;

• what checks prove the work is done.

The better your operating boundary, the better the result.

Commands and controls to know:

/permissions     manage what Claude Code can do
/context         inspect where context is going
/compact         summarize a long session
/clear           start a fresh task while keeping project memory
Esc              interrupt the current response or tool call
Shift+Tab        cycle permission modes, including plan mode

The practical lesson is simple: Claude Code is powerful because it can act, but it becomes safe when you actively manage context and permissions.

References:

• Claude Code commands reference

• Claude Code CLI reference

3. Installing Claude Code

Figure 3: Installing Claude Code

Installation is not the real learning goal.

The real goal is to make sure your environment is ready for agentic work.

Before asking Claude Code to build or modify anything, check:

• Can the tool run in the environment you actually use?

• Is the project available locally?

• Can dependencies be installed?

• Is there a clear command to run or test the project?

• Do you understand which files should not be changed?

• Do you know how to inspect the diff afterward?

For beginners, the installation step should become an environment checklist, not just a setup command.

The agent becomes much more useful when your project has a clear structure and obvious verification commands.

Official install commands:

# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash

# Homebrew
brew install --cask claude-code

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

# Windows CMD
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

After installation:

cd your-project
claude

Useful setup checks:

claude auth status
claude auth login
claude update

If you installed through Homebrew or WinGet, use the package manager to upgrade:

brew upgrade claude-code
winget upgrade Anthropic.ClaudeCode

Reference:

• Claude Code CLI reference

4. Your First Prompt

Figure 4: Your First Prompt

A good first prompt is not long. It is bounded.

A weak prompt looks like this:

Help me improve this app.

A better prompt looks like this:

Please inspect this project and explain the main app structure.
Do not edit files yet.
Focus on the pages, components, and build commands.
After that, suggest one small improvement that can be completed safely.

The second prompt is better because it controls the workflow.

It asks Claude Code to explore first. It prevents premature edits. It defines the area of attention. It asks for one small next step.

When writing a first prompt, include:

• goal;

• current context;

• allowed scope;

• forbidden scope;

• expected output;

• stop condition.

The key is to avoid asking for a whole product in one request.

Commands to start the first session:

cd /path/to/project
claude

Then type:

Give me an overview of this codebase.
Do not edit files yet.
Identify the main app structure, important commands, and one safe first improvement.

You can also start Claude Code with the first prompt already attached:

claude "give me an overview of this codebase; do not edit files yet"

If I want a strictly non-interactive answer, I use:

claude -p "summarize the project structure from the README and package files"

References:

• Claude Code CLI reference

• Claude Code common workflows

5. The Explore -> Plan -> Code -> Commit Workflow

Figure 5: The Explore -> Plan -> Code -> Commit Workflow

This is the core workflow I would teach first.

explore -> plan -> code -> review/check -> commit or revise

Official command spine:

/plan          enter plan mode inside a session
/diff          inspect changes
/code-review   review current diff for correctness and cleanup
/review        deeper read-only review
/security-review review pending changes for security risk
/run           launch and inspect the app
/verify        confirm a code change works by building/running/observing

You can also start directly in plan mode:

claude --permission-mode plan

Explore

Ask Claude Code to inspect the project before editing.

Useful prompts:

Explore this repo and identify the main entry points.
Do not make changes yet.

Find the files related to the course landing page.
Explain how they fit together before editing.

For a large repo, keep exploration read-only:

Use a subagent to investigate how authentication works.
Return only the key files, data flow, and risks.
Do not edit files.

Plan

Ask for a small, reviewable plan.

Propose a minimal implementation plan.
List the files you expect to change.
List anything you will not touch.
Tell me how we can verify the result.

Inside Claude Code, use:

/plan fix the auth bug

or start the whole session in plan mode:

claude --permission-mode plan

Code

Only after the plan is clear should you allow changes.

Proceed with the smallest version of the change.
Do not add new dependencies.
Keep the diff easy to review.

If the work is too broad, stop and split it:

Do only step 1.
Leave the rest as a checklist.

Review and Check

The work is not done when the agent stops typing.

Review the diff. Run the app. Run available tests or checks. Ask the agent to explain the changes.

Commands to use before accepting the work:

/diff
/code-review
/verify

Commit or Revise

If the result is good, commit it. If not, revise or stop.

Useful prompts:

Summarize the diff in plain English.
What changed outside the original scope?
What checks did you run?
If this should be committed, propose a concise commit message.

The workflow is not about speed only. It is about making AI-generated work inspectable.

References:

• Claude Code common workflows

• Claude Code commands reference

6. Context Management

Figure 6: Context Management

Context is Claude's working memory.

Even if the context window is large, it is not infinite, and more context is not always better.

You need to decide what belongs where:

Context management is the difference between constantly re-explaining yourself and building a reusable collaboration environment.

For a small task, a prompt may be enough.

For a repeated project, use persistent instructions.

For a long learning path, use a knowledge system.

Commands and syntax for context:

@src/utils/auth.js       reference a specific file
@src/components          reference a directory listing
@github:repos/owner/repo/issues   reference an MCP resource when connected
/context                 inspect context usage
/compact                 compress a long conversation
/memory                  edit or inspect memory files
/add-dir <path>          add another working directory for this session
claude --continue        resume the latest conversation in this directory
claude --resume          choose a previous conversation

My practical rule: use @file for immediate context, CLAUDE.md for always-needed project rules, and skills for repeated workflows.

References:

• Store instructions and memories

• Claude Code CLI reference

7. Code Review

Figure 7: Code Review

AI coding does not remove review.

It increases the importance of review.

When reviewing Claude Code output, ask:

• What files changed?

• Is the diff smaller or larger than expected?

• Did it modify files outside the scope?

• Did it add new dependencies?

• Did it remove behavior accidentally?

• Did it run checks?

• Can I explain the change in plain language?

A simple review framework:

Accept: the change matches scope and passes checks.
Revise: the direction is right but needs correction.
Reject: the change violates scope or creates unacceptable risk.
Stop: the task is unclear or the project state is unsafe.

For non-engineers, this may be the most important part of the workflow. You do not need to understand every line of code immediately, but you do need to recognize when the agent has changed too much.

Commands to make review concrete:

/diff
/code-review
/code-review --fix
/review
/security-review
/verify

Prompts I would use:

Review this diff for behavior regressions, scope creep, missing tests, and risky dependencies.
Lead with findings.
Do not rewrite code unless I ask.

Run the available checks and explain which risks remain.

References:

• Claude Code common workflows

• Claude Code commands reference

8. The CLAUDE.md File

Figure 8: The CLAUDE.md File

CLAUDE.md is project memory.

It is where you put durable instructions that should not be repeated in every prompt.

Good things to include:

• how to run the project;

• important commands;

• coding conventions;

• files or folders to avoid;

• testing expectations;

• product context;

• common mistakes;

• deployment notes.

Bad things to include:

• vague motivational text;

• huge copied documentation;

• outdated instructions;

• rules that conflict with the actual repo;

• too many unrelated goals.

The purpose of CLAUDE.md is not to make the agent obedient. It is to make collaboration less repetitive and less fragile.

The command I missed in my first version of this article is important:

/init

Run /init inside a Claude Code session to generate a starter CLAUDE.md. Claude Code analyzes the codebase and creates a starting guide with discovered build commands, test instructions, and conventions. If a CLAUDE.md already exists, /init suggests improvements instead of blindly overwriting it.

If you want the newer interactive initialization flow:

CLAUDE_CODE_NEW_INIT=1 claude

Then run inside the session:

/init

Use /memory after /init to refine memory files:

/memory

Important file locations:

./CLAUDE.md              project instructions shared with the repo
./.claude/CLAUDE.md      alternative project instruction location
./CLAUDE.local.md        personal project notes, usually gitignored
~/.claude/CLAUDE.md      personal instructions across projects

If a repo already has AGENTS.md, create a CLAUDE.md that imports it:

@AGENTS.md

## Claude Code

Use plan mode for risky changes.

That keeps instructions shared across coding agents without duplicating everything.

References:

• Store instructions and memories

• Claude Code commands reference

9. Subagents

Figure 9: Subagents

Subagents are useful when a task naturally separates into roles.

For example:

• one agent researches the codebase;

• one agent reviews a diff;

• one agent writes tests;

• one agent checks documentation.

But subagents also add complexity.

Do not start with subagents. Start with the base workflow:

explore -> plan -> code -> review

Only introduce subagents when the work has clear role boundaries.

For a beginner course, I would teach subagents as a later module, not as day-one material.

Commands and patterns:

/agents

Use /agents to manage agent configurations.

You can also ask directly:

Use a subagent to investigate how our auth system handles token refresh.
Return only the relevant files, flow, and risks.

For temporary CLI-defined subagents, Claude Code supports --agents:

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on correctness, security, and maintainability.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

If a built-in or custom subagent is causing problems, deny it:

claude --disallowedTools "Agent(Explore)"

Reference:

• Claude Code subagents

10. Skills

Figure 10: Skills

Skills are best understood as reusable workflow contracts.

A good skill should define:

• when to use it;

• what context to read;

• what it is allowed to do;

• what it must not do;

• what output it should produce;

• how to verify quality;

• when to stop.

That is much more useful than thinking of skills as "better prompts."

For example, a code review skill should not just say:

Review this code.

It should say:

Check for behavior regressions, scope creep, missing tests, risky dependencies, and unclear diffs.
Lead with findings.
Do not rewrite unrelated code.

Skills matter because they turn repeated judgment into reusable process.

Commands and paths:

/skills
/reload-skills
/summarize-changes

Skills can live at different scopes:

~/.claude/skills/<skill-name>/SKILL.md      personal skill
.claude/skills/<skill-name>/SKILL.md       project skill

A minimal project skill looks like this:

.claude/skills/summarize-changes/SKILL.md

---
description: Summarizes uncommitted changes and flags anything risky.
---

## Current changes

!`git diff HEAD`

## Instructions

Summarize the changes, then list risks such as missing tests, hardcoded values, or broad diffs.

Then invoke it:

/summarize-changes

My rule: if I paste the same workflow three times, it probably wants to become a skill.

References:

• Claude Code skills

• Claude Code commands reference

11. MCP

Figure 11: MCP

MCP, or Model Context Protocol, is about connecting models to tools and context in a structured way.

The practical question is:

What should the agent be able to access or do?

For example:

• read files;

• query a database;

• search documentation;

• inspect browser state;

• call an internal API;

• create a ticket;

• update a knowledge base.

MCP is powerful, but it should not be added just because it sounds advanced.

Before adding a tool, ask:

• What problem does this tool solve?

• Can the current workflow solve it manually?

• What permissions does it need?

• What can go wrong?

• What should the agent never do?

• How will we verify the result?

Good agent systems are not built by connecting every tool. They are built by connecting the right tools with the right boundaries.

Commands to manage MCP:

/mcp

Add a remote HTTP MCP server:

claude mcp add --transport http <name> <url>

Example:

claude mcp add --transport http notion https://mcp.notion.com/mcp

Add a local stdio server when the tool needs local system access:

claude mcp add <name> -- <command> <args>

After MCP is connected, you can reference resources with @server:resource syntax:

Show me the data from @github:repos/owner/repo/issues

My rule: do not add MCP until the manual workflow is painful and the permission boundary is obvious.

Reference:

• Claude Code MCP

12. Hooks

Figure 12: Hooks

Hooks are automation triggers.

They can run actions around events in the workflow.

For example:

• after a file edit;

• before a command;

• after tests;

• when a session starts;

• when a session ends.

Hooks can be useful, but they are also easy to overuse.

A good hook should have:

• a clear trigger;

• one allowed action;

• a safety boundary;

• a stop condition;

• a log or visible output.

Bad hook design turns automation into hidden behavior.

Good hook design makes repeated safety checks easier.

My rule:

Do something manually three times before automating it with a hook.

Commands and files:

/hooks
~/.claude/settings.json
.claude/settings.json

Use /hooks to inspect configured hooks. To create or change hooks, edit the settings JSON.

Example: run Prettier after Claude edits or writes a file:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Example: block edits to sensitive files with a PreToolUse hook:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-files.sh"
          }
        ]
      }
    ]
  }
}

My warning: hooks are not prompts. They are automation. Treat them like production code.

References:

• Claude Code hooks guide

• Claude Code power user customization: how to configure hooks

• Claude Directory hooks catalog - useful for seeing full-stack hook patterns such as linting, formatting, testing, dependency audits, secret scanning, branch protection, bundle-size checks, and coverage guards.

• bartolli/claude-code-typescript-hooks - a concrete hook repo with React/Next/Vite, Node TypeScript, and VS Code extension quality-check hooks.

Practical Command Cheat Sheet

If I only remember one page from this article, it should be this:

References:

• Claude Code CLI reference

• Claude Code commands reference

13. Course Review Notes

I do not recommend publishing official course quiz answers.

What I prefer to do is summarize the concepts in a way that helps me answer similar questions later. This keeps the learning useful without turning the course into an answer key.

Here is how I would summarize the key ideas from this course.

If the question is: What makes Claude Code different from a normal chat assistant?

A good way to answer is:

Claude Code works inside a development environment. It can read files, edit code, run commands, and use feedback from tools. That makes it closer to an agentic coding collaborator than a normal chat interface.

If the question is: Why should Claude Code explore before editing?

A good way to answer is:

Exploration helps the agent understand the repo structure, relevant files, and constraints before it makes changes. This reduces premature edits and makes the plan easier to review.

If the question is: What should a good first prompt include?

A good way to answer is:

A strong first prompt should include a clear goal, relevant context, allowed scope, forbidden scope, expected output, and a stop condition.

If the question is: What is CLAUDE.md for?

A good way to answer is:

CLAUDE.md stores durable project instructions so the user does not need to repeat the same context in every prompt. In a new repo, run /init inside Claude Code to generate a starter CLAUDE.md, then use /memory to refine it.

If the question is: When should subagents be used?

A good way to answer is:

Subagents are useful when work naturally separates into clear roles, such as research, implementation, review, or testing. They should not be added just because they sound advanced.

If the question is: What is the practical purpose of MCP?

A good way to answer is:

MCP gives the agent structured access to tools, resources, and external context. Its value depends on clear permissions, boundaries, and verification.

If the question is: What makes hooks risky?

A good way to answer is:

Hooks can create hidden automation. If the trigger, allowed action, safety boundary, and stop condition are unclear, they can make the system harder to understand and control.

If the question is: What is the safest core workflow for beginners?

A good way to answer is:

explore -> plan -> code -> review/check -> commit or revise

This keeps the work small, visible, and reviewable.

In Claude Code command terms, that often becomes:

/plan -> approve small change -> /diff -> /code-review -> /verify

Reference:

• Claude Code 101 course page

My Main Takeaway

Claude Code is not mainly about getting code faster.

It is about learning a new way to work:

define intent
provide context
set boundaries
delegate a small task
review the result
feed learning back into the system

For product builders and non-engineers, this is especially important.

AI coding agents lower the barrier to building, but they do not remove the need for judgment. The better you become at scoping, reviewing, and giving feedback, the more useful the agent becomes.

The real skill is not prompting.

The real skill is controlled delegation.

Knowledge Map