ESC
Start typing to search across all chapters
23 min read

Chapter 2: Building Your Power Stack

What Are Plugins and Why Do They Matter?

Out of the box, Claude Code is already powerful. It can read files, run programs, search the web, and create content. But its real power comes from the ecosystem of plugins that extend what it can do and, more importantly, how well it does certain things.

Plugins are add-on packages that give Claude Code specialized skills, workflows, and capabilities. Think of them like apps on your phone — your phone works fine without Instagram, but Instagram gives it a specific capability that the base device does not have.

There are several types of components that plugins can include:

You do not need to understand the technical details of how plugins work. You just need to install the right ones and let them enhance Claude’s capabilities in the background.

Installing Plugins

Plugins are installed through plugin marketplaces. Claude Code ships with the official Anthropic marketplace (claude-plugins-official) already available — you do not have to add it manually. The canonical install command names both the plugin and the marketplace, which prevents ambiguity if two marketplaces happen to publish plugins with the same name.

There is a second Anthropic-run marketplace worth knowing about: the community marketplace (anthropics/claude-plugins-community), a catalog of over two thousand community-submitted plugins that have passed Anthropic’s automated security screening. Unlike the official marketplace, it is not available out of the box — you add it once, and from then on you install from it like any other source:

Inside Claude Code:

/plugin marketplace add anthropics/claude-plugins-community
/plugin install humanizer@claude-community

Note the suffix carefully: plugins from this marketplace install as @claude-community (the marketplace’s declared name), not @claude-plugins-community (the repository name). And apply the same judgment you would to any third-party software — the screening is automated, not a human review of every plugin update.

The recommended way — inside Claude Code (this is how most users will install plugins day-to-day):

Inside Claude Code:

/plugin install frontend-design@claude-plugins-official
/reload-plugins

The first command downloads and installs the plugin from the official marketplace. The second — /reload-plugins — activates it in your current session so you can use it immediately. Without /reload-plugins, you would have to restart Claude Code for the plugin to take effect.

The equivalent in your terminal (useful for scripts and setup files):

In your terminal:

claude plugin install frontend-design@claude-plugins-official

Both forms work. The slash-command form is smoother for daily use because you stay inside Claude Code.

Browsing and managing plugins. There is also an interactive plugin manager with four tabs (Discover, Installed, Marketplaces, Errors) that you cycle through with Tab:

Inside Claude Code:

/plugin

This is the easiest way to browse what is available, see what you have installed, and remove plugins you no longer use.

For a non-interactive list:

In your terminal:

claude plugin list

Your installed plugins are tracked in ~/.claude/settings.json under the enabledPlugins key (more on settings files later in this chapter).

The Plugins I Use Every Day

After three months of daily use, here is my recommended plugin stack for non-technical power users. I will explain what each one does and why it matters.

frontend-design — This is the plugin that consistently produces the most jaw-dropping results. When you ask Claude Code to build a website or create a visual interface, this plugin provides a comprehensive design skill that guides Claude to create production-quality, visually distinctive interfaces. Without it, Claude makes functional but generic websites. With it, Claude creates interfaces that look like they were designed by a professional. If you install only one plugin, make it this one.

document-skills — A collection of skills for working with documents: creating PDFs, manipulating spreadsheets (XLSX), building presentations (PPTX), creating Word documents (DOCX), and more. For anyone who works with documents regularly, this plugin is essential.

superpowers — A suite of advanced workflow skills including brainstorming frameworks, systematic debugging, parallel task management, plan execution, and code review. The brainstorming skill alone is worth the install — it provides a structured creative process before any major task.

commit-commands — Simplifies the process of saving your work to version control (Git/GitHub). Instead of remembering git commands, you just type /commit-commands:commit and it handles the rest. Essential if you are building websites or any project that benefits from version history.

claude-md-management — Helps you create and maintain CLAUDE.md files (your project memory — covered in depth in Chapter 3). When you have been working on a project for a while and want to capture what Claude has learned, this plugin streamlines the process.

learning-output-style — Changes how Claude communicates with you. Instead of just completing tasks silently, Claude explains what it is doing and why, turning every session into a learning experience. I keep this on because I am constantly learning new techniques from Claude’s explanations.

context7 — Gives Claude access to up-to-date documentation for any programming library or framework. When Claude needs to use a specific tool or technology, this plugin ensures it is working with current information rather than outdated training data.

