Mastering Claude Code

Designing, Building, and Monetizing Agentic AI Workflows

Chapter 1 How Agentic Workflows Change the Industrial Landscape

■A. From $8 Billion to $50 Billion: The Explosive Growth of the Agentic AI Market

In the fall of 2024, a venture capital partner in Silicon Valley put up a slide during an internal meeting. A single graph filled the screen, and the line was climbing at an almost vertical angle. Someone asked, "Isn't this a bubble?" The partner shook his head. "Bubble is a word you use when there are only expectations and no substance. Right now, companies are actually spending budgets."

The market shown by that graph is agentic AI. Agentic AI means artificial intelligence systems that judge for themselves, make plans, and use tools to execute tasks without human intervention. It is different from passive AI that merely answers questions like a chatbot. Give it a goal, and it designs the path to reach it. If a problem occurs along the way, it finds a detour.

The size of this market is estimated at about $7.8 billion in 2025, roughly 10.7 trillion Korean won. According to MarketsandMarkets' 2025 report, the figure is expected to reach about $52.6 billion, roughly 72 trillion Korean won, by 2030. The compound annual growth rate exceeds 46%. Capgemini's analysis, cited by Statista, reached a similar conclusion. It predicted that the market, which was $5.1 billion in 2024, would exceed $47 billion by 2030. Because research firms define the market in different ways, the figures differ, but every report agrees on the direction: at least sixfold growth by 2030.

What matters more than the size of the number is the slope of the growth curve. According to an analysis Omdia released in September 2025, the first-five-year compound annual growth rate of agentic AI reaches 175%. Compared with the 90% first-five-year growth rate of generative AI during the same period, it is almost twice as high. Agentic AI is running faster on top of the infrastructure that generative AI laid down.

■B. Twenty-Five Percent of Companies Have Already Adopted It, and Half Will Operate It by 2027

There is a reason these numbers do not remain investor expectations. Companies are actually opening their wallets.

According to Deloitte's survey, among companies using generative AI, 25% started agentic AI pilot projects in 2025. That share is expected to double to 50% by 2027. Gartner goes one step further. It predicted that by the end of 2026, 40% of enterprise applications would embed task-specific AI agents. Considering that the rate was below 5% in early 2025, that means an eightfold-plus spread in only one or two years.

PwC's 2025 survey gives a more direct number. Seventy-nine percent of U.S. business executives said their companies were already using AI agents "in some form." Eighty-eight percent said they planned to increase AI-related budgets within the next 12 months because of agentic AI.

Still, there is a shadow behind these rosy numbers. Gartner warned that more than 40% of agentic AI projects could be canceled by the end of 2027. Rising costs, unclear business value, and insufficient risk control are the main causes. In Capgemini's survey, only 2% of companies had taken agentic AI all the way to scaled deployment. The gap between a 79% adoption rate and a 2% full-operation rate. That gap is the opportunity. Companies want agentic AI, but people who can build and operate it properly are scarce. That is why this book aims to help you develop that capability.

■C. The Ceiling of Traditional Automation and the Breakthrough of Agentic Systems

(1) The Limits of Rule-Based Automation Such as n8n and Zapier

Why are companies moving so urgently toward agentic systems? Because they have run into the limits of existing automation tools.

If you have used tools such as Make, n8n, or Zapier, you know the process well. You put a node on the canvas. You configure it. You connect the next node. You check whether variables are passed correctly. You test. You add another node. When an error appears, you read the message, find the cause, and fix it. You test again. You repeat this process.

This approach shines in predictable work. In AI automation, it is the kind of task called deterministic: the same input always produces the same output. When a customer submits an inquiry form, an email goes to the person in charge, a row is added to a spreadsheet, and a notification appears in Slack. The same order, the same result, every time. Boring, but beautiful in its predictability.

The problem comes when an exception occurs. What if a customer enters a phone number in the email field? What if the attached file format is different from what was expected? What if an API suddenly changes its response format? Rule-based automation stops when it meets these exceptions, these edge cases. Then someone has to go in and fix it manually. That is maintenance, that is time, and in the end that is cost.

(2) A Structure in Which Agents Handle Edge Cases Themselves During the Build Process

Agentic workflow reverses this process. Instead of telling the system step by step "how to do it," you explain "what you want." The agent figures out the rest.

Imagine that you hired a capable developer. You do not explain the code line by line. You explain the problem, describe the desired outcome, and ask, "Do you need anything else?" That is how agentic systems work. The system reasons. It adapts to the situation. If needed, it asks questions. If something breaks, it diagnoses and repairs it on its own.

An AI automation consultant in the United States described the difference this way. "Traditional automation is like finding a destination with a paper map and a compass. You read street names, plan the route yourself, and if you take a wrong turn, you have to notice it and come back on your own. Agentic workflow is like taking out a smartphone and searching for the destination. A blue line appears, and you follow it. If you leave the route, it automatically recalculates and guides you again."

Both methods can reach the destination. But the experience is completely different.

One thing must be clear here. Agentic systems do not replace traditional automation. For repetitive and predictable tasks, rule-based automation is still suitable. The real value of agentic systems appears in areas that require judgment, processes with many variables, and tasks such as research where inputs and outputs differ every time. Customer support, competitor analysis, and content pipelines fall into this category. They are processes with many moving parts and no single correct answer.

(3) The Train Track Analogy: Battle-Testing with Many Scenarios Before Deployment

The point where the real strength of an agentic system appears is the build stage.

Building traditional automation is like laying train tracks by hand. You install every rail, every switch, every connection yourself. Agentic workflow is like telling a construction team, "Please lay train tracks from here to there." The construction team builds it on its own. If it finds weak ground during construction, it reinforces it. If a curve seems too sharp, it adjusts the angle. Edge cases that humans did not think of are handled during the construction process.

And before deployment, you run battle tests. To continue the train-track analogy, you do not begin operation just because the tracks are complete. You run ten trains of different weights. You test trains of different lengths, trains with different wheel specifications, freight cars and passenger cars in turn. Only after you are confident that every kind of train can run safely do you begin actual operation.

In an agentic workflow, this battle test means throwing many input scenarios at it. You feed in normal data, incomplete data, and data in unexpected formats one after another. You observe how the agent handles each situation, and when a problem is found, you revise the workflow and tools. If this process is done thoroughly, the deployed workflow is far less likely to break in real use.

■D. The Difference Between "Deploying an Agent" and "Deploying Code"

(1) The agent stays local, and only workflows and tools go up to the cloud

One of the most common misunderstandings around agentic systems is the idea that "the agent runs 24 hours a day." In reality, that is not the case. At least, it is not the case for the Claude Code-based workflows covered in this book.

I will cover this in detail later in the book, but let me first point out the core principle. The WAT framework used in this book consists of three layers. W is Workflows, A is Agent, and T is Tools. When you deploy a workflow to the cloud, only W and T go up. A, the agent itself, does not go up.

A workflow deployed to the cloud runs according to a set timetable, or cron schedule, or in response to an external signal, a webhook. What runs then is not the agent's judgment, but the code and process the agent created in advance. Take a workflow that automatically sends a newsletter every Monday at 6 a.m. What operates on Monday morning is the Python script and Markdown guide built by the agent, not the agent itself.

(2) Where self-healing works and where it does not

This distinction matters because of the scope of self-healing.

When you sit in front of Claude Code and build a workflow, the agent is working right next to you. If something breaks, the agent detects it immediately. It reads the error message, analyzes the cause, fixes the code, and runs it again. This self-healing ability actually works during the build stage, and it is extremely powerful.

But the moment the workflow is deployed to the cloud and starts running automatically, the agent is no longer there. The deployed code works much like traditional automation. It is predictable, deterministic, and follows fixed logic. If an exception occurs, a human, not the agent, must intervene.

But this is not a weakness. It is a strength. The fact that deployed automation is predictable means it can be trusted. It is risky to place a nondeterministic system, one that may produce a different output every time even for the same input, into a customer's core business process. AI exercises judgment at the build stage, and after deployment, the code produced by that judgment runs repeatedly and reliably. This is the right way for an agentic workflow to operate.

People adopting agentic systems need to understand this distinction clearly so they can set client expectations accurately. You should not promise, "AI will fix everything on its own forever." The accurate explanation is, "AI handles more exceptions in advance during the build process than a human would. That is why the chance of breakage after deployment is much lower."

We have looked at the trend in which companies hit the ceiling of existing automation and turn their attention to agentic systems, and at the principles by which those systems actually work. Then what concrete framework can we use to design an agentic workflow? The answer is the WAT framework, which we will cover in the next chapter. We will unfold the blueprint for how the three layers, workflows, agents, and tools, divide and coordinate one task.

Chapter 2. The WAT Framework: The Blueprint for Agentic Systems

■A. W (Workflows): Natural-Language Instructions Read by the Agent

Picture a school locker. What happens if you toss every subject's homework, exam papers, and class notes into it without thinking? Math solutions lie on top of Korean exam papers, and last month's physical education notice is pressed underneath. Poor grades are not caused by lack of ability, but by not finding the needed materials in time. If you put in binders by subject, divide the shelves, and label the notebooks, the same locker becomes an entirely different space.

The same principle applies to agentic systems. If you tell the Claude Code agent, "Analyze our competitors," the agent must search the web, organize data, create a PDF, and send it by email. If you leave this process to be handled improvised every time, the quality of the output becomes uneven. On one day it misses three competitors, and on another day it sends only text without charts. There is no structure.

The WAT framework solves this problem by dividing an agentic system into three layers. W is Workflows, A is Agent, and T is Tools. These three letters are the backbone running through this entire book.