playwright — Enables browser automation. Claude can open a web browser, navigate to pages, take screenshots, click buttons, and interact with websites. This is how Claude can visually verify websites it builds, scrape web content, and interact with web applications.

plugin-dev — For when you want to create your own plugins. This becomes relevant in Chapter 11 when we discuss building custom workflows.

code-review — Reviews code for bugs and quality issues. Even as a non-technical user, having Claude review the code it generates ensures higher quality outputs, especially for websites and data analysis scripts.

ralph-loop — Enables iterative refinement loops where Claude continuously improves its own output. Useful for design work where you want Claude to self-critique and enhance its results without manual intervention.

hyperframes — If you work with video (Chapter 10), this is the skill I reach for now — it replaced Remotion, the React-based video framework I used through early 2026. HyperFrames renders video from plain HTML and CSS — the same materials Claude already uses to build websites — so there is no video editor, no timeline, and no React framework to wrestle with. The hyperframes skill is the entry point: you describe the video you want, and it routes the job to the right specialized workflow (kinetic motion graphics, faceless explainers, captioned talking-head clips, product promos, and more). Because the output is HTML you can open and tweak, it fits a non-technical workflow far better than the code-heavy video frameworks that came before it. It is a standalone skill family rather than a marketplace plugin — install it once in your terminal with npx hyperframes skills update, then run /reload-plugins inside Claude Code. See the “Skills vs. Plugins vs. MCPs” section later in this chapter for the distinction.

react-pdf — Specialized PDF generation using React-PDF. When you need to create polished, custom-formatted PDF documents, this plugin produces better results than generic PDF creation.

What Are MCPs: Extending Claude Code with External Tools

MCP stands for Model Context Protocol. If plugins teach Claude new skills, MCPs give Claude new tools. They are connectors that let Claude Code communicate with external services and applications.

Here is the practical distinction: a plugin changes how Claude approaches a task (better design, better workflow). An MCP gives Claude access to a tool it did not have before (a browser, a meeting notes app, a government data API, a diagram builder).

MCPs run as separate services on your computer that Claude Code communicates with. When you add an MCP, you are essentially telling Claude: “Here is a new tool you can use. It can do X, Y, and Z.”

Installing MCPs

MCPs are added with the claude mcp add command. There are two flavors you will see in this playbook: hosted HTTP (most common for new MCPs — you give Claude a URL to connect to) and local stdio (older pattern — you give Claude a command to run a server process on your machine).

Hosted HTTP (the modern default):

In your terminal:

claude mcp add --transport http [name] [url]

For example, to add the Notion MCP using its official hosted endpoint:

In your terminal:

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

Most of the MCPs I recommend in Appendix B now use hosted HTTP. It is simpler (no server to install or update) and usually requires only a browser-based OAuth flow the first time.

Local stdio (the older pattern):

In your terminal:

claude mcp add [name] -- [command] [arguments]

Note the -- separator between the MCP name and the command to run. For example, to add the Playwright browser automation MCP (which still uses stdio):

In your terminal:

claude mcp add playwright -- npx -y @playwright/mcp@latest

You can see your configured MCPs with:

In your terminal:

claude mcp list

The MCPs I Use

Playwright (Browser Automation) — This is the most impactful MCP for non-technical users. It gives Claude a browser. Claude can navigate to websites, take screenshots of pages it builds (for verification), interact with web forms, and scrape content from the internet. When Claude builds you a website, it can use Playwright to take a screenshot and show you what it looks like without you needing to open a browser. When you need to extract data from a web page, Playwright makes it possible.

In your terminal:

claude mcp add playwright -- npx -y @playwright/mcp@latest

Excalidraw (Diagrams) — Gives Claude the ability to create hand-drawn-style diagrams. Useful for flowcharts, architecture diagrams, mind maps, and visual explanations. The diagrams have a distinctive sketched aesthetic that looks great in presentations and documents.

MoSPI Stats (Indian Government Data) — This is a specialized MCP that connects Claude to India’s Ministry of Statistics and Programme Implementation data. If you work with Indian economic data (CPI, IIP, industrial statistics, energy data, labor force surveys), this MCP lets you pull official statistics directly into your analysis. This is an example of a domain-specific MCP — there are MCPs for many different data sources and services.

Claude-in-Chrome (Browser Extension) — A Chrome extension that lets Claude Code interact with your actual Chrome browser. Unlike Playwright (which opens a separate browser), Claude-in-Chrome can see and interact with pages you have already opened, including ones that require login. This is useful for scraping content from authenticated pages, reading Google reviews, or interacting with web applications that require your credentials. After a long stretch as a limited preview, it is now generally available on all direct Anthropic plans — Pro included. If you have more than one browser connected, the /chrome command lets you pick which one Claude drives.

Granola (Meeting Notes) — Connects Claude to the Granola meeting notes service, letting Claude access your meeting transcripts and notes. If you use Granola, this MCP means Claude can reference what was discussed in recent meetings when helping with follow-up tasks.

Chrome DevTools MCP (Browser Debugging and Inspection) — This MCP connects Claude to Chrome’s built-in developer tools via the DevTools Protocol. Where Claude-in-Chrome gives Claude a visual browser, Chrome DevTools gives Claude the engineering layer underneath: network request inspection, JavaScript console access, performance profiling, Lighthouse audits, memory snapshots, and DOM manipulation. If you are building websites or web applications, this is invaluable for debugging. Claude can inspect why a page loads slowly, check for JavaScript errors, monitor API calls, and audit accessibility — all without you needing to open DevTools yourself. Think of Claude-in-Chrome as Claude seeing your browser, and Chrome DevTools as Claude diagnosing it.

Figma MCP (Code-to-Design and Design-to-Code) — This is Figma’s official MCP server, and it has become one of the most powerful tools in my stack. The standout capability: you can take any UI that Claude Code builds — on localhost, staging, or production — and push it directly into Figma as fully editable frames. Claude Code is already excellent at rapidly prototyping front-end interfaces. Now, instead of that prototype living only in code, you can capture it onto the Figma canvas where you (or your design team) can organize screens side by side, annotate what works, duplicate frames to explore variations, and refine the design without touching code. This is the code-to-design direction, and it changes the workflow fundamentally: code becomes a starting point for design exploration, not just the end product.

The MCP also works in the other direction — design-to-code. You can share a Figma frame link with Claude Code, and it reads the exact structure: components, layout, design tokens, and CSS variables. The result is code that matches your design precisely rather than Claude’s interpretation of a screenshot. With Code Connect, you can even map Figma components to your actual codebase components, so Claude reuses your existing code rather than generating new components from scratch.

Between these two directions, the gap between “what it looks like in design” and “what it looks like in code” effectively disappears. If you work with designers, collaborate with a team, or simply want to move between building and exploring without friction, this MCP is essential.

Codex MCP (Multi-Agent Orchestration) — This MCP connects OpenAI’s Codex CLI to Claude Code, letting you delegate tasks from Claude to Codex and get results back. The setup is one command:

In your terminal:

npm install -g @openai/codex && codex login
claude mcp add --scope user codex -- npx -y codex-mcp-server

Why would you want a second AI inside Claude Code? Three reasons. First, token efficiency: you can offload well-defined, bounded tasks to Codex running cheaper OpenAI models (like o4-mini), reserving Claude’s token budget for the work that benefits from its reasoning. Second, cross-verification: when you want a second opinion on code quality, logic, or security, having a structurally independent model review the work catches blind spots that a single model might miss. Third, parallel execution: Claude can send a subtask to Codex and continue working on something else simultaneously — Codex runs in its own sandbox with its own context, so it does not consume Claude’s context window.

Each Codex call spawns a genuine agent session with its own file system access and shell commands. You can even continue conversations with a specific Codex session using thread IDs. The key trade-off: Codex uses your OpenAI API key, so you are paying both Anthropic and OpenAI. But for the right workflows — bulk code generation, test writing, boilerplate — the cost savings from using a cheaper model can outweigh the dual billing.

Gemini MCP (Google’s Model as a Second Brain) — The same multi-agent pattern works with Google’s Gemini. The Gemini CLI MCP server connects Gemini to Claude Code with a richer set of tools than Codex offers: gemini for direct model queries with model selection, web-search for Google Search grounding, analyze-media for multimodal image and PDF analysis, brainstorm for structured ideation with thinking frameworks, and shell for delegating shell commands to Gemini’s sandbox. The use cases mirror Codex — delegating problems, getting a second opinion, handling context overflow — but Gemini’s web-search tool provides Google-grounded results that can be more current than Claude’s built-in search, and analyze-media adds a multimodal analysis channel that Codex lacks. If you already have access to the Gemini API, this is worth adding alongside or instead of Codex.