The first layer, the workflow, is an instruction document written in Markdown format. The word Markdown may feel unfamiliar, but the substance is quite ordinary. It is just everyday Korean sentences with a few symbols added. The hash symbol (#) marks headings, the asterisk (*) marks emphasis, and the dash (-) separates list items. Thanks to these symbols, the agent can see at a glance which parts are major steps and which parts are detailed instructions.

One workflow corresponds to one business process. If there is a "competitor analysis workflow," it describes in natural language the goal, collecting competitor data and generating a branded PDF report; the required inputs, company information, analysis items, and brand assets; the tools to use, web scraping tool, data analysis tool, and PDF generation tool; the expected output, a PDF file with the brand logo and colors applied; and the exception handling method, using an alternative data source if a competitor website blocks scraping.

(1) A step-by-step process written in Markdown

When you open a workflow file, you see human-readable sentences, not code. For example, a newsletter automation workflow contains content like this.

"Step 1: Use the Perplexity API to conduct the latest research on the topic. Step 2: Based on the research results, write the newsletter body in HTML format. Step 3: Use the Nano Banana image generation tool to create three infographics. Step 4: Human review stage. Present three title candidates and wait for approval. Step 5: Send it to the recipient list through Gmail with the approved title."

It is easier to understand this instruction document if you compare it to a cooking recipe. A workflow is a recipe. To make a chocolate cake, you need an order: preheat the oven, crack the eggs, measure the flour, and mix the batter. If you pile up only ingredients without a recipe, no cake comes out. The same is true if you pile up only tools without a workflow.

(2) A structure in which the workflow file evolves by reflecting agent feedback

The real strength of a workflow lies in the fact that it is not fixed. When the agent runs the workflow and encounters a problem, it solves the problem and then revises the workflow file itself.

Let me give an actual example. When the newsletter automation was first run, infographic creation failed because the API endpoint of the image generation tool had changed. The agent detected the error, searched the web to find the new endpoint, and revised the tool code. It did not stop there. The agent added an exception handling item to the relevant step of the workflow file: "If the endpoint changes, check the latest documentation through web search." On the next run, even if the same problem occurs, the agent already knows how to respond.

This is the self-improvement loop. The more it runs, the more refined the workflow becomes, and the less likely it is to repeat the same mistake. In traditional automation, a human had to find the error, fix it, and update the documentation by hand. In an agentic system, those three steps happen automatically inside the agent.

■B. A (Agent): The Project Manager Who Judges and Delegates

(1) It reads workflows, selects tools, and handles errors

The second layer, the agent, is Claude Code itself. It is the very presence that talks with you in the chat window on the right side of VS Code, Visual Studio Code.

If I define the agent's role in one phrase, it is "project manager." A project manager does not lay bricks directly. They read the blueprint, the workflow; call the needed specialists, the tools; decide the order of work; and find alternatives when problems arise.

When a request comes in saying, "Analyze our competitors," the agent first searches the workflow folder to see whether there is a "competitor analysis" workflow. If there is one, it reads that guide. If the guide says, "Step 1: Collect competitor data with the web scraping tool," the agent finds the web scraping tool in the tools folder and runs it. If the execution result returns an error, the agent analyzes the error message, revises the tool code, and runs it again.

The agent's work in this process can be summarized as follows. It reads the workflow. It identifies the available tools. It calls the tools in the right order. When an error occurs, it diagnoses and fixes it. It asks the user questions when needed. When the work is done, it updates the workflow and tools.

(2) A way of delegating work to tools, not to people

It matters that the agent delegates work to tools, not to people. People set the direction, review the result, and give feedback. The actual execution is done by tools.

To show why this distinction matters, let me use another analogy. Imagine ordering food through a delivery app. You enter "one serving of kimchi stew" into the app. The app sends the order to the restaurant, the restaurant cooks, and the delivery driver transports it. You are not standing in front of the gas stove holding the pot yourself. Your role is to say what you want, and the rest is handled by the system.

In an agentic system, you are the customer, the agent is the delivery app, and the tools are the restaurant and delivery driver. Just as the app sends a change to the restaurant when the customer says, "Change the kimchi stew to soybean paste stew," when you say, "Add a price comparison item to the competitor analysis," the agent revises the workflow and adds the needed tool.

■C. T (Tools): Python Scripts That Perform One Task

(1) Modular tools such as web scraping, PDF generation, and data analysis

The third layer, tools, is the part that actually acts. If the workflow is the recipe, the tools are the ingredients. Eggs, flour, sugar, butter. Each ingredient has one role. Eggs bind the batter, sugar adds sweetness, and butter adds flavor.

Tools are the same. One tool performs one task. A tool that scrapes data from a website, a tool that analyzes the scraped data, a tool that converts the analysis results into a PDF, and a tool that sends the PDF by email. Each exists as an independent Python script.

There is no need to be intimidated by the word Python. There is code inside the tool files, but you will almost never have to read or modify that code. The agent creates tools, uses tools, and fixes tools. You only need to check whether the tool output works properly.

The modular nature of tools offers a major advantage in practice. A web scraping tool created once can be reused in a competitor analysis workflow, a job-posting collection workflow, and a dental sales lead collection workflow. You can plug it in where needed like a Lego block.

(2) Claude Code automatically creates tools and automatically fixes them when they fail

It is hard to overstate the fact that tool creation and modification happen automatically.

When the agent recognizes that it must collect data from the web for competitor analysis, it first checks whether there is a suitable tool in the tools folder. If there is not, it creates one itself. It writes a Python script, tests it, and if it fails, analyzes the error and revises the code.

This is a process actually observed by an AI automation consultant in the United States while building a competitor analysis workflow. The agent created a tool that used a web scraping service called Firecrawl to collect data from competitor websites. On the first run, a Unicode encoding error occurred. The agent read the error log, identified emoji characters as the cause, added code to handle those characters in the script, and updated the tool file. In this entire process, the only thing the user did was say, "Fix it."

■D. How the Three W-A-T Layers Collaborate on One Task

Let us follow from beginning to end how the three layers mesh in one task.

You ask the agent, "Analyze our company's competitors and create a PDF report." The agent explores the workflow folder, finds the "competitor analysis" workflow, and reads it. The workflow contains five steps.

In Step 1, the agent calls the "business information collection tool." This tool reads the company information you entered earlier, such as industry, target customers, price range, and core differentiators. In Step 2, the agent calls the "competitor discovery tool." Based on the company information, this tool searches the web and creates a competitor list. In Step 3, the "competitor research tool" collects each competitor's products, prices, and marketing messages. In Step 4, the "competitor analysis tool" synthesizes the collected data and produces a SWOT analysis and opportunity areas. In Step 5, the "PDF generation tool" converts the analysis results into a report with your brand logo, colors, and typeface applied.

Throughout this process, the agent moves along the map called the workflow and calls the appropriate tool at each point. When a tool returns a result, the agent moves to the next step. If a tool fails, the agent diagnoses the error, fixes the tool, and tries again. It then records this experience in the workflow and tool files so that the next run works more smoothly.

We can also explain the reason for using the WAT framework with numbers. If AI tries to handle every step at once, even assuming each step is 90% accurate, the overall success rate falls to 59% after five steps, 0.9 to the fifth power. But if each step is separated into an independent tool, the workflow controls the order, and the agent verifies the result of each step, only the failed step needs to be rerun. There is no need to repeat everything from the beginning.

This is the core of the WAT framework. Probabilistic AI handles reasoning and judgment, while deterministic code handles execution. That division of labor creates the reliability of an agentic system.

The workflow defines "what will be done and in what order," the agent decides "what judgment should be made in the current situation," and the tools "actually execute that judgment." If any one of the three layers is missing, the system does not work properly. An agent without a workflow loses direction, a workflow without an agent remains a plan on paper, and a system without tools cannot execute anything.

With this blueprint in hand, we will now build the first agentic workflow that actually works. One empty folder, one brand logo, and a one-line prompt saying, "Write a newsletter about agentic AI." In the next chapter, I will show from beginning to end how far you can go with just this.

Chapter 3. Newsletter Automation: The First Live Demo

■A. Project Setup Starting from an Empty Folder

Imagine sitting in front of the screen. VS Code is open, and the file explorer on the left has nothing in it. A folder named "newsletters-demo" sits there empty. On the right, the Claude Code chat window waits with the cursor blinking. One hour later, a newsletter with your brand logo and colors will arrive in the inbox from this empty space. Let us follow that process from start to finish.

Every project begins the same way. You open an empty folder and give Claude Code a home. By home, I mean a claude.md file. I will cover this file deeply in Chapter 5, but for now remember one thing. claude.md is the instruction document the agent must read before starting every conversation. It is also called a system prompt.

You put the WAT framework we covered in Chapter 2 into this file. Create workflows like this, store tools in this folder, respond this way when an error occurs. When you drag and drop this guide into the left panel of the file explorer, the first file appears in the folder.

Next, you tell Claude Code, "I just added the claude.md file. Read it and initialize the project. Ask me if you have questions." The agent reads the file, sends a confirmation message that it understands the WAT framework, and begins creating folders in the left panel. Three folders appear side by side: workflows, tools, and temp. A place for workflow files, a place for tool scripts, and a place where temporary files stay briefly. The project's skeleton is now set.

■B. How to Feed Brand Guidelines and a Logo

No matter how well a newsletter is written, without the face of the brand it cannot plant the recognition in recipients that "this is from our company." A logo, a color palette, and a typeface. These three things create the newsletter's identity.

Create one more folder named brand_assets in the left explorer. Drag two files into it. One is the company logo image file, in PNG format, and the other is the brand guideline document. The brand guideline contains information such as main color codes, secondary colors, typefaces, and spacing rules.

A single sentence in natural language is enough to tell the agent that these files exist. "Create the entire newsletter to match my brand. The logo is @AIS.png, and the brand guideline is @AIS-brand-guidelines.png." In Claude Code, when you type the at sign (@), you can directly tag files inside the project. The agent opens the tagged files, understands the shape of the logo, and extracts color codes and typeface information from the guideline.

This process matters because of repeatability. Once you put brand assets into the project, the agent applies the same logo and colors every time you create a newsletter afterward, no matter how many times you do it. A human no longer has to remember each time, "I need to add the logo, what was the color code again?"

■C. From a One-Line Prompt ("Write a newsletter about agentic AI") to Completion

The project structure is ready, and the brand assets are prepared. Now it is time to actually create the newsletter.

Before that, check one setting. At the bottom of the Claude Code chat window, there is a toggle for switching modes. Start with Plan Mode. In this mode, the agent thinks, researches, and plans, but does not actually create files or run code. It is the stage where an architect draws the plans before picking up a shovel.

Type this into the chat window.

"I want to create a newsletter about agentic AI. Research the topic, lay it out nicely in HTML, and include a few infographics. Tell me what technology stack to use and whether there is anything I have missed."

This is enough. It is not a perfect prompt. But this is where the power of Plan Mode appears. The agent accepts this vague request and finds the blanks it needs to fill in by itself.

The agent comes back. It asks three questions.

"Should we connect an external search API for research? I recommend something like Perplexity."

"Should we send the newsletter through a platform like Beehive, or send it directly through Gmail?"

"If you have brand assets, please share them. We can apply a consistent style to the newsletter."

The agent is behaving like a project manager. It takes the client's vague request and asks backward for the information needed to turn it into an executable specification. If a human did this, only an experienced planner could do it.

You answer, "Do the research with Perplexity. Send it through Gmail. I already put the brand assets in the folder."

(1) The stages of research, content writing, human review, and sending

The agent presents the final plan. The newsletter automation workflow consists of five stages.

In the research stage, it uses the Perplexity API to collect the latest trends related to agentic AI. In the content writing stage, Claude writes the newsletter body in HTML based on the collected materials. In the infographic generation stage, it uses an image generation tool to create data visualization images. In the human review stage, it presents title candidates and waits for the user's approval. In the sending stage, it emails the recipient list through Gmail with the approved title.

The last part of the plan is interesting. The agent added a section on its own called "items the user may not have thought of yet." The need for a human review stage, optimization of the email subject line and metadata, and a brand consistency check. This is the moment when the agent functions not as a mere executor, but as a planning partner.

If you like the plan, switch the mode to Bypass Permissions. In this mode, the agent autonomously creates files, runs code, and calls external APIs. The agent creates a to-do list, handles items one by one, and crosses off completed items.

Files begin to appear one by one in the left explorer. Two configuration files, newsletter style settings and recipient list; five tools, research, infographic generation, HTML assembly, Gmail sending, and Google Sheets archive; and one workflow. All of these files were created without human intervention.

(2) The principle by which brand fonts and colors are applied automatically

When the agent assembles the newsletter, the brand guideline you inserted earlier goes to work. The color codes extracted from the guideline are inserted into the HTML code. The main brand color is laid under the header background, the designated typeface is applied to the body text, and secondary colors are used in section dividers. The same color system is reflected in the infographics, so the entire newsletter maintains one brand identity.

This is possible because the agent has "read" the brand guideline file. The same process as telling a human designer, "These are our brand colors," happens with one file tag.

■D. Failure, Fixes, and Checking the Final Email

Now you throw one sentence at the agent. "Write a newsletter about agentic AI." The agent finds and reads the workflow, starts research, generates infographics, and assembles the HTML. In the middle, at the human review stage, it presents five title candidates and asks which one to use. Once you choose one, the email is sent.

But when you open the email, there is a problem. The HTML is broken, so only the background color is visible and the body text cannot be read. The layout is a mess.

This is the moment when the real value of an agentic system appears. With traditional automation, a human would have to open the HTML code and find what went wrong by hand. In Claude Code, one natural-language sentence is enough.

"I received the email, but the HTML is completely broken. I cannot read any of the text. Find the cause, fix it, and send it again."

The agent inspects the HTML code. It finds a problem with inline styles and email client compatibility. Gmail does not support certain CSS, Cascading Style Sheets, the language that controls web page design, and the layout collapsed because of that. The agent fixes the problem and updates both the workflow and the tool files so the same issue does not recur. Then it sends the newsletter again.

You open the second email. The logo is clearly positioned at the top. The brand colors are applied consistently to the header and section dividers. The body is organized by section, covering agentic AI market trends, architecture explanation, and practical use cases. Infographics are inserted throughout, and those infographics also follow the brand color system. At the bottom are a key summary and call to action, followed by links to research sources.

This output is not perfect. The date may be marked incorrectly, and the logo position in the infographic may be slightly off. But this is the first iteration. If you say, "Fix the logo in the upper-left corner of the infographic," or "Change the date to today's date," the agent reflects it immediately. The more you iterate, the more refined the output becomes, and the sturdier the workflow and tools become.

Let us step back here and look down at the whole process. Starting from an empty folder, adding claude.md, adding brand assets, planning in natural language, having the agent automatically create workflows and tools, run them, fail, fix them, and receive the final email. In this entire process, you did not write a single line of code yourself. You did not read API documentation, design a JSON structure, or type HTML tags by hand.

Once you have this experience, the next questions come naturally. Can I make this workflow run automatically every Monday at 6 a.m.? Can I broaden the research scope or segment the recipient list? Can I create not only newsletters but also competitor analysis reports in the same way?

The answer to all of them is yes. And to open all these possibilities, you need something first: the environment where Claude Code lives, namely the installation and setup of VS Code, and the process of shaking hands with the agent for the first time.

Chapter 4. Installing VS Code and the Claude Code Extension

■A. Downloading VS Code and Understanding the Basic Interface

When you receive a new computer at the office, there is something you do first. You decide where to place the desk, adjust the monitor height, and install the programs you use often. What you need to do before starting Claude Code is the same. You prepare a workspace where the agent can work.

That workspace is VS Code, Visual Studio Code. VS Code is a free code editor made by Microsoft, but there is no need to be intimidated by the name "code editor." In this book, VS Code is not a tool for writing code directly. It is the house where the Claude Code agent lives. It is the window through which you view files, organize folders, and talk with the agent.

Installation is straightforward. Search "VS Code" in a web browser and the official download page will appear. Download and install the version that matches your operating system, Windows, Mac, or Linux. When installation is complete, open the program.

When you first open it, a welcome screen appears. There is not much on this screen that you need to focus on. On the left, you will see a vertical menu bar lined with icons. The top icon is Explorer. It looks like two sheets of paper overlapping. This is the panel that shows the project's files and folders. Below it are a magnifying-glass search icon, source control for Git integration in a branching shape, and an Extensions icon shaped like square blocks.

For now, there are only two things you need to memorize: the Explorer icon and the Extensions icon. You can learn the rest one by one when you need them.

■B. Installing the Claude Code Extension and Choosing a Subscription Plan

You cannot use Claude Code with VS Code alone. You need to install an extension. An extension is a plug-in that adds new features to VS Code. It is like installing an app on a smartphone.

Click the square-block Extensions icon in the vertical menu bar on the left. A search box appears at the top. When you enter "Claude Code," the official extension distributed by Anthropic appears at the top. This extension opens the window through which you can talk with the Claude Code agent inside VS Code. Click the "Install" button.

When installation is complete, a small button shaped like the Anthropic logo appears in the upper-right corner of VS Code. This button is the key that opens Claude Code.

(1) The difference between the Pro and Max plans

When you click the button, it asks you to log in. To use Claude Code, you need a paid Anthropic subscription. You cannot access Claude Code on the free plan.

There are broadly two subscription plans. The Pro plan is $17 per month, about 23,000 Korean won, and the Max plan starts at $100 per month, about 137,000 Korean won. You can use all Claude Code features even if you start with the Pro plan. But you reach the usage limit quickly. That is because tokens, explained in detail in Chapter 6, are consumed quickly during the repeated process of building, testing, and revising workflows. Once you reach the limit, you must wait for a certain period.

The Max plan gives you a much more generous limit. When you maintain long sessions with the agent and work on complex projects, you can keep working without interruption. The cost may feel burdensome, but if you shift your perspective, it looks like this. The monthly salary of one software developer ranges from several million to tens of millions of won. Claude Code replaces a substantial part of that developer's work for around 100,000 won per month. If you think of it not as a subscription fee but as the labor cost of a high-speed junior developer, the return on investment looks entirely different.

It is reasonable to start with the Pro plan, experience how often you hit the limit, and then move up to Max if needed.

(2) Authentication process and first screen layout

After subscribing to a plan, return to VS Code. When you click the Claude Code button, a browser window opens and asks you to log in to your Anthropic account. Enter your email and password and complete authentication. The browser then automatically returns to VS Code. A chat interface appears on the right, along with a message that authentication succeeded.

This chat window is similar in shape to KakaoTalk or the Claude web interface at claude.ai. There is an input field at the bottom, and when you send a message, the agent's responses stack above it. The difference is that the agent in this chat window can read, edit, and create files on your computer. It is not just a conversation partner, but a presence that actually acts inside your work environment.

■C. The Roles of the Left File Explorer and the Right Agent Chat Window

After authentication is complete, organize the screen layout. Close all unnecessary tabs, such as the welcome tab and release notes tab. Leave only two areas on a clean screen.

The left side is the file explorer. Every folder and file in the project appears in a tree structure. When the agent creates a workflow file, it appears here. When it creates a tool script, you can check it here. Click a file, and its contents open in the central editing area.

The right side is the agent chat window. This is where you give instructions to the agent, where the agent reports progress, asks questions, and tells you the result.

Understanding the relationship between these two areas is basically the whole of using VS Code. You check files on the left and talk with the agent on the right. When the agent creates or edits files on the left, those changes appear in the explorer in real time.

Now open the project. At the top of the explorer, there is an "Open Folder" button. Click it and choose the folder you will work in. If this is a new project, create an empty folder and select it. It does not matter whether it is the folder you made for the newsletter demo in the previous chapter or a completely new folder.

After you choose a folder, its name appears in the explorer, and the files inside it are listed. If it is an empty folder, nothing appears. Put claude.md there and ask the agent to initialize the project. Then the project setup process we saw in Chapter 3 begins.

Let me point out one common problem in advance. Many people who install VS Code for the first time try to use Claude Code "without opening a folder." If you start chatting while the explorer says that no folder is open, the agent does not know where to create files, so it will not work properly. Before using Claude Code, always open your working folder first. It is like asking for a package delivery without giving your home address.

VS Code is installed. The Claude Code extension is on. The paid subscription has been authenticated. The working folder is open. The agent now has a house to live in. But there is one document you should hand to that agent first. One file that tells it how to work in this house. That file is claude.md.

Chapter 5. claude.md: The File That Gives the Agent a Home

■A. What claude.md is and how it works as a system prompt

A new employee who passed the job interview comes to work for the first time. They sit down at their desk, but there is no guidance document. No work manual, no organization chart, no project status board. They can ask the colleague next to them, "What should I do?" But they have to ask every time, and the quality of the answer depends on that colleague's mood and memory.

Now imagine the opposite. On the first day, a clean onboarding document is sitting on the desk. "You are in charge of content on the marketing team. Publishing the weekly newsletter is your main job. Brand guidelines are in this folder, and the previous newsletter archive is in that folder. Use a friendly tone rather than a formal one, and always use brand colors for infographics." After reading this document, the new employee can start moving in the right direction on day one.

claude.md is exactly that onboarding document.

Every time you send a message, the Claude Code agent reads claude.md before it reads your message. Every time. Without exception. That is why claude.md is not just a memo, but a System Prompt. It is a document that defines the agent's behavior at a basic level.

An agent without claude.md only reacts to your questions with no context. Its outputs vary, it decides where to save files differently each time, and it forgets rules you agreed on earlier. An agent with claude.md keeps the project's purpose, tech stack, folder structure, and working style consistent.

■B. How to Put the WAT Framework into claude.md

Let's look at how to put the WAT framework from Chapter 2 into claude.md. When you open the claude.md file, you see text in Markdown format. The content is divided into three main parts.

The first part is "What." It explains what this project is, what the tech stack is, and what the main components are. "This project works inside the WAT framework. There are three layers. The workflow is a Markdown instruction document, the agent is you, and the tools are Python scripts."

The second part is "Why." It explains why each component exists. "When AI handles every step at once, accuracy drops sharply. If each step is separated into a modular tool, only the failed step can be rerun, which improves overall reliability."

The third part is "How." These are the behavior rules the agent should follow day to day. "Before creating a new tool, check the existing tools folder first. If an error occurs, read the log, identify the cause, edit the script, and update the workflow. Never write API keys directly in code. Store them in the .env file."

There is one more important item besides these three parts: File Structure guidance. It states where the agent should save files when it creates them. "Save workflow files in the /workflows folder, tool scripts in the /tools folder, and temporary files in the /temp folder. Keep API keys and passwords in the .env file." Without this guidance, the agent piles files chaotically in the project root, making it hard later to find what is where.

■C. Initializing a Project with the Slash Command /init

Writing claude.md yourself can feel burdensome. In that case, you can use the slash command built into Claude Code. Type /init in the chat window, and the agent scans the current project's folder structure and files, then automatically creates a suitable draft of claude.md.

Of course, the automatically generated draft is only a starting point. You still need to add items such as the detailed rules of the WAT framework, your own brand information, and preferences for specific API services. Even so, it is much easier than starting from a blank page.

Another method is to bring in a well-made claude.md template. claude.md templates for the WAT framework are shared in the community. Drag one into your project and edit it to fit your own project.

Whichever method you choose, remember that claude.md is a living document. It is not something you create once and never revisit. As the project moves forward, if you need a new rule or the agent repeats the same mistake, add that point to claude.md. If you tell the agent, "Put this rule into claude.md," the agent may update the file directly.

■D. A Routing Strategy When claude.md Gets Long

There is a paradox hidden in the value of claude.md. The more useful information it contains, the longer the file becomes. The longer the file becomes, the more tokens the agent spends in every conversation. We will cover tokens in detail in the next chapter, but for now remember this: the longer it is, the more it can cost and the more performance may drop.

In practice, it is recommended to keep claude.md within 200 lines. Then can you fit all project context into 200 lines? In most cases, no. Take the executive assistant project, which we cover in Part 6. If you include team information, priorities, OKRs (Objectives and Key Results), and project status, it can easily become hundreds of lines.

The answer is Routing. In claude.md, write only "where to find it," and keep the actual content in separate files. It works like an index card in a library. You do not write the entire book on the index card. You write the book title and shelf number. When needed, you go to that shelf and take out the book.

In claude.md, routing works like this: "If you need team information, refer to /context/team.md. Brand guidelines are in /brand-assets/guidelines.md. For email writing rules, read /rules/email-style.md." The agent does not normally read those files. It opens them only when a related request comes in. This keeps claude.md short, reduces token use in each conversation, and still leaves the needed information accessible.

There is a way to notice when routing is needed. If you keep adding the same type of information to claude.md, that is a sign to separate it into another file. Instead of putting "Write emails in this tone," "Send Slack messages in this format," and "Structure reports this way" all into claude.md, create /rules/communication.md and leave only one line in claude.md: "For communication rules, refer to /rules/communication.md."

The essence of claude.md in one sentence is this: it is a Table of Contents that tells the agent "who you are, what you do in this project, and where to look if you need more detailed information."

For this table of contents to do its job, you need to understand tokens, the units that the agent reads and processes. I said that a long claude.md consumes many tokens. What exactly is a token, why does it matter, and how do you manage it? That is the topic of the next chapter.

Chapter 6. Tokens, Context Windows, and Context Management

■A. What Is a Token: About 3 to 4 Characters, Around 75% of a Word

Orders are piling up in a restaurant kitchen. There is a limit to how many order slips the head chef can handle at the same time. If the counter can hold ten slips, the eleventh has to wait somewhere. And as order slips pile up, the chef's attention spreads thin, making it more likely that a detail from the fifth order, such as "no onions," gets missed.

The Claude Code agent has a similar physical limit. The key to understanding that limit is the Token.

People read text in letters and words. AI reads in tokens. A token is the smallest unit AI uses to process text. In English, one token is roughly 3 to 4 characters and about 75% of a word. The word "information" can be split into two or three tokens. Commas and periods each take up tokens. Spaces are included in tokens too.

For Korean, token efficiency is somewhat lower than for English. That is because one Hangul character often takes one or more tokens. It is useful to know that the same sentence can consume more tokens in Korean than in English.

Tokens matter for two reasons: cost and quality. Your subscription plan has a limit on the total number of tokens you can use within a given period. The more tokens you use, the faster you hit that limit. And as more tokens pile up in a single conversation, the agent's response quality drops. That is the topic of the next section.

■B. The Context Window Is Claude's Working Notepad

(1) The system prompt, tools, MCP servers, and conversation history all go inside it

The Context Window is the agent's working notepad. Think of it as the total amount of information the agent can see at once.

Many things are inside this notepad. First, claude.md, the system prompt, takes up space. Then come the list of tools the agent can use, information about MCP servers, which we cover in Chapter 16, and the contents of skills, which we cover in Chapter 17. The conversation history between you and the agent, the contents of files the agent has read, and the results of commands it has run are all recorded in this notepad.

(2) The standard 200K-token window

This notepad is not infinite. At the time of writing this book, the standard context window of Claude models is about 200,000 tokens. That is roughly 150,000 English words, or about 300 A4 pages. It is a large space, but in a complex project it fills faster than you might expect.

If you ask the agent to run a long workflow, exchange several rounds of conversation, read multiple files, and connect several MCP servers, you will see the context window fill more than halfway in no time.

■C. Context Rot: Quality Drops as Tokens Pile Up

(1) The "Lost in the Middle" phenomenon

Problems can occur even before the context window is full. This is the phenomenon called Context Rot.

To understand it, imagine reading a thick novel all at once. You clearly remember the names and relationships of the characters from the first 50 pages. The events in the last 50 pages also feel vivid. But what about the 200 pages in the middle? Your memory gets blurry. You mutter, "Right, this character did something here..." but the details do not come back.

A similar pattern appears in AI models. They can refer relatively accurately to information at the beginning of a conversation and information in the most recent part, but they are more likely to miss or distort information in the middle. This is called the "Lost in the Middle" phenomenon.

(2) The accuracy decline curve seen in all models

Context rot is not only a Claude problem. It appears in all large language models, including GPT. As tokens pile up, the agent's response accuracy follows a steadily falling curve. After a certain threshold, the decline becomes sharp.

The practical implication is clear. If the agent suddenly gives strange answers, ignores rules you agreed on earlier, or starts inventing information that does not exist, suspect context rot.

■D. Four Essential Commands: /context, /compact, /clear, /rewind

Slash commands are the tools for handling context rot. You only need to remember four.

/context shows the current token usage status. When you type this command in the chat window, it breaks down what percentage of the total context window is being used, how many tokens the system prompt takes, how much tools and MCP servers are consuming, and how large the conversation history is. It is like getting a health checkup at a hospital. You need to know where tokens are concentrated before you can decide what to do.

/compact compresses the conversation. The agent extracts only the key information from the conversation so far and discards the rest. If you were using 60% of 200,000 tokens, it may drop to 10 to 15% after compaction. Since key information is preserved, there should be little difference in the agent's behavior before and after compression.

/compact has a useful option. If you add "keep the information about website design" after /compact, the agent preserves information related to that topic first and cleans up the rest. You can compress the conversation while naming the important context.

/clear deletes the conversation completely. It returns the context window to a blank state. Use it when the work topic changes completely, or when context rot becomes so severe that the agent's answers are hard to trust. Running /clear does not delete project files such as workflows, tools, or claude.md. Only the conversation history disappears.

/rewind goes back to a specific earlier point in the conversation. If the agent edits code and the result gets worse, you can use /rewind to return to the state before the edit. It is similar to "Undo (Ctrl+Z)" in a word processor.

■E. Auto-compact and Advice for Beginners

Remembering these four commands every time and running them at the right moment can feel burdensome. Fortunately, Claude Code has a built-in Auto-compact feature. When the context window fills beyond a certain level, the agent automatically compresses the conversation. A message such as "context: 45% remaining until auto-compact" appears in the status bar at the bottom of the chat window, showing how much room is left.

When you first use Claude Code, you do not need to worry too much about context management. Auto-compact handles it for you. Still, if the agent suddenly starts acting strangely, get into the habit of checking token status with /context and using /compact or /clear when needed.

As you gain experience, you develop your own standards. Personal rules such as "Use /compact when context usage passes 60%" or "Always use /clear when the work topic changes." We will cover these practical tips in more detail in the hacking tips chapter in Part 8.

Now that we understand tokens and the context window, one issue remains: choosing the agent's brain itself. There is more than one model available in Claude Code. A fast but light model, a balanced model, and a heavier model that thinks more deeply. You need a strategy for choosing the right model for the situation.

Chapter 7. Model Selection Strategy

■A. The Character of the Three Model Families: Haiku, Sonnet, and Opus

Think about choosing a car. For commuting in the city, a fuel-efficient compact car fits well. For a family trip, you need a spacious SUV. To move household goods, you need a truck. None of the three is a bad car. The best choice changes with the purpose.

AI models available in Claude Code work the same way. Anthropic provides three model families: Haiku, Sonnet, and Opus. The numbers after the names, such as 3.5, 4, 4.5, and 4.6, indicate versions. Higher numbers mean newer versions with improved performance. It is like a newer model year in a car, where safety equipment and fuel efficiency improve.

Haiku is the compact car. It is the fastest, lightest, and uses the fewest tokens. It fits situations that need repetitive work, large-volume text processing, and quick responses rather than complex reasoning.

Sonnet is the midsize sedan. It balances speed and reasoning ability. It performs well enough for most tasks, such as everyday coding, workflow building, and data analysis. Its price-to-performance ratio is strong, so it is the safest general-purpose choice.

Opus is the large SUV. It is the slowest, but it thinks most deeply. It is strong at complex architecture decisions, debugging that requires multi-step reasoning, and strategic judgments that require subtle context. It consumes the most tokens, so it also reaches the limit faster.

■B. Use Sonnet for 80%, Switch to Opus for Complex Architecture Judgments, Then Return to Sonnet

Which of the three models should you use by default? A strategy proven in practice is "Sonnet as the main model, Opus as support."

Handle about 80% of daily work with Sonnet: writing workflow files, creating tools, running tests, making small edits. In all these processes, Sonnet is fast and accurate enough.

For the remaining 20%, switch to Opus at moments that require complex judgment. When you need to design the overall architecture of a project, track a tricky bug involving several tools, or find the best compromise between conflicting requirements. In these situations, Opus's deeper reasoning makes the difference.

Once the judgment is done, return to Sonnet. Opus designs the structure, and Sonnet implements it. That is the division of labor.

Haiku shines when assigned to sub-agents, which we cover in Chapter 23. The main agent can make strategic judgments with Sonnet or Opus, while lower-level tasks such as repetitive data processing are given to Haiku. This can greatly reduce token cost.

At the beginning, you do not need to think about this strategy. Just use the default setting, whether Sonnet or Opus. It is not too late to apply a model-switching strategy once the project becomes complex and token management starts to matter.

■C. Switching Models in the Middle of a Session with /model

Switching models is not difficult. Type /model in the chat window, and a popup shows the list of models you can choose. Click Default, Sonnet, Haiku, or Opus, and the switch happens immediately. You can change it at any point during the conversation.

For example, suppose you are building a workflow with Sonnet and feel that the agent made a wrong judgment about the project structure. Switch to Opus with /model and ask, "Review the entire structure of this project again." After revising the structure based on Opus's deeper analysis, return to Sonnet and continue the detailed implementation.

■D. Assign Haiku to Sub-agents to Reduce Token Cost

We will cover sub-agents properly in Part 7, but because this connects directly to model selection, let me point out the key idea first.

A Sub-agent is a separate agent to which the main agent delegates a specific lower-level task. If the main agent asks a sub-agent, "Organize this data," the sub-agent works independently inside its own context window and returns the result.

Assigning Haiku to that sub-agent sharply reduces token cost. Tasks such as data cleanup, basic conversion, and repeated searches do not need deep reasoning. Fast and inexpensive Haiku is a good fit.

Put it this way: Opus is the architect, Sonnet is the site manager, and Haiku is the worker. The architect does not need to carry bricks every time, and the worker should not be asked to design the entire building. Giving each one the work it does well is how an efficient team operates.

Now that we have chosen a model, let's look over the tools the agent actually uses. When the agent reads files, runs terminal commands, and brings in data from the web, what built-in tools are working inside? You do not need to memorize their names. It is enough to recognize them in the flow and think, "Ah, this is that thing."

Chapter 8. Understanding Built-in Tools

■A. Read, Write, Edit: The Basics of File Handling

Think about how you handle documents in an office. You take a file out of a cabinet and read it. You create a new document and put it in. You edit part of an existing document. The Claude Code agent also has basic actions for handling files: Read, Write, and Edit. They correspond to reading a file, creating a file, and editing a file.

When the agent reads claude.md, the Read tool operates. When it creates a new workflow file, the Write tool operates. When it changes one line in an existing tool script, the Edit tool operates. When these actions happen in the agent chat window, you see messages such as "Read file: claude.md" or "Write file: tools/scrape_website.py."

You do not need to call these tools yourself. The agent automatically chooses them for the situation. You only need to notice, when you see these labels in the chat window, "Ah, the agent is reading a file now" or "It is creating a new file."

■B. Bash, Glob, Grep, LS: Terminal Commands and File Search

Let's continue the office analogy. To find a specific document in a cabinet, you have to open drawers one by one. If there are many documents, you look at labels. Sometimes you need to search by a phrase inside the document.

Bash is the tool the agent uses to run terminal commands. A terminal is a window where you give text commands to the computer. The agent uses Bash when it runs a Python script, installs a package, or tests an API. If you see a message such as "Bash: pip install requests" in the chat window, it means the agent is installing a software package in the terminal.

Glob is a tool that finds multiple files at once by file name pattern. It is used for tasks such as "Find every file ending in .py inside the tools folder."

Grep is a tool that searches for specific text inside file contents. A task might be, "Find every line containing the string 'API_KEY' in all Python files."

LS is a tool that lists which files are inside a specific folder. It is like opening a drawer and glancing at what is inside.

You do not need to memorize the names of these four tools. When the agent shows these names in the chat window, it is enough to understand roughly, "It is searching for files" or "It is running a command."

■C. WebFetch, WebSearch: Bringing in External Data

If the agent could handle only files inside your computer, its range of use would be limited. WebFetch and WebSearch are tools that let the agent bring information from the internet.

WebFetch reads the contents of a specific URL. If you ask the agent, "Summarize this webpage," WebFetch brings the text from that page and passes it to the agent.

WebSearch finds information through a search engine. If you ask the agent, "Find the 2025 market size for agentic AI," WebSearch brings relevant search results.

In the newsletter automation, the research step that used the Perplexity API is an example of this WebSearch family of tools. It is the process where the agent accesses external data sources and pulls current information into the project.

■D. How to Learn the Tool Names Naturally in the Flow Without Memorizing Them

The built-in tools introduced in this chapter are Read, Write, Edit, Bash, Glob, Grep, LS, WebFetch, and WebSearch. Nine tools in all.

Do not try to memorize all nine right now. Instead, pay attention to the tool names that appear in the chat window as you use Claude Code. If you see "Bash: python tools/research.py," read it as "The agent is running a Python script with the Bash tool." If you see "Glob: tools/*.py," read it as "It is looking for Python files in the tools folder."

The habit of watching the agent's behavior is the fastest path to technical understanding. As you read what the agent thinks, which tool it chooses, and which command it runs, the role of each tool naturally becomes familiar. If an unfamiliar tool name appears, just ask the agent. Type "What was that Glob you just ran?" and the agent will explain it kindly.

This concludes Part 2. You installed VS Code, connected Claude Code, gave the agent project context through claude.md, understood the principles of tokens and the context window, learned a model selection strategy, and became aware of built-in tools. You now have the basic fitness for agentic systems.

In Part 3, we build practical projects on top of this foundation. We will review slash commands as a whole, learn the design principles of project folders, and meet powerful tools called RAG (Retrieval-Augmented Generation) and vector databases. The process where an agent searches thousands of external documents and finds an accurate answer. Once you see what kind of mechanism is hidden there, your view of agentic systems will widen by one level.

Chapter 9. Complete Guide to Built-in Commands

■A. /init: Project Initialization

On the first day of a new semester, the homeroom teacher writes the semester timetable on the board: textbook list, supplies, class rules. Students need this information to know what to bring starting tomorrow. The /init command is the "first-day orientation" of a Claude Code project.

When you type /init in the chat window, the agent scans the structure and files of the current folder. Then it automatically creates a draft claude.md suited to the project. If you run it in a folder that already contains code, the agent identifies the language, framework, and dependency packages of the existing code and reflects them in claude.md. If you run it in an empty folder, it suggests a basic project structure.

As emphasized in Chapter 5, the claude.md created by /init is only a starting point. Project-specific context, such as detailed WAT framework rules or brand information, must be added directly. Even so, it gets you onto the track much faster than starting from a blank state.

■B. /model: Model Switching

This command performs the model switching covered in Chapter 7. Type /model, and a popup shows the list of models you can choose. Click Default, Sonnet, Haiku, or Opus, and the switch happens immediately.

The key point is that you can change it at any time during the conversation. While building a workflow with Sonnet, switch to Opus with /model when an architecture judgment is needed. When the judgment is done, return to Sonnet. Because model switching happens inside the same session while preserving conversation context, you do not need to explain the previous conversation again.

■C. /doctor, /status: Environment Diagnosis and Status Check

/doctor diagnoses the Claude Code installation environment. It checks whether the extension is installed correctly, whether authentication is valid, and whether required dependencies are in place. If you have just set up a new computer, or if Claude Code behaves differently from what you expected, this is the first command to run. It is like a health checkup. If it finds a problem, it tells you both the cause and the fix.

/status shows basic information about the current session. The Claude Code version, model in use, connected account, subscription plan information, and more appear at a glance. When you wonder, "Which model am I using right now?" you can check with /status instead of opening the switching screen with /model.

■D. /context, /compact, /clear, /rewind: Context Management Tools

These are the four commands covered in detail in Chapter 6. Even if there is some repetition, this chapter organizes them again around practical usage scenarios.

Running /context shows token usage by item. You can see the share taken by the system prompt, the tokens consumed by MCP servers and skills, and the accumulated conversation history. When you wonder, "Why am I reaching the limit so quickly?" /context points to the cause. For example, if you have connected three MCP servers but actually use only one of them, you can disconnect the unused servers and save tokens.

/compact compresses the conversation. In practice, the most common time to use it is when context usage passes 60%. In Chapter 6, I explained that you can name topics to preserve during compression, such as "keep the information related to website design." This feature is useful when topics are mixed in the middle of work.

/clear deletes the conversation completely. Use it when the work topic changes. For example, when you have been building a newsletter workflow and now move on to a competitor analysis workflow, it prevents leftover context from the previous conversation from contaminating the new task.

/rewind returns the conversation to an earlier point. If the agent edits code and the result gets worse, use /rewind to restore the state before the edit.

■E. Other Slash Commands

Besides the core commands above, there are other useful commands to know.

/help shows the full list of available slash commands. When you cannot remember which commands exist, /help is enough.

/cost shows the token usage and cost of the current session. It helps manage subscription limits.

/memory edits the agent's Auto Memory file. If you tell the agent, "Always use pnpm," the agent saves that preference in global memory. You can use /memory to check or edit what has been saved.

/permissions manages the agent's permission settings. It controls which commands can run automatically and which commands require user approval. Chapter 28 covers permission settings in detail.

/mcp manages connected MCP servers. You can add servers, remove servers, and check their status. We will look at it in earnest in Chapter 16.

/agents creates and manages subagents. We will practice this in the subagents chapter, Chapter 23.

You do not need to memorize all these commands. If you remember only /help, you can find the rest at any time. As you use Claude Code, the commands you need will naturally become familiar. If you forget a command, you can say in plain language, "Show me token usage," and the agent will run /context on its own.

Now that you know how to control the agent with slash commands, we move on to designing the workspace where the agent works. The way you organize the project folder makes a big difference in the agent's efficiency.

Chapter 10. Project Folder Architecture

■A. Three-Level Settings Hierarchy

Think about living in an apartment. There are management rules that apply to the whole apartment complex: recycling days, parking rules, hours for shared facilities. On top of that, each building may have its own detailed rules. And inside your own unit, your own household rules apply: when you run the dishwasher, what day you vacuum.

Claude Code settings have the same kind of hierarchy. There are three levels.

(1) Global (user) level: tilde (~) path, applied to every project

Global settings apply to every Claude Code project on your computer. They are located under the tilde (~) path in your home directory. If a path starts with the ~ symbol, it is a global setting.

Examples of what you store here include skills you want to use in every project, such as a frontend design skill; personal preferences such as "Always use pnpm"; and settings that always allow a certain MCP server.

(2) Project level: .claude/settings.json, shared team settings

Project-level settings live in the .claude directory inside that project folder. The settings.json file goes here. This file is shared by everyone who accesses the project. When a team works together, it ensures that all team members use the agent under the same rules.

(3) Local level: settings.local.json, personal overrides

Local settings are stored in the settings.local.json file inside the same .claude directory. Use this when you want to follow the project settings but override only certain items for your own environment.

■B. Settings Priority: Local Overrides Project, Project Overrides Global

What happens when the three levels of settings conflict? The priority is clear. Local is highest, then project, then global.

When the agent tries to perform an action, it checks the local settings first. If that action is allowed in the local settings, it runs it as is. If the local settings do not contain that item, it checks the project settings. If the project settings do not contain it either, it checks the global settings.

For example, suppose your global settings say "Always allow file reading (Read)." But if a certain project's settings.json says "Prohibit file reading," the agent cannot read files in that project. The project settings have overridden the global settings.

This hierarchy matters in real work because it balances security and convenience. You can keep permissions fairly open at the global level, then narrow them at the project level for projects that handle sensitive data.

■C. Practical Folder Structure Example: The Executive Assistant Project Directory

(1) The roles of the .claude, archives, brand-assets, projects, and skills folders

Theory alone does not quite land, so let us look at the folder structure of a real project. This is the directory for the Executive Assistant project we will build in Part 6 of this book.

At the top level, there is a .claude folder. Settings files (settings.json, settings.local.json), claude.md, rules, skills, and agents files all go inside it. This folder is the brain of the project.

The archives folder stores past outputs by date. Think previous analysis reports or last week's newsletter archive.

The brand-assets folder contains logos, brand guidelines, and color palette files.

The projects folder manages current subprojects in separate subfolders.

The skills folder contains local skill files used only in this project. They are separate from global skills.

At the project root, you place claude.md, claude.local.md, .env, and .gitignore.

(2) Excluding sensitive files with .gitignore settings

One file you cannot leave out of the folder structure is .gitignore. This file is a list that tells Git, covered in detail in Chapters 15 and 30, "Never upload these files."

You register things like the .env file, which stores API keys and passwords, OAuth authentication token files, and personal settings files in .gitignore. That way, even if you upload the project to GitHub, sensitive information is not exposed.

In VS Code's file explorer, files listed in .gitignore appear in gray. This visual cue lets you see at a glance that "this file will not be public." By contrast, files shown in green are new files not yet registered in Git, and yellow files have been modified. Once you get used to this color system, you can understand the current state of a project just by scanning the explorer.

Now that you know how to frame a project's skeleton, we move on to a powerful technique for bringing external knowledge into an agent. This is the structure where the agent searches for information not found in its training data, such as your company's internal documents or product manuals, and finds accurate answers. This is RAG, Retrieval-Augmented Generation, and behind it sits a technology called a vector database.

Chapter 11. RAG and Vector Databases

■A. The Concept of RAG (Retrieval-Augmented Generation)

Suppose you ask a librarian, "Please tell me how to clean the filter on the latest cordless vacuum cleaner." With only the librarian's own knowledge, it is hard to answer the exact filter replacement procedure for a specific product. But if the librarian pulls the product manual from the shelf and opens the relevant page, they can give an accurate answer. The librarian's expertise, the ability to answer, has been combined with the materials on the shelf, the external information.

RAG (Retrieval-Augmented Generation) is exactly this process. An AI agent "retrieves" information from outside when it is not in its own training data, "augments" the answer, and then "generates" the final response.

(1) The flow of splitting documents into chunks and vectorizing them with an embedding model

For RAG to work, external information must be prepared in advance in a form that AI can search. This process is called embedding.

Suppose there is a 68-page PDF manual for a cordless vacuum cleaner. If you hand the entire document to the AI, it takes up too much of the context window. So you divide the document into small pieces. These pieces are called chunks. One chunk is about one paragraph, or perhaps half a page.

When each chunk passes through an embedding model, the text is converted into an array of numbers, a vector. A vector is a mathematical expression of that text's "meaning." A chunk about "how to clean the filter" and a chunk about "battery charging time" are converted into vectors at different positions, because their meanings are different.

These converted vectors are stored in a vector database. Pinecone is a representative vector database service.

(2) How a user question is converted into a vector to retrieve similar chunks

When the user asks, "How do I clean the filter?" that question also passes through the same embedding model and is converted into a vector. The vector database finds the chunk vectors closest to the question vector, that is, the ones with similar meaning. Chunks containing "filter cleaning procedure" or "filter replacement cycle" rise to the top.

The AI agent receives these retrieved chunks and uses its language ability to compose a natural answer. It is based on the information in the original document, but reorganized to fit the user's question.

The whole flow is: document -> chunk splitting -> embedding (vector conversion) -> vector database storage -> user question -> question vector conversion -> similar chunk retrieval -> AI generates the answer. This is the RAG pipeline.

■B. Google Gemini Embedding 2: The First Native Multimodal Embedding

(1) Putting text, images, video, and audio into one vector space

Traditional embedding models could handle only text. To search images, you had to write a separate text description of each image and embed that. Video and audio were even more complicated.

Google's Gemini Embedding 2 breaks through this limit. It is the first native multimodal embedding model that can place text, images, video, and audio together in one vector space.

To explain what this means, let us use an experiment where a photo of smile-shaped potato fries, a video of a dog playing guitar, and a text file explaining how to use Claude Code are all embedded together. If we visualize the embedding results in two-dimensional space, the fries photo lands near the "food" category, the dog video near "entertainment," and the technical document near "tech." Data in different formats, image, video, and text, are organized in the same space according to meaning.

(2) Roof repair company case: finding similar past projects from one photo

There is a case that shows the practical value of this technology. A roof repair company stored 13 photos from past projects in a vector database. Each photo also included metadata such as cost, time required, and number of people assigned.

A new customer sends one photo of their roof. If you convert that photo into a vector and search the database, the five most similar past projects are returned with similarity scores. "A past project similar to this roof was a two-story house in Richmond, with this cost and a two-day timeline." Reference material is provided immediately when preparing an estimate.

Searching hundreds of past projects with one photo was an area that text search alone could not handle. Showing the photo directly is far more accurate than describing it in text as "find a project with a red tile roof and water stains."

■C. Pinecone Vector Database Integration Demo

(1) Putting images, video, and text into the data folder

How complicated would it be to build all of this yourself? Here is how one AI automation consultant in the United States built a multimodal RAG system with Claude Code.

Open an empty project in VS Code and tell Claude Code, "I want to create a Pinecone vector database using Google's new embedding model. Make it so I can put in images, video, and text. When that is done, build a chat web app too." The agent creates a plan and adds placeholders for the required API keys, Gemini, Pinecone, and the chat model, in the .env file. Paste in the API keys, drag files into the data folder, and setup is complete.

The agent automatically detects file formats. It classifies PNG as images, MP4 as video, and TXT as text. It passes each file through the Gemini embedding model, converts it into a vector, and stores it in the Pinecone database.

Building this pipeline with traditional tools such as n8n takes hours to days. You need to configure processing nodes for each file type, design chunk-splitting logic, set up embedding API calls, and connect database storage nodes. With Claude Code, the same result came from a few plain-language sentences and three API keys.

(2) Demonstrating natural-language queries and image search in the web app

Once the data is stored, the agent launches a simple chat web app on localhost, a web server accessible only from your own computer.

Take the example of loading a cordless vacuum cleaner manual. In the chat app, type, "How do I clean the filter?" The system searches the Pinecone database and retrieves related text chunks and images. Along with the text answer, "Press this button to remove the filter," it also displays a diagram image showing the procedure. Click the image to view it at full size. Each result shows a confidence score, which helps you judge the accuracy of the search result.

When text explanation alone is not enough, the actual diagram or photo appears with it. That is the power of multimodal RAG.

RAG and vector databases are technologies that extend an agentic system's memory outward. They turn information not found in the agent's training data, your company documents, product photos, even training videos, into searchable knowledge.

This concludes Part 3. We learned how to initialize a project, design a folder structure, and connect external knowledge. The agent's abilities keep expanding. In Part 4, we turn those abilities into visible outputs: cloning websites, building apps, and deploying them to the world through GitHub and Vercel. The moment is coming when other people can actually visit and use what you created.

Chapter 12. Website Cloning and Customization

■A. Giving a Reference Site URL and Instructing Claude Code to Clone It

Suppose you walk into a real estate office. You can explain in words, "I want a house like this," or you can show one photo on your smartphone and say, "A house with this kind of feel." Which one gets you closer to the result you want faster? The process of creating a website is no different.

You could tell Claude Code, "Make me a modern, clean landing page." The agent will create something based on its own standards for "modern" and "clean." But there is usually a gap between the image in your head and the agent's interpretation. It takes several rounds of revision to reach the result you want.

There is a faster way. Find a website you like and give its URL to Claude Code. "Clone this site." The agent visits the site, understands its structure, analyzes the layout and color system, then recreates a website with a similar look in code.

Cloning does not mean copying the original exactly. Copyrighted images, text, and logos are not included. What gets recreated are design patterns such as layout structure, color placement, typography style, and section arrangement. Add your own brand assets and content on top, and you get a completely original website while keeping the polished feel of the reference site.

There are many websites where you can find inspiration. Search by industry or style in design galleries such as Dribbble, Godly.website, and Awwwards, and you can quickly find sites worth using as references.

The exercise is straightforward. Open the reference site in a browser and press F12, on Windows, to open developer tools. In the Console, press Ctrl+Shift+P and search for "screenshot" to capture a full-page screenshot. Copy style information from the Styles section of developer tools as well. If you pass both of these, the full screenshot and the style code, to Claude Code, the agent reproduces the reference site's structure and style much more accurately.

■B. Screenshot Loop: Claude Code Writes Code and Compares Its Own Result

When you ask for a clone, the agent begins writing code. But the agent does not just write code. It checks for itself how the code actually renders.

This process is the screenshot loop. After the agent writes the website code, it uses Puppeteer, a tool that controls a web browser with code, to take a screenshot of the page it created. Then it compares that screenshot with the screenshot of the reference site. It finds places where colors differ, layouts are misaligned, or elements are missing. When it finds differences, it edits the code, takes another screenshot, and compares again.

(1) At least two rounds of comparison

This comparison process repeats at least twice. The first round fixes major structural differences. The second round refines detailed colors, spacing, and font sizes. You will see comparison images accumulating one by one in the temporary screenshots folder in the left explorer.

(2) Specifying screenshot file naming rules in claude.md

When you use the screenshot loop, temporary files pile up quickly. If they have meaningless names such as screenshot_1.png and screenshot_2.png, it becomes hard to tell which one is the reference site and which one is the clone result. Add a naming rule to claude.md such as "Use the ref_ prefix for reference screenshots and the clone_ prefix for clone screenshots," and file management becomes easier.

■C. Knowing When to Turn Off the Screenshot Loop for Dynamic Animations

The screenshot loop has one trap. When you clone an element with background animation, such as a flowing gradient or floating particle effect, the screenshot captures only one frame of the animation. The agent may look at that still image, decide "it still differs from the original," and fall into a bad cycle of repeated edits. It is comparing motion against a still image, so it can never match forever.

In this situation, you need to tell the agent explicitly: "This is an animation, so do not do screenshot comparison. Just write the code, and I will check it directly in the browser." That one sentence saves dozens of unnecessary loops.

■D. Applying Brand Assets (Colors, Logos, Photos) on Top of the Clone

Once the clone is complete, it is time to keep the reference site's colors and layout while applying your brand identity.

The brand_assets folder used in Chapter 3 contains your logo and brand guidelines. Tell the agent, "Apply our brand to this clone. The logo is @AIS.png, and the guidelines are @brand-guidelines.png." The agent replaces the reference site's colors with your brand colors, inserts the logo, and changes the typeface. It also rewrites the text to fit your business.

If you cloned a French site, translation into Korean happens automatically as well. One sentence is enough: "Change the whole thing to Korean."

Cloning and customization have now framed the overall website. But what if the background of the hero section, the first-impression area at the top of the website, feels a little plain? What if you want an eye-catching effect on a specific button? You do not need to rebuild the whole site. You can take inspiration at the individual component level and replace only that part.

Chapter 13. Improving Individual Elements with 21st.dev Components

■A. What Is 21st.dev: A High-Quality Web Component Library

When doing interior design, you can change the mood without rebuilding the whole house. Replacing the living room light with indirect lighting, changing the front door handle to brass, or adding blinds by the window can change the impression of a space. A website is the same.

21st.dev is a library that collects high-quality web components. A component means an individual part that makes up a website. One button, one background animation, and one navigation bar are each components. 21st.dev contains hundreds of components, including buttons with flowing rainbow borders, wave-like background effects, highlights that respond to mouse movement, and shader backgrounds.

■B. Taking Inspiration at the Individual Component Level, Not the Whole Site

The key strategy for using 21st.dev is that you do not take the entire site from this library. The overall structure has already been set through cloning or direct building. What you take from 21st.dev is a polished expression for a specific part.

For example, if the background of the hero section feels monotonous, browse the "backgrounds" category on 21st.dev. If you like a wavy blue gradient, copy that component's prompt, the code snippet provided by 21st.dev.

■C. Inserting a Specific Component, Such as an Animated Background, into an Existing Site

Paste the copied prompt into the Claude Code chat and say, "Put this background element behind the hero text. And because this is an animation, do not compare screenshots. Just write the code and I will check it."

The agent analyzes the existing website's HTML structure and inserts the 21st.dev component code into the background layer of the hero section. Check the result on localhost. If the background animation covers the text and makes it hard to read, give feedback: "Put a translucent background behind the text." If a button glow effect is too distracting, say, "Make the glow a bit subtler."

This process takes only a few minutes. You are not rebuilding the whole site. You are replacing one Lego block.

Now that we have refined individual components, let us look beyond websites. A website stops at showing information, but a web app interacts with the user. A chat interface where you talk with an AI fitness coach, and workout records level up like a game. Claude Code can build these kinds of dynamic applications too.

Chapter 14. Live Build of a Fitness Coach AI Web App

■A. Designing Features in Plan Mode: Chat Interface and Gamification Tracker

It is Saturday morning. You want to exercise, but you do not know what to do today. A trainer at the gym would be nice, but a personal trainer is expensive. Open a web browser and ask an AI fitness coach: "Create a 30-minute high-intensity interval training routine." The coach presents a step-by-step routine from warm-up to cool-down. Each conversation adds points, and when you reach a certain number of points, your level goes up. Exercise habits form as if you are playing a game.

We will build this web app from start to finish with Claude Code.

Start in Plan Mode. Type this into the chat window.

"I have a fitness coach workflow in n8n. I want to turn it into a web app. I want the main screen to have a chat interface, with a gamification tracker on the right. Make it dark mode and minimal. Use the frontend design skill to make it professional."

The agent asks questions. "Which features should be core? Please choose among general fitness Q&A, personalized workout plans, and progress tracking." "Should gamification level up based on message count?" "Where should user data, such as level and message count, be stored?"

As you exchange answers, the specification is finalized.

■B. Finalizing the Specification by Answering Claude Code's Questions

What you do in this process is decision-making. Not coding. If you make decisions such as "Put everything in," "Let's start with message count only," or "I will decide data storage later. Use local storage for now," the agent handles the rest.

Once all questions are answered, the agent presents a combined plan. It includes the app name, color system, tech stack, feature list, and implementation steps. If you like the plan, say, "Good, build it."

■C. The Repeated Cycle of Build, Screenshot Verification, and Revision

Switch to bypass permissions mode. The agent creates a todo list and begins handling the items one by one. It writes the HTML structure, styles it with CSS, and implements the chat features and gamification logic with JavaScript. The frontend design skill is called automatically to raise the design quality of the code.

A few minutes later, the agent gives you a localhost address. Open it in the browser.

A chat interface appears on a dark-mode background. The conversation window is on the left, and level and point status appear on the right. Try sending a message: "Create a 30-minute HIIT routine." The backend workflow runs, and a few seconds later the coach's response comes back. But bold markdown and bullet marks appear as raw markdown in the response, which does not look good.

Go back to Claude Code. "The response is coming out in markdown format. Fix it so it appears only as plain text." The agent edits the frontend code. Check again. This time it is clean. But the gamification points are not increasing. "I sent a message, but the points are not going up. Fix it." The agent finds and fixes an error in the local storage logic.

This build-check-revise cycle is the core rhythm of building a web app. The result does not come out perfect in one try. But because each cycle runs in minutes, you can get a fairly polished app in 30 minutes to an hour.

■D. Five Hack Tips to Prevent AI Vibe Coding

The slang term vibe coding refers to the impression that a website or app made with Claude Code "looks AI-made." Uniform layouts, flat colors, and lifeless typography are its traits. Here are five ways to prevent it.

The starting point is to state design principles in claude.md. "Always call the frontend design skill first. No exceptions." That one line raises the design quality of the result.

When the frontend design skill is installed, the agent reads and applies design principles before writing code. Animation, spacing, color contrast, and typography hierarchy are implemented at the level of a professional designer.

Use the screenshot loop so the agent visually checks and improves its own output.

Provide a reference site to give a visual reference point for "this kind of feel."

Finish by bringing in individual elements from a component library such as 21st.dev.

When all five are applied, the quality of the result changes enough to feel it, even with the same prompt.

The web app now works satisfactorily on localhost. It is time to put it into the world. Deploying it to a real web address that anyone can visit even when your computer is turned off, that is the topic of the next chapter.

Chapter 15. Live Deployment with GitHub and Vercel

■A. Creating a GitHub Account and Connecting Claude Code

Everything you have created so far, whether a landing page or a fitness coach app, exists only inside your computer. A localhost address can be accessed only from your device. If you send that address to a friend, they will see only a blank screen.

To put a website into the world, you need to upload the code to the cloud. The first step is GitHub.

GitHub is a platform for storing code and managing versions. Just as Google Drive stores documents, GitHub stores code. The difference is that GitHub tracks every change history. It records when, who, and which line changed. If a bad edit happens, you can return to an earlier version.

Creating a GitHub account is free. Register an email and password at github.com. After creating the account, go to Settings -> Developer Settings -> Personal Access Token and create a token. This token is the key that lets Claude Code upload code to your GitHub account.

Save the token in the .env file. Tell Claude Code, "Connect to GitHub," and the agent will guide you through authentication. The GitHub login screen opens in the browser, and once you approve it, the connection is complete.

■B. Pushing the Codebase to a GitHub Repository

Once the connection is complete, tell the agent, "Upload this project to GitHub. Make the repository name fit-coach-ai-app."

The agent creates a new repository on GitHub and uploads every file in the project. This process is called a push.

(1) How to exclude sensitive information, such as API keys, from commits

Before pushing, there is something you must check: whether the .env file is listed in .gitignore. If a file containing API keys, OAuth tokens, or passwords is uploaded to GitHub, anyone can see it. In a public repository, anyone in the world can access it. Even in a private repository, everyone with permission can access it.

Build the habit of asking the agent, "Run a security check before pushing. Make sure sensitive information is not included in the commit." The agent scans the code and checks whether any API keys are exposed.

(2) Public vs. private repository settings

When creating a repository, choose Public or Private. A demo for learning can safely be public, but for client projects or commercial websites, private is recommended. A private repository has no issue connecting to Vercel.

■C. Importing the Repository from the Vercel Dashboard and One-Click Deployment

The code is now on GitHub. Now you need a service that converts this code into an actual website. That service is Vercel.

When you create a Vercel account, log in with your GitHub account and the integration happens automatically. In the Vercel dashboard, click "Add New Project," and your list of GitHub repositories appears. Select the fit-coach-ai-app you just created, click "Import," then click "Deploy."

After a few dozen seconds, Vercel shows a deployment complete message. An address such as fit-coach-ai-app.vercel.app is created. Enter that address in a browser, and the fitness coach app you were building locally runs publicly on the web. You can access it from a smartphone too.

Environment variables, such as API keys, are registered separately in the Vercel dashboard under Settings -> Environment Variables. You did not upload them to GitHub, but Vercel needs this information when it runs the code.

■D. Live Update Pipeline: Edit Code, Push, and Automatically Redeploy

Even after deployment, edits come up. You may want to change a button color, add a new section, or fix a typo. You do not need to go to Vercel and redeploy every time.

The pipeline works like this. Edit the code in Claude Code. Check the changes on localhost. If you are satisfied, say, "Push to GitHub." A new commit goes up to GitHub. Vercel automatically detects the GitHub change and reflects it on the live website within 20 to 30 seconds.

To sum up this flow: Claude Code (development) -> localhost (testing) -> GitHub (storage) -> Vercel (deployment). The four steps connect smoothly.

There is one thing to watch. If you push changes to GitHub before testing them enough on localhost, defective code will be reflected on the live website right away. It is safer to write in claude.md, telling Claude Code, "Test on localhost first, and do not push to GitHub until I explicitly tell you to." The principle of pre-deployment testing is the same as the train-track analogy in Chapter 1. You run battle tests under many scenarios before actual operation.

This concludes Part 4. We cloned a reference site, refined components, built an AI web app, and deployed it to the world. Now that the website and app are out in the world, it is time to broaden the reach of the agent's hands. The ability to send email, read calendars, fetch files from Google Drive, and scrape data from the web. MCP servers that open the doors of external services to the agent, skills as reusable instruction manuals, and deployment techniques that put workflows in the cloud for 24-hour automated execution. All of this unfolds in Part 5.

Chapter 16 MCP (Model Context Protocol) Servers

■A. The Concept of MCP: A Framework That Gives Agents Access to a Supermarket

A chef making a cake has a kitchen, a recipe, a knife, and an oven. But there are no ingredients. If there are no eggs, flour, sugar, or butter in the refrigerator, the chef cannot bake a cake no matter how skilled they are. What if you gave the chef a pass to the supermarket? Whenever ingredients are needed, the chef goes to the supermarket and picks them out directly. The chef decides how many eggs are needed and which brand of flour to use.

MCP (Model Context Protocol) is exactly that supermarket pass.

Until now, the Claude Code agent had only built-in tools for reading and writing files on your computer. Powerful, yes, but the agent's world was limited to the local file system. When you connect an MCP server, that boundary disappears. The agent can read email in Gmail, schedule events in Google Calendar, fetch documents from Google Drive, and scrape data from websites.

The key to understanding MCP is "one connection, many functions." Take Gmail as an example. There are many actions, such as sending email, reading email, searching email, applying labels, and creating drafts. To use these functions without MCP, you would have to set up a separate API (Application Programming Interface, the communication rules between software) endpoint for each action, configure authentication, and match the request format. When you connect an MCP server, the agent can access all of these actions at once. The agent decides which endpoint to call and which parameters to provide based on the situation.

Continuing the supermarket analogy, instead of visiting separate egg, flour, and sugar shops, you get every ingredient from one supermarket.

■B. Installing the FireCrawl MCP Server and Practicing Web Scraping

For the first practice of connecting an MCP server, we use Firecrawl. Firecrawl is a service that extracts data from websites. It provides several tools through one MCP server, including scraping (fetching page content), crawling (exploring an entire site), mapping (understanding site structure), and search (running a web search and extracting results).

The installation process is surprisingly easy. Copy the installation command for Claude Code from Firecrawl's official documentation. Paste it into the Claude Code chat window and say, "Install this MCP server. I will put the API key in .env, so read it from there." The agent handles the installation.

If you create a free account on the Firecrawl website, you receive 500 credits. Copy the API key from the dashboard, paste it into the .env file, and save it.

Once installation is finished, you can test it right away. If you say, "Bring me the content of this URL in Markdown," the agent calls the scraping tool on the Firecrawl MCP server and fetches the text of that page. The agent decides on its own which tool to use and what request format to send.

In the website clone covered in Part 4 and in the research stage of newsletter automation, this MCP server plays the role of fetching data. Once connected, it can be reused across multiple workflows.

■C. Connecting Service-Specific MCP Servers Such as Gmail, Calendar, and Drive

Firecrawl is an MCP server for web data. To access Google services, you need separate MCP servers. There are Gmail MCP servers, Google Calendar MCP servers, and Google Drive MCP servers. There is also a GitHub MCP server, so the agent can directly handle the code push covered in Chapter 15.

The way you connect each service's MCP server is the same as with Firecrawl. Get the installation command from the official documentation, store the API key or authentication information in .env, and instruct Claude Code to install it.

Information about connected MCP servers is recorded in the MCP configuration file at the project root, such as mcp.json. Because this file contains each server's URL and authentication information, you should register it in .gitignore so it is not uploaded to GitHub. The security principle emphasized in Chapter 15 applies here as well.

■D. The Token Cost MCP Servers Add to the Context Window

Connecting MCP servers is convenient, but it is not free. Remember the context window covered in Chapter 6. The list and descriptions of tools from connected MCP servers take up part of the context window. If one server provides dozens of tools, that list alone can consume thousands of tokens. If you connect three or four servers, a large part of the context window is filled with MCP information from the start.

The practical advice is this: keep connected only the MCP servers you actually need for the current task. A newsletter automation project rarely needs the GitHub MCP server. A competitor analysis project does not need the Google Calendar MCP server. If you check token usage with the /context command, you can see by category how many tokens MCP servers are consuming. If an unused server is eating tokens, it is wise to disconnect it.

If MCP servers open the doors of the outside world to the agent, skills are a way to give the agent specialized knowledge. If quality varies every time you repeat the same work, it is time to package that work as a skill.

Chapter 17 Skills: Reusable Natural-Language Instruction Manuals

■A. What a Skill Is: The Same Structure as a Workflow, Under a Different Name

Imagine repeating the same explanation to a new employee. If you are saying for the third time, "Use this font for the report cover, put the logo in the header, put the page number at the bottom center...", it is time to write that down as a document. Once you hand over the document, no further explanation is needed.

A skill is that document. Technically, a skill is a Markdown file. It has the same structure as the workflows you learned in Chapter 2. The goal, inputs, steps, outputs, and exception handling are described in natural language. The difference lies in its use. If a workflow is "the procedure for a specific task to run this time," a skill is "specialized knowledge and behavior rules used repeatedly."

The front-end design skill used in Part 4 is a good example. This skill file contains "design principles to follow when creating a modern website." Color contrast rules, typography hierarchy, spacing ratios, animation guidelines. Whenever a website-related request comes in, the agent reads and applies this skill.

■B. Installation Locations for Global Skills vs. Project Skills

The scope of a skill changes depending on where it is installed.

Global skills can be used in all of your Claude Code projects. Skills that are useful regardless of project, such as the front-end design skill, belong here. Global skills are stored under the .claude folder in the home directory, so they may not appear in the file explorer of a specific project.

Project skills are stored in the .claude/skills folder inside that project. They are used only in that project. Skills meaningful only for a specific project, such as a newsletter infographic generation skill, belong here.

Installing a skill usually takes one command. If you paste the installation command for a skill shared by the community into the Claude Code chat window, the agent handles it. If installing it yourself feels bothersome, just say, "Install this for me."

■C. How the Agent Dynamically Loads the Right Skill for the Task

The defining feature of how skills work is dynamic loading. The agent is not always reading every skill. When a request comes in, the agent scans the list of available skills. If there is a skill related to the current request, it reads and applies it then. Unrelated skills are ignored.

This matters because it saves tokens. If you put a skill directly into claude.md, that content occupies the context window in every conversation. If you separate it as a skill, it loads only when needed and does not consume tokens during ordinary work.

This is an extension of the routing strategy covered in Chapter 5. If you keep adding the same type of instruction to claude.md repeatedly, that is a signal to separate it into a skill.

■D. The Difference Between Skills and MCP: Instruction Manual or External Tool Connection

MCP and skills both expand an agent's abilities, but they expand them in different directions.

MCP gives the agent means of action. The ability to read email in Gmail, the ability to scrape a website with Firecrawl. It puts new tools in the agent's hands.

Skills give the agent standards for judgment. "Follow these design principles when building a website," "Use these brand colors when creating an infographic." They tell the agent not what to do, but how to do it.

As an analogy, MCP gives the chef a new knife, while a skill gives the chef a new recipe. Both are needed, but their roles differ.

Now that the agent can access external services (MCP) and has specialized knowledge (skills), it is time to put these abilities to work. There is a tool that handles every Google Workspace service through one interface.

Chapter 18 Google Workspace CLI (GWS CLI)

■A. What GWS CLI Is: Gmail, Drive, Docs, Sheets, and Calendar Through One Interface

Monday morning. You have to check 30 unread emails in Gmail, review today's schedule in Google Calendar, find meeting materials in Google Drive, and write a report in Google Docs. An hour passes as you switch among four tabs. What if these four services could be tied together into one command system?

GWS CLI (Google Workspace Command Line Interface) is that tool. This open-source CLI released by Google lets you operate Gmail, Drive, Docs, Sheets, Slides, and Calendar from one interface.

(1) More Than 100 Prebuilt Recipes

GWS CLI includes more than 100 prebuilt workflows called "recipes." A recipe that reads Sheets data and creates a report Doc, a recipe that finds open time slots and schedules a meeting, a recipe that sorts and archives email by label, a recipe that creates a document from a template. These recipes play a role similar to skills. They are a pattern library the agent can refer to when working with Google services.

(2) Agent-Friendly Structured Responses Based on JSON

GWS CLI responses are structured based on JSON (JavaScript Object Notation, a data exchange format). That means the format is easy for an AI agent to parse. Instead of receiving plain text saying, "There are three emails. The first one is...", the title, sender, date, and body of each email arrive in clearly separated fields. Because the agent can process this data directly, accuracy improves.

■B. Installation Process: Creating a Google Cloud Console Project and Setting Up OAuth

Installing GWS CLI is one step more complex than installing an MCP server. You need to create a project in Google Cloud Console, set up an OAuth (Open Authorization) consent screen, and generate a client ID.

It sounds complicated, but in practice, if you give Claude Code the GitHub address for GWS CLI and say, "Install this," the agent reads the documentation and guides you step by step. The parts you must do yourself are mostly clicking buttons in Google Cloud Console and putting the generated credential file into the specified folder.

When installation is complete, verify authentication. A Google login screen opens in the browser, and once you approve access, the connection is complete. After that, Claude Code can freely access Google services.

One point is worth knowing. At the time this book is being written, GWS CLI is an open-source beta, not an officially supported product. Stability is high, but some functions may change with version updates. When Google Workspace adds new API endpoints, GWS CLI reflects them automatically, so the tool itself continues to stay current.

■C. Practice: Automatically Classifying Gmail Email Priority

With GWS CLI connected, let us try a real-world use.

Tell Claude Code: "Fetch today's unread emails and score them from 1 to 10 according to my business priorities. Automatically mark emails below 5 as read."

The agent uses GWS CLI to fetch the list of unread emails from Gmail. It then refers to the business context, current project information, and team priorities recorded in claude.md, and scores each email. Advertising emails or newsletter subscriptions receive low scores, while emails from key clients or urgent internal requests receive high scores. Emails below 5 are automatically marked as read.

Check the result. The 30 emails are sorted in priority order. If you read only the top 5, your morning email triage is done. A task that used to take 20 minutes of opening 30 emails one by one is finished in under 5 minutes through the agent's judgment.

■D. How to Create Google Slides in the Actual Format, Not Markdown

When you create Google Docs or Slides through an API, a common problem is that Markdown text is output as-is. It is raw text without fonts, colors, or layout applied.

GWS CLI solves this problem. Because the CLI directly manipulates the native format of Google Slides, the presentation created by the agent has real fonts, colors, and images applied. Color codes extracted from brand guidelines are reflected in slide backgrounds and text, and logos are inserted at specified positions.

If you combine this with the screenshot loop learned in Part 4, the agent can create slides, capture the actual screen, verify the layout, and revise it in a loop. It opens Chrome DevTools, takes screenshots of the slides, and fixes the code when it finds misaligned margins or clipped text.

■E. Demo: Automatically Creating a YouTube Resource Guide

Here is another example showing how to use GWS CLI. Put a YouTube video URL into Claude Code and ask, "Create a resource guide for this video as a Google Doc."

The agent downloads the video's transcript. It extracts the key content and organizes it in a resource guide format. Then it creates a Google Doc using GWS CLI Bash commands. It is communicating directly with Google services through terminal commands, not API calls.

The result is a real Google Doc. A header image is inserted at the top, a YouTube channel link is included, and sections are divided by the video's main topics. At the bottom, a call to action and community links are placed. It is a finished, formatted document, not raw Markdown.

We have looked at how to connect to external services (MCP), how to package specialized knowledge (skills), and how to handle all of Google Workspace as one system (GWS CLI). If a workflow with all these abilities runs only inside your computer, that would be a shame. To have it run automatically every Monday morning, you need to put the workflow in the cloud.

Chapter 19 Deploying Workflows to the Cloud

■A. Deployment Principle: Upload Workflows and Tools, Not the Agent

Let us return to the principle emphasized in Chapter 1. When deploying, what goes to the cloud is not the agent. Only the workflow (W) and tools (T) go up. The agent (A) remains in your local environment.

This is an intentional design. Code that runs automatically in the cloud must be predictable. The same input should produce the same output. The agent's reasoning ability shines during the build phase, but after deployment, it is safer for the code produced by that reasoning to run deterministically.

If you want to improve the workflow after deployment, modify it in local Claude Code, test it, and deploy it again. By repeating this cycle, the workflow becomes sturdier.

■B. Modal Deployment

(1) What Modal Is: AI Infrastructure Charged Only When It Runs

Modal is a serverless AI infrastructure service. The word "serverless" can be confusing. It does not mean there are no servers; it means you do not have to manage servers yourself. If you upload code, Modal turns on a server only when needed, runs it, and turns it off when execution ends. Billing is based on execution time, so you are not charged while the code is not running.

When you create an account, you receive $5 in free credits, about KRW 6,800, and if you register a credit card, that increases to $30, about KRW 41,000. For a newsletter workflow that runs once a week, these credits can cover operation for a considerable period.

(2) Instructing Claude Code to "Push This Workflow to Modal"

The deployment process begins by giving Claude Code a natural-language instruction: "Upload this YouTube analysis workflow to Modal and make it run automatically every Monday at 6 a.m."

The agent makes a plan. It packages the workflow and tool scripts into a Modal deployment file, sets up a Cron schedule, and registers environment variables, such as API keys, as Modal secrets. Once you review and approve the plan, the agent executes it.

(3) Security Review: Checking Sensitive Keys Before Deployment

Before deployment, you must run a security check. Ask the agent, "Do a security review. Check whether API keys are exposed and whether webhooks have authentication." The agent scans the code and reports potential vulnerabilities.

If an API key is hardcoded in the code, it warns you. It tells you that the key should be moved to a Modal secret. If a webhook endpoint is open without authentication, it points out that anyone can send requests to it.

(4) Setting a Cron Schedule and Testing Immediate Execution

Check the deployed app in the Modal dashboard. In the schedule tab, you can see the Cron set to "every Monday at 6 a.m." You can test it with the run-now button. Check execution results and logs in real time from the dashboard.

If an error occurs during the test run, copy the error log and paste it into Claude Code. "This error happened in Modal. Find the cause." The agent diagnoses the cause, fixes the code, and deploys it again.

■C. Trigger.dev Deployment

(1) How It Differs from Modal: Strengths in Scheduling, Webhooks, Dashboard, and Logs

Trigger.dev plays a role similar to Modal, but it is more specialized for workflow automation. It provides scheduled execution (Cron), webhook triggers, automatic retries, queueing, and orchestration (coordination of multiple tasks) by default. In the dashboard, you can visually check each execution's step-by-step progress, duration, and success or failure.

If Modal is general-purpose AI infrastructure, Trigger.dev is an environment tailored to workflow operations. Failed executions are retried automatically, and retry intervals can be adjusted with delays, so workflow operations become more stable.

(2) Configuration That Connects the Trigger.dev Reference File to claude.md

To deploy with Trigger.dev, the agent must write TypeScript files. If you route Trigger.dev's API reference file, trigger-ref.md, in claude.md, the agent refers to this document when writing deployment code.

The deployment pipeline is similar to the GitHub-Vercel flow learned in Part 4. You write code in Claude Code and push it to GitHub; Trigger.dev automatically detects the GitHub changes and reflects them in the production environment.

(3) Comparing Webhook Triggers and Schedule Triggers

Schedule triggers run at fixed times, such as "every Monday at 8 a.m." They are suitable for repeated tasks such as sending newsletters, creating regular reports, and weekly competitor analysis.

Webhook triggers run in response to external events. When a website inquiry form is submitted, when a new task is added in ClickUp, when a customer completes payment. When these events send a signal to the webhook URL, Trigger.dev immediately runs the corresponding workflow.

In practice, the two types are often combined. When a customer inquiry comes in (webhook trigger), it is analyzed immediately, and every evening (schedule trigger), that day's inquiry status is generated as a consolidated report.

■D. The Workflow Update Cycle After Deployment

Deployment is not the end; it is a new beginning. As a workflow runs in the cloud, it may encounter unexpected data, an external API's response format may change, or new requirements may be added.

The update cycle works like this. Check the results that ran in the cloud, such as logs in the Modal or Trigger.dev dashboard. If a problem is found, modify the workflow or tools in local Claude Code. Test locally. Once satisfied, push to GitHub, and the cloud environment updates automatically.

The key point of this cycle is that the agent's self-healing ability works only during the local build phase. Code deployed to the cloud does not fix itself. When an error occurs, it leaves a log and stops. That is why battle testing before deployment matters. Remember the train-track analogy from Chapter 1. You run test operations with many trains before entering actual service.

This concludes Part 5. MCP servers let the agent's hands reach external services, skills packaged specialized knowledge, GWS CLI tied all of Google Workspace together, and Modal and Trigger.dev deployed workflows to the cloud so they could run automatically 24 hours a day.

In Part 6, we bring all of these abilities together in one project: an AI executive assistant. An agent that organizes your schedule every morning, prioritizes email, briefs you on team status, and proposes next actions for projects. Following the four-step build framework, the journey begins: building a house, giving it life, attaching hands, and letting it grow.

Chapter 20 The Four-Step Build Framework

■A. Step 1, Home: Setting Up VS Code, Creating Folders, and Writing claude.md

Tuesday, 9:15 a.m. There are 47 unread emails piled up in your inbox. Your calendar has two morning meetings and one afternoon call, and ClickUp has seven tasks due this week. Slack notifications are blinking in three channels at once. You pause for a few seconds, unsure where to start. It is the moment when decision fatigue eats into the day's most productive time.

Starting with this chapter and over the next three chapters, we build an AI executive assistant that will end this decision fatigue. It is an agent that combines your calendar and tasks every morning to plan the day, prioritizes email, briefs you on team project status, conducts research, and creates content. By running four agents in parallel at the same time, it can finish a 25-minute job in under 2 minutes.

The build happens in four steps: Home, Life, Hands, and Growth. If you follow this analogy, the whole process connects naturally.

The first step is building the house. You prepare the physical space where the agent will live.

Open VS Code and create a new folder. A name like "EA-project" is fine. When you open this folder in VS Code, an empty space appears in the left explorer. Open the Claude Code chat window on the right.

Tell the agent: "This folder is the space where you will work as my executive assistant. Set up a basic folder structure."

The agent creates folders: .claude (settings, rules, skills, agent files), context (information about me, work context, team information, current priorities), projects (subfolders for ongoing projects), decisions (important decision logs), archives (archives of past outputs), references (reference documents and SOPs), and templates (forms used repeatedly).

Write the claude.md file. At first, one paragraph is enough. "You are [name]'s executive assistant. You help with schedule management, task organization, research, and communication drafts." This file will evolve throughout the project, so you do not need to make it perfect.

The house has been built. It is an empty room with no furniture. In the next step, we give it life.

■B. Step 2, Life: Giving It Business Context

The first thing to do for the assistant that has moved into the house is onboarding. Remember the analogy in Chapter 5 about a new employee's first day. An employee who shows up without onboarding documents has to ask questions every time. The same is true of an agent.

(1) Team Information, Priorities, OKRs, and Project Status

The most effective way to give the agent your business context is an interview. Tell the agent, "Ask me what you need to know about me, our business, the team, and current priorities. Ask one question at a time."

The agent starts asking questions. "What is your name and role?" "What is the core service of the business?" "How many team members are there, and what roles do they each have?" "What is the top goal for this quarter?" "Tell me about the projects currently in progress."

You do not need perfectly organized sentences when answering. You can brain dump by voice input. The agent organizes what you say and saves it as structured files.

When the interview ends, the agent creates files in the context folder: me.md (information about you), work.md (business overview), team.md (team composition and roles), current-priorities.md (current priorities), and goals.md (quarterly goals). Each file organizes the information extracted from the interview in Markdown format.

Then claude.md is updated. The routing learned in Chapter 5 is applied. "When you need to know about me, read /context/me.md. For business information, refer to /context/work.md; for team information, refer to /context/team.md." This keeps claude.md short while allowing the agent to access the information it needs.

(2) Automating Code Management Through GitHub Integration

Putting a project that has its home and life on GitHub has several benefits. Backups happen automatically, and you can load this project and use the assistant from any device. Change history remains, so if the assistant's settings go wrong, you can return to an earlier version.

It is the same GitHub integration process learned in Chapter 15. If you say, "Put this project on GitHub," the agent handles it. Make sure the .env file is registered in .gitignore.

■C. Step 3, Hands: Creating Skills So It Can Perform Real Work

The house exists, and the agent understands the context, but it still cannot "do" anything. It can answer questions and give advice, but to send email directly, check calendars, or conduct research, it needs hands. These hands are skills.

The first hands to attach to the executive assistant are connections to project management tools, such as ClickUp, Notion, and Asana. If connected through an MCP server or API, the agent can read tasks, check status, and judge priorities.

Next comes a research skill. If you create a research skill connected to the Perplexity API, the agent searches the web, synthesizes information according to your business context, and writes reports. It is not a plain web search; it refers to the business information in me.md and work.md and analyzes even "what this means for our business."

The process of creating a skill is the same as what you learned in Chapter 17. In plan mode, request, "Create a research skill. Use Perplexity and have it write reports that reflect my business context." The agent creates and tests the skill file.

■D. Step 4, Growth: A Structure Where the Assistant Evolves Through Feedback and Repetition

The house exists, the agent understands the context, and hands have been attached. The fourth step is to make all of this improve over time.

The heart of growth is use. Use this assistant every day. Do here the work you used to do in Claude Web or ChatGPT. Bring prompts from custom GPTs and convert them into skills. Give feedback on the agent's output every time. "This part was good," "This is not my style; make it more concise," "Add this information to claude.md."

Even one focused week of use will leave research reports, content drafts, decision logs, and project notes inside the project. Because the agent can refer to these files, the context grows richer with use, and output quality rises. A month later, it will be an assistant at a completely different level from now.

The outline of the four-step framework is now in place. In the next chapter, we go deeper into claude.md context management, the core of the second step, "Life." What should you do when claude.md starts exceeding 100 lines? What should you do if you keep repeating the same thing?

Chapter 21 Advanced claude.md Context Management

■A. How to Structure the Full Business Context

An executive assistant's claude.md is more complex than claude.md in other projects. A newsletter project's claude.md only needs to know "how to create newsletters." The assistant's claude.md must understand your entire business: name, role, team, projects, priorities, communication style, tools used, decision history. If all of this goes into one file, it becomes hundreds of lines, and the tokens consumed in every conversation explode.

The solution is the routing learned in Chapter 5. Make claude.md a table of contents, and put the actual content in separate files.

In the executive assistant project of an AI automation consultant in the United States, claude.md is about 90 lines. The actual information inside it is minimal. One line for the assistant's role ("You are [name]'s executive assistant. Be direct, concise, and casual."), one line for the current top priority ("YouTube channel growth is priority number one. Everything else supports it."), and one line for an urgent matter ("Finish the client proposal by this Friday."). Everything else is routing: "If you need to know about me, /context/me.md," "Business information is /context/work.md," "The team is /context/team.md," "Current priorities are /context/current-priorities.md."

■B. Routing to Separate Files When claude.md Gets Long

Over time, new entries are added to claude.md. If you connect a new MCP server, that information goes in. If you create a new skill, the skill list is updated. If a new project starts, the project reference path is added.

Once it starts going beyond 150 lines, a warning light turns on. Once it exceeds 200 lines, you should actively split it apart.

The principle of separation is straightforward. Find blocks of information in claude.md that can be grouped by category. Move that block to a separate file. Leave only a one-line reference path in claude.md.

For example, if claude.md has fifteen lines of rules about communication style, create /rules/communication-style.md, move them there, and leave only "For communication rules, see /rules/communication-style.md" in claude.md.

■If you keep repeating the same instruction, that is a signal to split it into a skill

There are cases routing does not solve. If you repeat the same kind of instruction across multiple conversations, that is a signal that it should be separated into a skill.

If you are saying for the third time, "When researching, always use Perplexity, always include sources, and analyze relevance to our business," that instruction should go inside the skill.md of a research skill. Then from the next time on, one phrase, "research this," is enough for the agent to read the skill and apply every rule automatically.

Routing is a way to organize information, and skills are a way to organize behavior. When information repeats, use routing. When behavior repeats, use a skill. Use these two tools in the right places, and claude.md stays short and efficient while the agent's capabilities keep expanding.

Now that we know how to refine claude.md, it is time to create a skill that actually works. We will start with the Morning Coffee Skill, where an executive assistant plans your day every morning.

Chapter 22. Practical Skill Build

■A. Morning Coffee Skill: a daily routine for planning work each morning

Wednesday morning, 6 a.m. Before the alarm rings, the agent has already started working. It checks the calendar, brings in this week's task status from ClickUp, and reviews team members' progress. While you brew coffee, the agent prepares today's plan.

This is the Morning Coffee Skill.

(1) Logic that combines the calendar, video pipeline, and team status

The skill.md for the Morning Coffee Skill describes steps like these.

The agent first brings in today's schedule from Google Calendar, through GWS CLI or a calendar MCP. It checks meeting times, attendees, and agendas. Next, it reads this week's due tasks, delayed tasks, and newly assigned tasks from the project management tool. It refers to current-priorities.md in the context folder to confirm the current top priorities.

It combines all this information, prioritizes today's work, and proposes a schedule in time blocks. "9:00-10:00: finish client proposal, top priority. 10:00-10:30: team standup meeting. 10:30-12:00: write YouTube video script."

If you say "good," the agent registers those blocks in the calendar. Decision fatigue disappears.

(2) Difference from the Pulse Check Skill: level of depth

If the Morning Coffee Skill is a light briefing that plans the day, the Pulse Check Skill is a deep diagnosis of the health of the entire project.

When you run the Pulse Check Skill, the agent brings in tasks from all ongoing projects. It checks each task's status, completed, in progress, or delayed, and calculates progress against quarterly goals, goals.md. It separately marks items that require manual follow-up.

The difference between the two skills is depth and frequency. Morning Coffee is a light briefing that runs daily and finishes within five minutes. Pulse Check runs once or twice a week and reviews the whole project from above.

■B. YouTube Analysis Skill: converting video data into a report

An executive assistant's skills are not limited to work management. Any repeated task needed for the business can be turned into a skill.

If you run a YouTube channel, you can create a skill that automatically generates a weekly analytics report. This skill collects views, likes, and comments from videos published in the last seven days through the YouTube API. It analyzes comment content to extract topics viewers want, complaints, and points of praise. It also examines popular videos from competing channels. It turns all this data into a PDF report in SWOT analysis format, applies the brand logo and colors, and saves it in the projects folder.

Combine this skill with the scheduled deployment learned in Chapter 19, and every Monday morning the previous week's analytics report is generated automatically. You only need to read the report and reflect it in your decisions.

■C. Skill Creator: a tool that automatically turns existing work patterns into skills

After creating many skills, you start wanting to automate the process of creating skills itself. Anthropic's official Skill Creator skill plays this role.

Skill Creator is a skill for creating skills. It contains best practices for skill building accumulated by Anthropic. The correct structure of YAML front matter, principles for writing step-by-step instructions, strategies for placing reference files, and even the eval process for assessing and improving skill quality.

To install it, type /plugins in the chat window, search for "skill-creator," and press the install button.

After installation, if you request, "Create a YouTube weekly analysis skill," Skill Creator asks questions and automatically generates skill.md based on your answers. It tests the generated skill, compares the result with a Golden Output, evaluates quality, and suggests improvements.

Skill Creator's eval function is useful for long-term skill maintenance. When the AI model is updated, it automatically checks whether existing skills still work well. If performance has fallen, it signals that the skill should be revised. Conversely, if the model has improved enough to produce good results without the skill, it helps decide that the skill can be retired.

This completes Part 6. We built the skeleton of the executive assistant with the four-step framework, deepened claude.md context management, and built the Morning Coffee Skill and YouTube Analysis Skill in practice. We also learned how to automate the skill creation process itself with Skill Creator.

Until now, however, the agent has performed only one task at a time. While the Morning Coffee Skill is running, it cannot do research. While it is researching, it cannot create content. What if several tasks could be assigned at the same time to specialized agents? A parallel structure where a researcher agent investigates, a content agent drafts, and an analysis agent organizes data. That is the subagent, and the agent team.

Chapter 23. The Concept and Operating Principles of Subagents

■A. A structure for delegating work from the main session to specialized agents

Imagine preparing a party. You need custom cupcakes. You could buy mass-produced cupcakes from the neighborhood market, but for a special party, it is better to custom order from a specialized bakery. The bakery makes only cupcakes. It does not handle every dessert. Instead, when it comes to cupcakes, it is much better than you are.

A subagent is exactly that specialized bakery.

Until now, you handled all work in one main Claude Code session. You researched, wrote code, made PDFs, and sent emails. This method has two problems. First, the main session's context window fills quickly. When tens of thousands of tokens of research results accumulate, the quality of later code writing or PDF creation falls. This is the context rot learned in Chapter 6. Second, if a general-purpose agent does everything, it excels at nothing. People are the same. If one person handles marketing, finance, and development, it is hard for any one area to reach expert level.

Subagents solve these two problems at the same time. The main session acts as the project manager and delegates specialized work to subagents. A subagent works independently in its own context window. If a subagent handles 40,000 tokens of research, the main session's context stays clean. When the subagent summarizes the result and sends it back, the main session receives only the core information and proceeds to the next step.

■B. Dividing roles among coder, reviewer, debugger, test runner, architect, and researcher

There are many specialized roles you can assign to subagents. Boris Cherny of Anthropic, the maker of Claude Code, has mentioned subagents he uses routinely, including Build Validator, Code Architect, Code Simplifier, On-call Guide, and Verify App.

Common role division in practice looks like this. The Researcher handles web search and data collection. The Coder writes code. The Reviewer examines written code and checks quality. The Debugger tracks and fixes errors. The Test Runner runs automated tests. The Architect designs the overall structure of the project.

You do not need to create all these roles. Start by separating the specialized areas that repeatedly appear in your work pattern into subagents one by one.

■C. Subagents run in parallel with their own context and separate models

There are three properties you must understand about how subagents work.

Independent context. When a subagent wakes up, it does not inherit the conversation history of the main session. It starts completely blank. The prompt, the work instruction, given by the main session is the subagent's only initial input. Thanks to this, the main session's context is not polluted.

Separate model selection. You can assign a different AI model to each subagent. Assigning Haiku to a research subagent reduces token costs. Assigning Opus to a subagent that needs architecture decisions secures deeper reasoning. The model selection strategy covered in Chapter 7 applies at the subagent level.

Parallel execution. You can launch several subagents at the same time. While the research agent searches the web, the code agent can refactor existing code, and the test agent can run existing tests. The three agents work at the same time, so it is much faster than sequential processing.

Remember one constraint of subagents. Subagents cannot talk to one another. The research agent cannot directly tell the code agent, "Use this data." All communication goes through the main session. The main session receives the research result and passes it to the code agent. If this constraint is inconvenient, the agent team covered in Chapter 25 is the alternative.

Now that we understand the concept and operating principles of subagents, let's create one ourselves.

Chapter 24. Custom Building Subagents

■A. Carousel Planning Subagent: converting transcripts into slides

Let's create one practical subagent in the executive assistant project. It is a subagent that converts a YouTube video transcript into carousel content for social media, meaning swipeable image slides.

Inside the main session's carousel skill, when the agent receives a transcript, it extracts key messages, plans text and layout for each slide, and generates images. If the "slide planning" step in this process is assigned to a separate subagent, you can save the main session's context while improving the expertise of the slide structure.

The easiest way to create a subagent is the /agents command. Run this command in the terminal, and the "Create New Agent" option appears. Select Project Agent, for use only in this project, and choose "Generate with Claude." Describe the agent's role.

"This agent is a carousel planner. It receives YouTube transcripts and creates a carousel content plan made of 7-8 slides. It includes each slide's title, body text, and visual suggestions."

The agent automatically generates an agent.md file based on this description. It sets tools to use, the model, Sonnet or Haiku, and the agent color for identification in the terminal. If you enable memory, the subagent refers in the next run to patterns learned from previous runs.

Calling this subagent inside a skill is simple. Add an instruction to the carousel skill's skill.md: "Delegate to the carousel planner agent during the slide planning step." Then the subagent is called automatically every time the skill runs.

■B. Running two research subagents in parallel: one for SMBs and one for enterprises

This is a case where the parallel execution power of subagents shines.

Suppose you request, "Research AI adoption strategy," but want to investigate both the small and midsize business, SMB, perspective and the enterprise perspective at the same time. If one research subagent does it sequentially, it takes twice as long. Instead, launch two research subagents at once.

"Launch two subagents. One should research AI adoption cases at small and midsize businesses, and the other should research AI governance strategies at large enterprises. When both are done, synthesize the results."

The main session creates the two subagents at the same time. Each searches the web and organizes materials in an independent context. Because the two agents work at the same time, the elapsed time is almost cut in half compared with sequential processing.

■C. Flow for collecting and synthesizing results in the main session

When the two subagents finish their work, each result returns to the main session. What the main session receives at this point is not the subagent's whole working process, but the final summary.

The SMB subagent returns "SMB AI adoption status: five major cases, three adoption barriers, recommended starting points," and the enterprise subagent returns "enterprise AI governance: comparison of three frameworks, regulatory response status, organizational structure changes." The main session receives these two results, analyzes overlaps and differences, and writes an integrated report.

The core value of this structure is context efficiency. Even if the SMB subagent internally consumed 40,000 tokens, the summary received by the main session is only a few thousand tokens. The main session's context window stays clean while deep research in two fields is secured.

If subagents are individual specialists, an agent team is a project organization where one team gathers and collaborates. Members talk directly with one another, manage a shared task list, and review one another's work.

Chapter 25. Agent Teams

■A. Difference between subagents and agent teams

To state subagents again, the main session gives instructions, the subagent performs independently, and the result comes back. It is one-way. Subagents cannot talk to one another.

An agent team raises this structure one level. Agents inside the team can exchange messages with one another. They manage a shared task list together. When one agent finishes work, it can directly send another agent a message saying, "Please check this."

A soccer team makes this easy to understand. In the subagent structure, the coach gives instructions to each player individually, and players report only to the coach. Players do not talk to one another. In the agent team structure, the coach sets the overall strategy, and players communicate on the field and collaborate in real time. A defender passes the ball to a midfielder, and the midfielder passes to a forward.

■B. Collaboration patterns where multiple agents work toward one goal

A representative pattern where agent teams show their value is building a full-stack web app.

You request, "Make a landing page," while forming a team. "Create a team of three: frontend developer, backend developer, and QA agent. Use the Sonnet model."

The main session creates three agents at the same time. A shared task list is created, and each agent receives an area of responsibility. The frontend developer builds the screen, and the backend developer builds the server logic. After the two agents work in parallel, they send a message to the QA agent: "Please review this." The QA agent runs tests and finds three bugs. The QA agent directly messages the frontend developer and backend developer, respectively: "Please fix this part." When the fixes are done, the QA agent reviews again. If it passes, the QA agent reports "complete" to the main session.

Throughout this process, the main session only plays the role of orchestrator. The actual work and quality checks happen autonomously among the team members.

To use agent teams, you need to enable an experimental feature. Add the relevant setting to the project's .claude/settings.local.json. You can just tell the agent, "Add this setting."

There are cautions when using agent teams. The cost is higher than subagents. If three agents run at the same time, token consumption is also nearly tripled. If agents edit the same file at the same time, conflicts can occur, so the file areas handled by each agent must be clearly separated. A team size of 3-5 people is appropriate. Teams of 10 or more sharply increase coordination costs and reduce cost efficiency.

■C. Context preservation strategy: how to prevent information loss between agents

Whether with subagents or agent teams, the hardest problem is information loss. A subagent starts from a blank state when it wakes up. The same is true for members of an agent team. Aside from the initial prompt sent by the main session, they have no context.

There are three strategies to reduce this problem.

Rich initial prompt. When calling a subagent, pass necessary background information along with the work instruction. Do not just say, "Do SMB research." Say specifically, "We are an AI automation consulting company. Our main customers are marketing agencies with 10-50 employees. In this context, research AI adoption cases among SMBs."

Project file access. Subagents and members of agent teams can access all files in the project. They can read me.md and work.md in the context folder, and they can use skill files. If the initial prompt explicitly says, "Refer to the files in the context folder," the agent loads the needed context on its own.

Agent memory. When creating a subagent with the /agents command, enabling memory creates an agent-specific memory file. Each time execution ends, what the agent learned, good data sources, recurring topics, effective approaches, is recorded in this file. On the next run, the agent reads this memory before starting, so it works much more efficiently than from a completely blank slate.

This completes Part 7. We delegated specialized work in parallel with subagents and built a structure where multiple experts collaborate in real time through agent teams. We learned how to scale agentic systems.

In Part 8, we change direction. Instead of scaling up, we look at techniques for making an existing system sharper and more efficient. Thirty-two hacking tips discovered through experience by people who use Claude Code every day. Ten beginner tips, twelve intermediate tips, and ten advanced tips await. How to run parallel sessions with Git worktrees, how to put Claude Code on a VPS and keep it running 24 hours, how to secure safe autonomy with permission settings. Each of these tips will shave time off your daily work.

Chapter 26. Beginner Hacking Tips (1-10)

■A. Run /init in every project

When you open a new project, there is something you should do first. Type /init. For a project with existing files, the agent scans the codebase and automatically creates claude.md with architecture, languages used, and key files identified. For a new project, it suggests a basic folder structure. This one-line command shortens the start of every session by at least 10 minutes.

■B. Customize the status line

If you use Claude Code in the terminal, you can set a status line that is always visible at the bottom of the screen with the /statusline command. It shows the current model, context usage, and session cost in real time. You can notice the moment context exceeds 60% without entering a separate command. Like a car's fuel gauge, it has to be visible to be managed.

■C. Speed up prompting with voice input

The /voice command has been introduced in Claude Code, allowing direct voice input in the terminal. The reason voice is faster than typing is plain. Fingers type 40-60 words per minute, while the mouth speaks 120-150 words per minute. When brain-dumping complex requirements, you can pour out thoughts as they are instead of tapping the keyboard and polishing sentences. The agent understands spoken style well.

You can also use a separate speech-to-text app. Once activated, it converts what you say into text not only in the Claude Code chat window but anywhere.

■D. Build a habit of keeping context small

Do not throw the entire codebase at the agent all at once. Pass only the files and information needed for the current task. Break big problems into small, focused steps. The less unnecessary noise in the context window, the higher the agent's response quality. This is the everyday application of the principle learned in Chapter 6.

■E. Use /context to identify token consumers

When you feel the agent slowing down or response quality dropping, type /context. It shows by category how many tokens are taken by the system prompt, MCP servers, skills, and conversation history. If an unused MCP server is eating 10% of the context, disconnecting it alone produces a noticeable performance improvement. It is like keeping a household ledger. If you do not see spending details, you cannot know where money is leaking.

■F. Compact at 60%, clear when switching tasks

When context usage reaches 60%, run /compact. The agent compresses the conversation, leaves only the core information, and clears the rest. You can specify what to preserve, such as "keep the API integration decisions."

When the work topic changes completely, initialize the conversation with /clear. When moving from newsletter work to competitor analysis, this prevents residual context from the previous conversation from polluting the new task. claude.md and project files remain intact, so you are not really starting from zero.

■G. Always start in plan mode

Press Shift+Tab at the bottom of the chat window to switch to plan mode. In plan mode, the agent reads, investigates, and makes a plan, but does not create files or run code.

This one habit dramatically reduces the number of revisions. If you start building without a plan, the agent discovers the problem only after stacking code in the wrong direction. The cost of rolling back and restarting is large. If you review the plan in plan mode, revise it, agree on it, and then switch to execution mode, the quality of the first deliverable is much higher.

■H. Treat Claude like a junior developer: give a problem instead of a command

Instead of directly commanding, "Write a login function," try handing over the problem: "How should we handle user authentication?" The agent thinks through the approach on its own, presents several options, and explains the pros and cons of each. Through this process, the agent reasons more deeply, and the quality of the final code improves.

Reading the agent's judgment process is learning in itself. Ask, "Why did you choose this method?" and the agent explains the technical basis.

■I. Make Claude ask questions first

Add this sentence to the end of the prompt: "Keep asking questions until you are 95% sure what I want." The agent discovers and asks about missing information, ambiguous requirements, and potential conflicts on its own. This prevents the situation where, only in the third revision round, you regret, "Ah, I should have said this at the beginning."

■J. Put a self-verification step in the to-do list

When the agent creates a to-do list, instruct it to insert verification steps between build steps. "After making the website, take a screenshot and check whether the layout is correct before moving to the next step." "After completing the API integration, run a test call and confirm that the response is normal."

Add the rule "verify until you are 95% confident before moving to the next step," and the agent hands over results at 90% completion instead of 60%.

Applying only these ten beginner tips will visibly change work efficiency. Next come intermediate tips for people whose hands are already used to Claude Code.

Chapter 27. Intermediate Hacking Tips (11-22)

■A. Delegate parallel work to subagents

When you encounter complex work, do not try to handle everything in the main session. Delegate it to a subagent. If you instruct, "Leave the research to a subagent and send me only the summarized result," the main session's context stays clean. This is the everyday use of subagents learned in Chapter 23.

■B. Create custom skills yourself

If you have repeated the same type of work three or more times, it is time to make it a skill. Create skill.md in the .claude/skills folder and describe the task steps, rules, and reference files. From next time, one phrase, "Run this skill," produces consistent-quality output.

■C. Assign the Haiku model to subagents

Assign Haiku to subagents that process large amounts of data or perform repeated work. Using Opus to read hundreds of thousands of tokens of transcripts and extract only the key points makes the cost unnecessarily high. Process it with Haiku and return only the summary to the main session, and you reduce cost without losing quality.

■D. Update claude.md frequently

Whenever you find a new pattern in a project or the agent repeatedly makes the same mistake, update claude.md. Say, "Add this rule to claude.md," and the agent edits the file directly. claude.md is a living document.

■E. If claude.md exceeds 500 lines, separate it into external files

The proper length for claude.md is 150-200 lines. Beyond that, token consumption in every conversation rises sharply. Apply the routing strategy learned in Chapters 5 and 21. Separate information by category and leave only reference paths in claude.md.

■F. Stop early and ask again

If the agent is going in the wrong direction, do not wait until it finishes. Press the Escape key to stop execution. Tokens spent in the wrong direction cannot be recovered. Send a prompt that corrects the direction and start again.

■G. Verify outputs aggressively and ask back

If the agent's first result is only "okay," present a higher standard. "Discard this and try a completely different approach." "Create a more polished version." The agent recognizes what was lacking in the first attempt and raises quality in the second. Every time you give feedback, say to the agent, "Reflect this lesson in the skill," so the same mistake does not recur.

■H. Fast rollback with /rewind

If the agent changed code and the state got worse, type /rewind. The conversation and code state are restored to the point before the edit. It is the same concept as undo in a word processor, but it rolls back code changes too.

■I. Set notifications with hooks

Use the /hooks command to connect notifications to specific events. If you set "play a sound when the session ends," you can immediately know the agent has finished even while doing other work. This is useful when running several sessions in parallel.

■J. Take screenshots for visual verification

If you instruct the agent, "Take a screenshot and check it," Puppeteer captures the current page. The agent analyzes the image and finds layout errors, color mismatches, and cut-off text. This is the everyday use of the screenshot loop learned in Chapter 12.

■K. Use Chrome DevTools

The agent can open a browser and test the functions of a web app. It automatically clicks buttons, submits forms, and moves between pages while detecting JavaScript errors or failed network requests. If screenshots are design verification, Chrome DevTools is function verification.

■L. Clone inspiration sites

This technique was covered in detail in Chapter 12. Give the agent screenshots and style information from a website you like and say, "Make it feel like this." Providing a visual reference is much faster and more accurate than explaining the design from scratch.

Chapter 28. Advanced Hacking Tips (23-32)

■A. Run parallel sessions with Git worktrees

(1) The principle of checking out multiple branches from the same repo at the same time

In Git, generally you can work on only one branch at a time. If an urgent fix is needed while developing a new feature, you have to save the current work and switch branches. The work is interrupted, and context is disturbed.

Git Worktree removes this constraint. From the same repository, you can check out multiple branches into separate folders at the same time. Folder A opens the main branch, folder B opens a feature branch, and folder C opens a fix branch, all at once.

(2) Run independent Claude Code sessions in each worktree

You can run an independent Claude Code session in each worktree folder. Session A builds a new feature, session B fixes a bug, and session C updates documentation. The three sessions work in the same repository, but they do not touch one another's files. When the work is done, merge each branch into main.

The Claude Code command for creating a worktree is claude --worktree feature-name. The agent automatically creates a new branch and working folder.

■B. Call API endpoints directly instead of using MCP servers

MCP servers are convenient, but the full tool definitions occupy context. If a project uses only one function of an MCP server, directly calling that API endpoint is more token-efficient. If you only need to read one Notion database, the dozens of tool descriptions in the Notion MCP server do not need to be loaded in every conversation.

■C. Automate repeated work with /loop

With the /loop command, or with natural language such as "check deployment status every five minutes," the agent repeats work at specified intervals inside the same session. It is used for deployment monitoring, PR, Pull Request, review, and error log monitoring. It remains active for up to three days while the session is open. If you need automation longer than three days, use the scheduled deployment covered in Chapter 19 or scheduled tasks in the desktop app.

■D. Put Claude Code on a VPS and create an always-on session

(1) SSH access and Telegram integration

If you install Claude Code on a VPS, Virtual Private Server, the agent runs 24 hours a day even when your computer is off. You can connect through SSH, Secure Shell, a remote access protocol, and talk with the agent. Set up a Telegram bridge, and you can send messages to the agent from your smartphone and receive answers. Claude Code in your pocket.

You can start by renting a VPS from a service such as Hostinger for around $6 per month, about 8,200 won. Installing Claude Code is the same as installing it in the terminal.

■E. Remote control from your phone

With Claude Code's Remote Control feature, you can continue a session started on your local desktop from a smartphone browser. The code stays on the local machine, and only instructions are sent through the remote connection. When you need to leave after starting work, you can still manage the agent while you are on the move.

■F. No-code data analysis

If you connect data tools such as BigQuery's BQ CLI to Claude Code, you can analyze data in natural language. If you say, "Tell me the top 10 products by sales last quarter," the agent writes and runs the right SQL query and returns the results. Even people who do not know SQL can access data.

■G. Ultra Think mode

When the agent repeats the wrong answer on a complex problem, include the word "ultrathink" in the prompt and it will allocate the maximum thinking budget, about 32,000 tokens. The agent responds after reasoning far more deeply than usual. Use it for architecture design, complex debugging, and decisions that affect the whole system. It is unnecessary for everyday tasks.

■H. Securing safe autonomy with Permissions settings

(1) The danger of dangerously-skip-permissions

Bypass permissions mode is convenient, but it means the agent can run any command without approval. File deletion, system-setting changes, and external service calls all happen automatically.

(2) How to register only safe commands in the allowlist

A safer method is to specify allowed commands and prohibited commands in the project settings. Allow file reads and web searches, but prohibit file deletion (rm -rf) and system modifications. The denylist takes priority over the allowlist, so even if a dangerous command is added to the allowlist by mistake, the denylist blocks it.

With this setup, you can keep a speed close to bypass permissions while gaining a safety net that prevents fatal mistakes.

■I. Building an agent team

Enable the agent team covered in Chapter 25 as an experimental feature. Add the relevant option to the project settings file. Three to five specialized agents communicate with each other and work in parallel. Because the cost is high, it is wise to use this only for complex, many-sided projects.

■J. Using Context7 MCP

Context7 is an MCP server that provides up-to-date technical documentation by version. The agent's training data may not reflect API changes or library updates. When Context7 is connected, the agent checks the latest documentation for the library before writing code. This prevents errors caused by renamed functions, removed parameters, or newly added features.

All 32 hacking tips have now been covered. These tips are not meant to be applied all at once. Try them one by one, choose the ones that fit your workflow, and turn them into habits. Start with the beginner tips, then move up to intermediate and advanced tips as needed.

How agents directly open and control browsers, along with the core concepts of Git and GitHub, will be covered in separate chapters.

Chapter 29. Browser Automation

■A. How Claude Code opens and controls a browser

Recreating in code everything a person does while sitting in front of a computer, moving the mouse, clicking buttons, and entering text. That is the essence of browser automation.

In Claude Code, you install Playwright CLI to enable this feature. Playwright is a tool that controls web browsers through code. The agent can open a browser, enter a URL, scroll a page, press buttons, fill forms, and take screenshots.

To install it, you can simply tell Claude Code, "Install Playwright CLI." The agent installs the required packages, creates a test script, and checks whether the browser opens properly.

■B. A loop for automatically detecting functional errors with Chrome DevTools

When building the fitness coach app in Chapter 14, we found a bug where gamification points did not increase. A person found it by using the app directly.

With browser automation, the agent handles this process for you. "Open the web app, fill in every field in the form, click the button, and check whether there are functional errors." The agent opens the browser and uses the app like a real user. It detects JavaScript errors, failed network requests, and screen transitions that differ from expectations. When it finds a bug, it takes a screenshot, diagnoses the cause, and modifies the code.

If you repeat this test-and-fix loop, most functional errors are caught before deployment.

■C. Limits of the screenshot loop in dynamic content testing and alternatives

As discussed in Chapter 12, pages with animation or dynamic content run into the limits of screenshot-based verification. A screenshot captures only one frame, so it cannot accurately evaluate moving elements.

There are two alternatives. One is to tell the agent, "Do not compare screenshots for this part." The other is to test real interactions through browser automation. You verify in code whether an animation starts when a button is clicked or whether elements appear as the page scrolls.

Chapter 30. Core Concepts of Git and GitHub

■A. Repository, commit, branch, push, pull, merge

Think of a bank account. Every transaction is recorded. Deposits, withdrawals, transfer dates, and amounts all remain. Git is a transaction ledger for code.

A repository is the project folder Git tracks. It contains all files and the history of changes.

A commit is a snapshot at a specific point in time. It records changes with a message such as "Add login feature." It is like a save point in a video game.

A branch is a separate workspace where you can experiment without affecting the main code. The default branch is usually called "main." When developing a new feature, you create a branch with a name such as "feature-login," work there, and merge it into main when it is complete.

Push means uploading local commits to GitHub (online). Pull means bringing the latest changes from GitHub to your local machine. Merge means combining changes from one branch into another branch.

■B. A workflow for experimenting safely with branches and merging into main

Let us see how these concepts combine in real work.

You want to add a new feature to a website project. If you work directly on the main branch, a mistake may be reflected immediately on the live site. Instead, create a new branch. Develop and test the feature on that branch. If everything is working normally, merge it into the main branch. Vercel detects changes to the main branch and deploys automatically.

This workflow is the standard method used by professional development teams. Claude Code understands this process well, so it can handle natural-language instructions such as "Create a new branch," "Commit these changes," and "Merge this into main."

■C. Claude Code and GitHub integration: commit automation

Chapter 15 already covered how to connect Claude Code with GitHub. What I want to stress here is commit automation. If you tell the agent, "Commit the changes and push them to GitHub," it detects changed files, writes a meaningful commit message, and pushes.

Having the agent write commit messages automatically is surprisingly useful. Descriptive messages such as "Add glow effect to hero section" are attached, so later, when tracking change history, it is easy to understand what each commit did.

This concludes Part 8. We covered 32 hacking tips, browser automation, and the essentials of Git and GitHub. Now that you have learned techniques for sharpening your tools, we move to the stage of turning all these abilities into revenue. Part 9 covers a framework for securing your first client within seven days, value-based pricing, workflow testing and QA, handover and maintenance, and real case studies.

Chapter 31. Overcoming Three Psychological Barriers

■A. Imposter syndrome: gaining real experience through free or low-cost pilots

You see it when you stand in front of the mirror. "Can I really charge money for this?" You have learned how to build agentic workflows and even made demo projects, but standing before a client is an entirely different matter. This feeling has a name: imposter syndrome, the sense that you are an unqualified fraud.

One AI automation consultant in the United States overcame this barrier in the following way. A 21-year-old in his community secured his first client in five days and was honest from the start. "I have just entered this field. I am absorbed in learning, and I am building a lot. I want to solve this problem for you." This kind of honesty is not a weakness. It is a pattern interrupt. The other person receives sales messages every day. "I am new, but I want to help" sounds like the voice of a real person.

Run the first one or two projects for free or at a very low price. This is not charity. It is an investment. What you invest is time. What you get back is real experience, a case study, and confidence. Offer it to the client like this: "I will build one small automation for you for free. Whatever the result is, it is yours. All I ask for is honest feedback."

There is little reason to reject an offer with zero risk. And once that one project is over, you become someone who can say, "I have done this before." Imposter syndrome melts only through experience.

■B. Obsession with pricing: do not worry about retainers before your first client

The second barrier is impatience about pricing. Some people have not even started their first project yet, but they are already worrying about the structure of a monthly retainer and drawing a roadmap to 10 million won in monthly revenue.

A retainer is a building that stands on trust. If you try to put up the building before trust is built, it collapses. The goal of the first project is not maximizing revenue. It is delivering value, proving that value in numbers, and creating a relationship. A retainer is something you naturally propose after value has been proven, when the client says, "I want to keep working with you."

■C. Over-preparation: you can start without a perfect portfolio

The third barrier is perfectionism. "I need to polish my portfolio more." "I should build a website first." "I need at least three case studies." These thoughts delay the start forever.

The 21-year-old mentioned earlier had no website. He had no portfolio. What he had was learned knowledge, honesty, and the courage to start a conversation. And he secured his first client in five days.

Perfect preparation does not exist. Your first project does not have to be perfect. What matters is starting, then learning and improving with every project.

Chapter 32. The Seven-Day Client Acquisition Framework

■A. Day 1: set a loose direction and make a list of 20 potential contacts

The first day has two goals. Set a rough direction, and make a list of 20 people to contact.

Direction setting is not about choosing an ultra-precise niche. "I automate repetitive work for small and medium-sized businesses with AI" is enough. At this stage, you are not deciding which industry to focus on. You are creating one sentence that can start a conversation.

Create the list in Google Sheets. Record name, industry, strength of relationship (whether you know the person directly or through someone else), and potential role (whether the person could become a direct client or introduce someone). Friends who run businesses, former coworkers, people you met in communities, LinkedIn connections. You will find that filling 20 names is not as hard as it seems.

■B. Days 2-3: five to ten warm, low-pressure conversations

(1) A trust-based approach, not cold outreach

Contact 5 to 10 people from the list. This is not a sales call. You are asking for a conversation as a curious businessperson.

Keep the message concise. "I am starting a business that automates repetitive work with AI. I am not trying to sell anything. Could we talk for 15 minutes? I want to hear where your daily work still feels manual."

(2) The question: "Where in your daily work does it still feel manual?"

The core question in the conversation is one sentence. "Among the tasks you repeat every week, is there anything you wish someone else would do for you?" This question reveals pain points. They spend five hours a week on lead management. Customer onboarding is too slow. Data entry is done manually. Answers like these come out. Record the key points from every conversation.

■C. Days 4-5: turn pain points from conversations into a small pilot

Review your notes. Choose the person with the clearest and most painful repetitive task. Then propose a very small, low-risk pilot.

"I would like to build the lead follow-up automation you mentioned last time as a free pilot. The result is yours, and all I ask for is honest feedback."

Define the pilot as narrowly as possible. One process, one automation, one output. Not a giant system, but a small, measurable improvement.

■D. Day 6: build a minimum viable product (MVP)

Build the pilot. Everything learned in this book applies here. Make a plan with the agent in plan mode, create the workflow and tools, and test it. Do not make it complicated. Implement only the minimum features that let the client feel, "This saved me time."

After the build is complete, record a two- to three-minute walkthrough video with Loom, the screen-recording service. Show the automation working and explain what problem it solves and how.

■E. Day 7: review pilot results and discuss next steps

Review the pilot results with the client. Show in numbers the time saved by the automation, the manual work reduced, and the accuracy improved.

(1) Maintenance or feature expansion with the same client

If the result is good, propose the next step. Present an appropriate option between maintenance, which keeps the automation running and handles small fixes, and feature expansion, which adds new automations.

(2) When to ask for a video testimonial

After confirming that the client is satisfied with the result, ask for a short video testimonial. "Could you record a 30-second video explaining how this automation helped you?" This testimonial becomes your strongest weapon when securing the next client.

■F. This cycle is repeated, not done once

The seven-day framework is not a one-time event. It is a cycle. In the first cycle, you gain experience. In the second cycle, you refine your language. In the third cycle, confidence grows. As the cycle repeats, conversations become more natural, proposals become sharper, and conversion rates rise.

Chapter 33. Value-Based Pricing (PRICE Framework)

■A. P (Prepare): convert business pain into time and cost numbers

(1) Wasted hours per week x labor cost x 52 weeks = annual loss

Suppose the process you will automate consumes 10 hours of an employee's time every week. If that employee's hourly wage is $25, roughly 34,000 won, the cost is $250 per week, $1,000 per month, and about $13,000 per year, roughly 17.8 million won.

(2) Calculate the percentage the workflow saves

If your automation can handle 60% of this process, the annual savings are about $7,800, roughly 10.7 million won.

■B. R (Research): study industry benchmarks and competitor pricing

Research the price range for similar automation services in the same industry. You need to know the market price to judge whether your own price is appropriate.

■C. I (Itemize): set the base price at 10-20% of generated value

The rule of thumb is this: the client should be able to see a 10x return on investment in the first year. If the annual savings are $7,800, start the project fee around $780, about 10%. As you gain experience and build more case studies, you can raise it to 15-20%.

The key is to show this calculation transparently in front of the client. "This process costs you $13,000 a year. If my automation saves 60%, you save $7,800. My fee is $780. You recover the investment in the first month, and the remaining 11 months are pure gain." When clients hear this math, price is perceived as an investment, not a cost.

■D. C (Communicate): deliver the value of the solution before saying the price

Before saying the number, first draw the picture of what happens after the automation is applied. "Every Monday morning, you no longer have to sort lead lists manually. The system classifies them automatically and sends only high-priority leads to the person in charge." Once the client imagines that future, the weight of the number changes.

■E. E (Evolve): path to a maintenance retainer after QA is complete

Even after the project is complete, the relationship continues. Propose a maintenance retainer. Handle API changes, model updates, and small feature fixes for a monthly fee. A suitable range is 10-25% of the original project fee.

Chapter 34. Workflow Testing and QA

■A. Designing test data with the client's real data

If you test with fake data, you find fake bugs. Ask the client for samples of real work data: original emails, CRM records, support tickets. If personal information is included, anonymize it before use. Real data reveals real edge cases.

■B. Internal QA: deliberately explore worst-case scenarios and edge cases

Do not merely check whether it "works normally" like a developer. Find "where it breaks" like an engineer. Deliberately enter empty data, duplicate data, unexpected formats, and abnormally large input values. Check whether the way it breaks is safe, such as stopping quietly or sending an error notification.

■C. A/B testing by prompt and model combination

In workflows that include AI, output quality changes greatly depending on prompt wording and model choice. Run prompt A and prompt B on the same input data, then compare which one produces more accurate and consistent results.

■D. Client-facing QA: how to collect structured feedback

After completing internal QA, provide the client with a test environment. Let them try it directly through a small form or chat interface. Collect feedback in a structured way. Ask for item-by-item ratings such as "How accurate is the output?", "Is the tone appropriate?", and "Do you like the format?"

■E. Why QA results become evidence that builds trust

Document the testing process and results. How many samples were tested, what edge cases were found, and how they were fixed. Share this document with the client, and trust grows: "This person works carefully." The chance of winning the next project rises, and conversion to a retainer becomes natural.

Chapter 35. Handover and Maintenance

■A. Two variables that affect handover

(1) Was it built in the client's account or in your infrastructure?

If you built it directly in the client's GitHub, Trigger.dev, or cloud environment, handover is straightforward. Everything is already owned by the client. You only need to replace your test credentials with the client's credentials.

If you built it in your own infrastructure, you need to move the code and settings into the client's environment.

(2) Is the project ending, or is more work planned?

If the project is fully ending, the handover must be final. All documents, code, and credentials should be neatly organized and delivered. If more work is planned, keep the test environment.

■B. Separating test and production environments

Follow a basic principle of software development. Experiment in the test environment, and move only verified changes into the production, or live operating, environment. Explain this concept to the client. "When changes are needed, we do not touch the live system first. We check them in the test environment and then apply them."

■C. Deliverables: Loom walkthrough video, technical documentation, credential summary

Organize the deliverables for handover. A Loom walkthrough video, explaining how the system works and how to set it up through screen recording. Technical documentation, listing the workflow structure, tools used, and settings. Credential summary, explaining which API keys are needed and where they are stored.

These documents allow the client's team to understand and manage the system even after you leave.

■D. Designing a maintenance retainer

(1) Scope including monitoring, model updates, and small fixes

Clarify what is included in the maintenance retainer. System monitoring, compatibility checks when AI models update, small bug fixes, and responses to external API changes. New feature additions or large refactors should be separated as separate projects.

(2) Items to state in the retainer agreement

Scope of service (included and excluded items), response time (within how many hours for urgent outages, within how many days for ordinary requests), term and renewal conditions, fee and payment terms, and handover procedure upon termination. If these items are clearly written down, both sides are protected.

■E. Security and data privacy check

Security is a required checkpoint in every workflow that handles client data. Check that API keys are not hardcoded in code, that .env files are not uploaded to GitHub, and that webhook endpoints require authentication.

When handling personal information, you must comply with relevant laws such as the GDPR, the EU General Data Protection Regulation, or Korea's Personal Information Protection Act. Prepare procedures for data minimization (collecting only necessary information), access control (only relevant people can view logs), and responses to data deletion requests.

Chapter 36. Christian Case Study

■A. How mass cold outreach turned into a first client in five days

There was a 21-year-old living in Arizona. He had become interested in AI only a few months earlier. At first, he scraped leads from LinkedIn, generated email copy with AI, and sent 450 cold emails a day. Open rates were high, but no one bought. There was no reason to respond to a template ad from a stranger.

His approach changed when he joined an AI automation community. "Do not sell workflows. Sell outcomes." That one sentence became the turning point. He began warm conversations with people he knew and learned that a project manager at a construction company spent a lot of time on customer communication. He proposed a PM assistant chatbot as a free pilot. Five days later, it converted into a paid contract. It began at $1,500 per month, roughly 2.05 million won, and later rose to $2,000, roughly 2.74 million won.

■B. Mindset shift from "selling workflows" to "selling business outcomes"

What he changed was not the tool, but the language. Not "Look at this automation I made," but "This system creates these results in your business." Instead of explaining the number of automation nodes or the structure of API calls, he talked about saved time and reduced errors. Developers admire technology. Business owners open their wallets for outcomes.

■C. How one community post led to a second client

After securing his first client, he posted his experience in the community. What he did, what result came out, and what lesson he learned. Another community member who read the post contacted him. "I was looking for an AI automation developer too, and I think you are exactly right." Three days later, the second client was confirmed.

What 450 cold emails failed to create, one community post created. In a space where trust already exists, sharing honest experience was the strongest marketing.

This concludes Part 9. We covered how to overcome psychological barriers, the framework for securing your first client in seven days, the PRICE model for value-based pricing, the QA process for assuring workflow quality, professional handover and maintenance, and a real case study. We have walked the full path from technology to revenue.

Part 10 compresses the journey of this book into one map and introduces communities and resources for continuing to learn.

Chapter 37. The Full Map of What This Book Taught

■A. Summary of the journey from the WAT framework to monetization

Before closing the book, let us look back at the path we have traveled.

The starting point was one empty folder. The moment you opened VS Code and looked at an explorer with nothing in it. From there, you confirmed in numbers how fast the agentic AI industry is expanding. A market racing from $7.8 billion toward $50 billion. Twenty-five percent of companies have already started pilots, and the forecast says half will be operating them by 2027. These numbers tell us that the skills you learned are not a hobby, but have real economic value.

The WAT framework provided the skeleton. The workflow, a natural-language instruction manual. The agent, the subject that makes judgments. The tools, the hands that execute. Understanding the structure in which these three layers divide the work was the foundation of everything. The relationship between recipe, ingredients, and chef. From Chapter 2, where that metaphor first appeared, to the Morning Coffee skill in Chapter 22, the WAT framework never left the stage.

You set up the environment. You installed VS Code, connected the Claude Code extension, and gave the agent project context through claude.md. You learned the principles of tokens and the context window, and understood how the agent's work notepad fills and empties. You learned how to find the balance point between cost and quality through a model-selection strategy.

You designed projects and connected core features. You controlled the agent with slash commands, organized projects through folder architecture, and placed external knowledge within the agent's reach through RAG and vector databases.

You made websites and apps. You cloned reference sites and had the agent verify its own results visually through screenshot loops. You refined details with 21st.dev components and built an AI fitness coach web app from beginning to end. You connected GitHub and Vercel and deployed code to the world. You experienced the moment of opening something you made on a smartphone.

You connected tools and deployed workflows. MCP servers opened doors to external services for the agent, skills encapsulated expert knowledge, and GWS CLI allowed you to handle all of Google Workspace through one interface. With Modal and Trigger.dev, you put workflows in the cloud so they could run automatically even while you slept.

You built an AI executive assistant. Following the four-step framework of home, life, hands, and growth, you made an agent that plans the day every morning, prioritizes email, and briefs team status. You ran the Morning Coffee skill and Pulse Check skill in real work, and automated skill creation itself with the Skill Creator.

You scaled up with subagents and agent teams. You delegated tasks to specialized agents and built a structure where multiple agents collaborate in parallel. You experienced one request being distributed across five agents and processed at the same time.

With 32 hacking tips, you refined everyday work. The habit of starting in plan mode, the discipline of compacting context at 60%, techniques for running parallel sessions with Git worktrees, and settings for running agents 24 hours a day on a VPS. You let agents control the web directly through browser automation and established principles for managing code safely with Git and GitHub.

Finally, you walked the path of turning all these abilities into revenue. How to overcome imposter syndrome, the framework for securing your first client within seven days, how to set value-based prices with the PRICE model, how to assure quality through QA, and how to design professional handover and maintenance retainers. Through the real case of securing a first client in five days, you confirmed that theory works in reality.

A journey that begins with an empty folder and grows into expertise in building and operating revenue-generating agentic systems. That is the full map of this book.

■B. The learning loop: build, test, deploy, feedback, repeat

One pattern appears repeatedly throughout this journey. Build, Test, Deploy, Feedback, Repeat. This five-step cycle runs through every chapter.

The process of building a newsletter automation, running it, discovering broken HTML, fixing it, sending it again, and checking the result. The process of making a competitor analysis workflow, finding that the logo in the PDF report is not visible, fixing it, and generating it again. The process of building a fitness coach app, finding a bug where gamification points do not rise, fixing it, and testing it again. The process of delivering a pilot to the first client, receiving feedback, improving it, and converting it into a paid contract.

The forms differ, but the structure is the same. Make, check, fix, and make again. The faster this cycle turns, the higher the quality of the output becomes. The central strength of an agentic system is the speed of this cycle. A loop that used to take days in the traditional way can turn in minutes in Claude Code.

This pattern continues after you close the book. Whenever you start a new project, meet a new client, or encounter a new technology. Build-test-deploy-feedback-repeat. These five words become the rhythm of your work.

Chapter 38. AI Automation Society and Next Steps

■A. The value of community resources and networking

There is a gap between learning a technology and turning it into a business. It is possible to cross that gap alone, but crossing it with people walking the same path is much faster and less lonely.

Online communities dealing with agentic AI and Claude Code are growing quickly. Hundreds of thousands of members share workflow templates, skill files, claude.md examples, and troubleshooting experiences. When someone asks, "I am getting an error connecting this MCP server," a person who faced and solved the same problem answers. A problem that would take two hours alone can be solved in 10 minutes in a community.

The value of community is not limited to technical help. As seen in the case study in Chapter 36, one post sharing the experience of securing a first client led to a second client. In a space gathered around the same goal, your story becomes inspiration for others, and other people's stories become practical opportunities for you.

The tools and techniques covered in this book are a snapshot from the time this book was written. Technology evolves quickly. New Claude Code features are added, the MCP server ecosystem expands, skill libraries become richer, and deployment platforms become more convenient. By joining a community, you can follow these changes in real time. Learning in an environment where thousands of people experiment at the same time and share results is far more efficient than reading documents and experimenting alone.

■B. Continuous learning: responding to model evolution, new MCP servers, and tool updates

The moment you close this book, you have two choices.

The first is to use what you learned as it is. The WAT framework, skill-building method, deployment strategy, and pricing model learned in this book will remain valid for a considerable period. You can start projects right away, secure clients, and create revenue.

The second is to keep evolving based on what you learned. AI models release new versions every few months. The performance curves of Haiku, Sonnet, and Opus change. The frontend design skill learned in Chapter 17 may become unnecessary with a new model. Conversely, work that was impossible with an earlier model may become possible with a new one. If you periodically verify the validity of existing skills with the eval function of the Skill Creator covered in Chapter 22, you will not fall behind model changes.

The MCP server ecosystem is expanding quickly as well. Beyond Firecrawl, Gmail, Calendar, and Drive covered in this book, MCP servers are appearing for many services such as Slack, Notion, Asana, and Salesforce. The method for connecting a new MCP server is the same as what you learned in Chapter 16. Once you understand the principle, adapting to a new tool is only a matter of repetition.

Deployment environments are changing too. Beyond Modal and Trigger.dev, new serverless platforms may emerge. If the scheduled task feature in the Claude Code desktop app evolves, automatic execution may become possible without a separate deployment platform. The best way to notice change is to check the official Claude Code documentation (docs.anthropic.com) regularly and follow practical experience shared in the community.

I will close the final sentence of this book like this.

You now hold the whole process in your hands, starting from an empty folder, then designing, building, deploying, and monetizing an agentic workflow. The cursor is blinking in the Claude Code chat window. The next sentence is yours.