Kite MCP (Zerodha Stock Trading and Portfolio) — If you invest in Indian equities, this MCP is a game-changer. Built by Zerodha themselves, the Kite MCP server connects Claude Code directly to your Kite trading account. Claude can fetch your holdings, check live stock prices (LTP, OHLC, full quotes), pull historical price data, view your positions and margins, search instruments across NSE and BSE, and even place or modify orders. The hosted version requires zero setup — no API keys, no local server, no Go build. You authenticate once through Zerodha’s OAuth flow in your browser, and Claude has full access to your portfolio. I use it for portfolio analysis: asking Claude to calculate XIRR on my holdings, analyze sector allocation, compare stock performance, and pull historical data for charts. Combined with Claude’s data analysis capabilities (Chapter 6), you can go from “show me my holdings” to a full portfolio performance dashboard with XIRR calculations, sector breakdowns, and historical trend charts in a single conversation. The setup is one line:

In your terminal:

claude mcp add --transport http kite https://mcp.kite.trade/mcp

A word of caution: this MCP can place real orders on your account. Claude will always ask for confirmation before executing trades, but be deliberate about what you ask for. I recommend starting with read-only queries (holdings, prices, historical data) before exploring order placement.

The MCP ecosystem is mature and growing rapidly, with hundreds of well-maintained MCP servers available across every category imaginable. Here are the most popular ones used by the broader Claude Code community that you should know about, even if they are not part of my personal workflow.

Notion MCP (Knowledge Base) — If your team uses Notion, this MCP lets Claude read and write Notion pages, databases, and documents. You can ask Claude to pull context from a Notion doc, create meeting notes in Notion, update a project database, or draft content directly into your workspace. For teams that run their operations in Notion, this eliminates the copy-paste dance between tools.

Slack MCP (Team Communication) — Connects Claude to your Slack workspace. Claude can draft messages, summarize channel discussions, search conversation history, and help you compose responses. Useful for people who spend significant time in Slack and want Claude to help manage the information flow.

GitHub MCP (Repository Management) — The official GitHub MCP server goes beyond the basic git commands. It provides full repository management — reading issues, managing pull requests, triggering CI/CD pipelines, analyzing commit history, and reviewing code. If you work with development teams and need to interact with GitHub, this MCP gives Claude deep integration with the platform.

Zapier MCP (Cross-Platform Automation) — This is the Swiss army knife MCP. Zapier connects to thousands of apps — Gmail, Google Sheets, CRM tools, task managers, and more. With the Zapier MCP, Claude can trigger multi-step automations across platforms. For example, Claude could analyze data and then push the results to a Google Sheet, or draft an email based on research and send it through Gmail.

Supabase MCP (Database) — If you are building applications that need a database (like a web app with user data), Supabase provides an easy-to-use database with a visual interface. The MCP lets Claude design tables, write queries, and manage your data without you needing to know SQL.

Sequential Thinking MCP — This one is interesting: it gives Claude a structured, reflective thinking process for complex problems. Instead of jumping straight to an answer, Claude works through problems methodically, considering multiple angles. Useful for architectural decisions, complex analysis, and any task where you want Claude to “think harder.”

The beauty of the MCP ecosystem is that you only install what you need. Start with Playwright (which I consider essential), then add others as your workflows demand them. You can always add more later.

One More Tool: gogcli for Google Workspace

If you use Google products — Gmail, Drive, Calendar, Sheets, Docs — there is one CLI tool I recommend over any Google-specific MCP: gogcli (by steipete).

In your terminal:

brew install gogcli

gogcli gives Claude Code terminal access to your entire Google Workspace through simple, human-readable commands. Where the various Google MCPs (Drive MCP, Gmail MCP, etc.) each handle one service, gogcli handles all of them through a single tool with a consistent interface.

What makes gogcli better than the alternatives:

Since Claude Code can run terminal commands, once gogcli is installed and authenticated, Claude can search your Gmail, upload files to Drive, check your calendar, read and write to Sheets, and manage tasks — all through gog commands. This single tool replaces the need for separate Google Drive MCP, Gmail MCP, or Zapier-for-Google setups.

To authenticate after installation, run gog auth login and follow the OAuth flow. Your credentials are stored securely in your OS keyring.

Workflows I have used gogcli for:

Pulling Google Sheets data for processing. If your data lives in Google Sheets, gogcli can download it as a CSV and hand it to Claude for analysis — no manual export step. gog sheets export [sheet-id] --format csv gives Claude a local file it can immediately read, chart, and transform. This is especially useful for recurring data tasks: pull the latest numbers, run the analysis, generate the report, all from a single prompt.

Connecting skills to Google Sheets. I built a custom skill for managing workshop guest lists. Instead of maintaining a separate CSV and manually updating it, the skill uses gog sheets commands to pull attendee data directly from the shared registration sheet, process additions, and push updates back. The skill wraps the gogcli commands in a reusable workflow, so adding a new participant is a single natural language instruction.

Bulk email operations with background agents. This is where gogcli’s power really shows. I used it with a background agent to scan and label thousands of emails — the agent ran gog gmail search to find emails matching specific criteria, then gog gmail label to apply labels in bulk. Background agents are ideal for this kind of operation: you kick off the task, continue with other work, and get notified when thousands of emails have been processed. What would take hours of manual inbox management takes minutes.

Skills vs. Plugins vs. MCPs: How They Relate

This is a common source of confusion, so let me clarify the hierarchy:

A single plugin might include skills, commands, agents, hooks, and MCP configurations. Or it might include just one of these. The frontend-design plugin, for example, primarily provides a skill — a detailed instruction set for building interfaces. The commit-commands plugin provides slash commands for git operations. The playwright plugin provides both a skill for testing web apps and an MCP for browser automation.

You do not need to memorize this taxonomy. In practice, you install plugins and add MCPs, and they work in the background to make Claude better at its job.

The .claude Directory: Your AI’s Control Panel

Every Claude Code installation creates a hidden .claude directory in your home folder (~/.claude/). Think of this as the control panel for your AI assistant — everything that defines how Claude behaves, what tools it has access to, and what it remembers lives here.

Here is the structure and what each part does:

The ~/.claude/ directory structure:

~/.claude/
├── settings.json          ← User settings (permissions, plugins, hooks, model)
├── CLAUDE.md              ← Your global instructions (loaded in every session)
├── memory/
│   └── MEMORY.md          ← Auto-saved memories (things Claude "remembers")
├── projects/
│   └── [project-paths]/   ← Per-project session history
├── agents/                ← Custom agent definitions
├── skills/                ← Custom skill files
├── plugins/               ← Installed plugin files
└── todos/                 ← Task tracking files

settings.json — Your one user-level settings file. It holds everything: permissions (which commands Claude can run without asking), enabled plugins, hook configurations, your preferred model, and preferences like “always use extended thinking.” Pre-approved commands live here under a permissions.allow array.

CLAUDE.md — Your global instructions file. Anything you put in this file gets loaded into every Claude Code session, regardless of which folder you launch Claude from. This is where you put rules and context that should apply everywhere (covered in depth in Chapter 3).

memory/MEMORY.md — This is where Claude stores things you ask it to remember (also covered in the next chapter). It persists across sessions.

projects/ — Claude stores per-project session history and context here. Each project directory you have worked in gets its own subfolder with conversation history.

agents/ — Custom agent definitions (markdown files that define specialized sub-agents). These become available as agent types when Claude dispatches background tasks.

skills/ — Custom skill files that teach Claude specialized workflows. Any skill you create or customize lives here (more on this in Chapter 11).

plugins/ — Installed plugin files. When you run /plugin install, the downloaded plugin ends up here.

You will rarely need to navigate this directory manually — the /config slash command, plugins, skills, and permission approvals all handle the management. But knowing the structure helps you understand where things live when you want to customize, back up, or troubleshoot your setup.

A note on settings.local.json: You may see references to a file called settings.local.json in older documentation or playbooks. As of current Claude Code versions, this file is only used at project scope — inside a .claude/ folder at a project’s root — not at the user level. Your user-level permissions now live in ~/.claude/settings.json under the permissions key. If you have an old ~/.claude/settings.local.json left over from earlier versions, Claude Code still tolerates it, but new approvals go into settings.json.

Project-Level .claude Directories

In addition to the global ~/.claude/ directory, you can create a .claude/ folder inside any specific project directory. This creates project-level settings that only apply to Claude Code sessions opened from that project folder.

Project-level .claude/ directory structure:

your-project/
├── .claude/
│   ├── settings.json      ← Project-specific settings (MCPs, hooks, statusline)
│   ├── settings.local.json ← Project-specific permissions (auto-gitignored)
│   └── commands/          ← Project-specific slash commands
├── CLAUDE.md               ← Project instructions
└── [your project files]

The key distinction: global settings in ~/.claude/ apply to every conversation you have with Claude Code. Project settings in your-project/.claude/ only apply when you open Claude Code from within that project directory. If you open Claude Code in a different folder, those project settings do not carry over.

This is useful when different projects need different configurations. For example, you might use a specific MCP for one project but not others, or you might want stricter permissions for a production project versus a personal sandbox. You can also set project-specific statusline scripts that show project-relevant information.

Project-level settings merge with your global settings — they do not replace them. If a project has its own .claude/settings.json, those settings are layered on top of your global settings.

The Settings File: ~/.claude/settings.json

Claude Code stores its user-level configuration in a single JSON file: ~/.claude/settings.json. Understanding this file is not required, but knowing what lives in it helps when you want to customize your setup.

Everything goes in this one file: permissions (which commands Claude can run without asking), enabled plugins, hook configurations, your preferred AI model, and global preferences.

A real settings.json (simplified):

{
  "permissions": {
    "allow": [
      "Bash(yt-dlp:*)",
      "Bash(ffmpeg:*)",
      "Bash(python3:*)",
      "Bash(git:*)",
      "WebSearch"
    ],
    "deny": [
      "Read(./.env)"
    ]
  },
  "enabledPlugins": {
    "frontend-design@claude-plugins-official": true,
    "document-skills@anthropic-agent-skills": true,
    "superpowers@claude-plugins-official": true,
    "commit-commands@claude-plugins-official": true,
    "playwright@claude-plugins-official": true,
    "context7@claude-plugins-official": true,
    "claude-md-management@claude-plugins-official": true,
    "learning-output-style@claude-plugins-official": true
  },
  "alwaysThinkingEnabled": true,
  "model": "opus"
}

The permissions.allow array is the important one for day-to-day use. Every time you approve a command, Claude Code adds it here. Over time, this list grows to include the tools you use frequently — yt-dlp for video downloads, ffmpeg for media processing, python3 for data work, git operations, web search, MCP server tools, and so on. Once a tool is in this list, Claude can use it without asking you every time.

You rarely need to edit this file manually. The easiest way to change settings is the /config slash command inside Claude Code — it opens a tabbed settings interface where you can toggle options without touching JSON. Plugins, skills, and permission approvals also write to this file automatically as you work.

Permissions: How and Why to Pre-Approve Trusted Commands

Every time Claude Code wants to take an action — read a file, run a command, access the internet — it checks its permission system. For new or potentially risky actions, it asks you before proceeding.

This is a safety feature, and an important one. You do not want an AI agent running arbitrary commands on your computer without oversight. But once you have used a tool successfully several times and trust it, re-approving it every time becomes friction.

The permission system has several modes, cycleable with the Shift+Tab keyboard shortcut:

My recommendation for new users: start in default mode. Approve tools as they come up. Within a week, you will have pre-approved your most common tools, and the permission prompts will largely disappear. The experience becomes seamless — you give an instruction, and Claude executes it without interruption.

One More Setup Step: Configure Your Status Line

Before you start working, set up a status line. This gives you a persistent display at the bottom of your terminal showing critical session information — the model you are using, how much context remains, session cost, and your current working directory.

Run this in any Claude Code session:

Inside Claude Code:

/statusline show model name, context percentage, and session cost

That is it. Claude generates a script and configures it automatically. The status line updates in real time as you work. You can customize it further at any time — just describe what you want in natural language.

Why this matters from day one: Context awareness prevents the most common beginner mistake — working until Claude starts forgetting things. With the context percentage visible at all times, you know exactly when to /compact. The cost display keeps you budget-aware. The model name confirms you are running the model you expect. This one setup step eliminates an entire category of frustration.

← Chapter 1: Getting Started Without Being a DeveloperChapter 3: CLAUDE.md — Your AI's Long-Term Memory →