Claude Code Full Course: Autonomous Goals, MCP, and VS Code Setup

This playbook takes the mechanics from a full beginner-to-competent Claude Code course and reframes every concept specifically for marketing and sales use cases rather than software development. The underlying skills (permission modes, autonomous goals, context management, skills, MCP, version control, deployment) are identical whether you are building a SaaS app or automating a GTM workflow. This playbook translates each one.

No developer experience required. If you can follow a checklist, you can run every workflow in this playbook.

7 modules:

1. Installing Claude Code and setting up VS Code as your workspace
2. Starting, resuming, and managing sessions
3. The 4 permission modes and when to use each for GTM work
4. Autonomous goals: the /goal command for self-correcting campaign builds
5. Skills: building reusable GTM workflows once, running them forever
6. Managing context so long campaign sessions do not degrade in quality
7. MCP, CLI tools, and version control for connecting and protecting your GTM stack

Why a coding tool matters for marketing and sales

Claude Code gives an agent direct access to your local files and the ability to actually execute multi-step work rather than just describing what it would do. For GTM this means building a landing page, a lead magnet, a campaign tracker, or an outreach sequence generator that lives on your machine, gets version-controlled, and can be deployed live, all from natural language instructions rather than a chat window you copy-paste out of.

The full setup, reframed: build one dedicated GTM workspace folder rather than treating Claude Code as a generic tool with no home base.

Installing Claude Code

Search the official Claude Code documentation, use the native install command for your operating system, paste it into your terminal, and run it. Takes under a minute.

Three ways to use it once installed: the Claude Desktop app toggle (simplest, least customisable, fine for basic non-technical use), the raw terminal (most powerful, least friendly interface), or an IDE like VS Code (the recommended middle ground: full terminal power with a visual file browser alongside it).

Setting up VS Code as your GTM workspace

Install VS Code, open it, and create one dedicated project folder for your GTM work (name it after your brand or campaign, not something generic). This becomes the single home for every campaign asset, tracker, lead magnet, and outreach tool you build going forward, rather than scattering work across ad hoc chat sessions.

Open the integrated terminal (the toggle panel icon, or Control + backtick), type claude, and your session starts inside that folder with full file access. Everything Claude creates or edits lives visibly in the file explorer on the side, so you can see exactly what changed after every instruction rather than trusting a black box.

Starting, resuming, and clearing sessions

claude              # start a new session in the current folder
/resume             # resume the most recent previous session
/clear              # wipe context and start a fresh session
# Control+C twice, or click the trash icon   # terminate the current session

For GTM work specifically: keep one session per campaign or workstream rather than one giant ongoing session for everything. A campaign brief session and a lead-scoring skill session pollute each other's context if run together, and /resume lets you pick back up exactly where a specific campaign thread left off days later.

Four permission levels controlling how much Claude Code can do without asking first. For GTM work, the right default is different depending on whether you are planning a campaign or executing on one you have already approved.

The 4 modes

Plan mode: Claude researches and plans but makes no edits and runs no commands until you explicitly approve the plan. Best for: campaign architecture, a new lead magnet concept, or anything where you want to review the approach before a single file gets touched.

Accept Edits mode: Claude can create and edit files directly but still asks permission before running any command. Best for: building out campaign assets (landing page copy, email sequences, tracker spreadsheets) where file creation is safe but you still want a checkpoint before anything executes.

Auto mode: Claude edits files and runs commands automatically, with an internal safety check reviewing anything that looks risky before it runs, only surfacing to you if something genuinely needs human judgement. Best for: repeatable GTM workflows you have already validated and trust, like running a lead enrichment script on a new CSV.

Bypass Permissions mode: full autonomy, no safety review on commands at all. Best for: sandboxed test environments only, never for anything touching a live CRM, a real ad account, or real customer data.

Switch between modes with Shift+Tab inside any session.

The GTM-specific rule of thumb

Start any new campaign or workflow in Plan mode. Move to Accept Edits once you approve the plan and want assets built. Only move to Auto or Bypass once you have run the workflow successfully at least once and trust it to repeat without a checkpoint. Never run Bypass mode against anything connected to a live ad account, live CRM, or a paying customer's data.

The single most powerful mechanic in the entire course for GTM use: /goal runs Claude in a self-correcting loop against a defined success condition, rather than producing one output and stopping.

How /goal works

Normally, Claude generates an output once and hands it back to you to judge. With /goal, Claude generates the output, an internal evaluator checks it against the specific requirements you defined upfront, and if it does not meet them, the feedback goes straight back to Claude to fix and regenerate, looping automatically until the requirement is actually met. Accuracy on the final result is meaningfully higher than a single-shot prompt because the checking step never gets skipped.

The workflow: switch to Plan mode first, gather every requirement clearly (what does "done" actually look like, down to specific, checkable criteria), have Claude propose a plan based on those requirements, review and refine the plan before executing, then run /goal to let it loop autonomously until the defined bar is met.

GTM use cases for /goal

Cloning a competitor's landing page structure and copy pattern (not the exact content, the structural approach) to test against your own, with a defined pixel or structural match threshold as the success condition.

Building an interactive lead magnet (a calculator, an assessment tool) where the requirement is functional correctness across every input combination, not just "looks right."

Generating a batch of ad variations where the success condition is a specific structural checklist (hook present, CTA present, character count within range) that gets checked and regenerated until every variation passes, rather than eyeballing a batch of drafts yourself.

The fidelity question matters: decide upfront whether you need something functional (fast, loose match) or pixel-perfect (an exact, tightly bounded match with a defined tolerance, like the 2% visual difference threshold used for cloning a UI in the course). Functional is usually the right choice for a first pass; pixel-perfect costs meaningfully more time and tokens.

A skill is a reusable SOP written once that Claude follows every time a specific type of GTM task comes up, instead of you re-explaining the process from scratch each session.

What a skill actually is

A skill packages a repeatable multi-step process (read a source, research something, produce a specific output format, follow specific quality rules) into a single reference Claude loads automatically or on command. The course's own example, a bug-fix pipeline, maps directly onto a GTM equivalent: a lead-response pipeline that reads an inbound lead notification, researches the company and contact, drafts a personalised outreach sequence, logs it to your CRM, and hands off to a human for the final send-approval, all as one named, repeatable skill rather than five separate manual steps every single time a lead comes in.

Installing and finding skills

/plugin                          # browse and install available skill plugins
/reload plugins                 # apply changes after installing a new skill

A public skills directory (skills.sh, mentioned directly in the course) lists community-built skills for any AI agent, not just Claude Code. Anthropic's own front-end design skill is one real example cited: install it, then trigger it either with natural language ("renovate this landing page using the front-end design skill") or the direct slash command (/front-end-design), and it applies a full design-system-level SOP rather than a one-off styling prompt.

For a marketing team specifically, the same install mechanic applies to any GTM-focused skill: paste the skill's repository link and ask Claude to install it directly, rather than needing to manually configure anything.

Where skills live and how they differ from project instructions

Skills installed for a specific project live in a .claude folder; skills meant to be universal across any AI agent framework live in a separate .agents folder that .claude can reference. The practical distinction for a GTM team: if a workflow should only ever run inside Claude Code, keep it Claude-specific; if it should be portable to whatever tool a future team member or a different AI agent uses, build it as a universal agent skill instead.

CLAUDE.md (or the universal AGENTS.md) is your system prompt for the whole project: standing rules that apply to every session, not just one task. A campaign-specific rule ("always write in British English, never use em dashes, always include a single clear CTA") belongs here, set once, rather than repeated in every single prompt.

Uninstalling a skill

Delete the corresponding folder inside .claude or .agents, then restart the session. The skill no longer loads. No separate uninstall command needed.

The longer a session runs, the higher the token usage and the lower the output accuracy tends to get. Monitoring and managing this directly protects the quality of long campaign-planning or multi-asset-build sessions.

What context window and context rot mean

/context     # shows a detailed breakdown of current context usage by category

The context window is the total amount of conversation history and file content Claude can hold in a single session. As usage climbs (visible as a percentage in the status bar or via /context), model accuracy tends to decline, a pattern referred to in the course as context rot. For a long GTM planning session (building a full campaign brief, then a landing page, then an email sequence, all in one thread), this means the quality of the fifth asset built in a session can genuinely be worse than the quality of the first, purely from accumulated context load.

The practical rule

Watch the percentage in your status bar. Once it crosses roughly 50%, either start a fresh session for the next task, or run /compact to summarise the existing conversation and free up space.

/compact     # summarizes the current conversation to free up context space

Important caveat: /compact summarises rather than preserves everything verbatim, so some specific detail can get lost in the process. For anything where the exact wording of an earlier decision matters (a specific brand voice rule, an exact metric target agreed earlier in the session), consider whether that detail needs to be written into a persistent file (like CLAUDE.md) rather than relying on it surviving a compact.

Rewinding instead of starting over

/resume      # pick a previous session, choose "resume from summary" or "full session"
# then use the rewind option to revert to a specific earlier checkpoint

If a campaign asset went in the wrong direction a few exchanges back, rewind restores both the conversation and any files Claude changed to that earlier checkpoint, rather than forcing you to manually undo file changes and re-explain context by hand.

How Claude Code connects to the actual tools your GTM stack runs on, and the honest tradeoff between the two connection methods.

MCP vs CLI: the actual tradeoff

CLI tools: Claude runs terminal commands directly against a tool that has a command-line interface (Vercel, Stripe, and others ship one). Highly token-efficient because there is no constantly-loaded tool schema sitting in context, but less structured around access control.

MCP (Model Context Protocol): a standardised server-based bridge between Claude and a remote tool or dataset (Slack, Jira, HubSpot, a database). Consumes more tokens, because the available tool schemas are always loaded into context, but gives you real control over exactly which tools an agent can access, proper authentication boundaries, and an audit trail, which matters far more once more than one person on a team is using the same connected agent.

The practical rule from the course: choose CLI when token efficiency is the priority and you are working solo. Choose MCP when you need team-level access control, security boundaries, or an audit trail of what an agent actually did against a connected system.

GTM-relevant MCP and CLI connections

GitHub comes connected by default and needs no separate setup. For anything else in a GTM stack (a CRM, an ad platform, Slack, a deployment platform like Vercel), check whether the tool ships an official CLI, an official MCP server, or both, then paste the tool's own connection documentation link directly into a Claude Code session and ask it to set up the connection. This is the same mechanic regardless of which specific tool: find the doc, hand Claude the link, let it configure the connection rather than doing it by hand.

Version control as a safety net for GTM assets

GitHub is free and gives you a complete historical record of every version of every asset in your project folder, which matters the moment more than one person is editing campaign assets or Claude makes a change you need to roll back. Ask Claude directly to create a private repository for the current project folder and commit the current state; every future change becomes a new named commit you can inspect, diff, or revert to.

The practical use for a marketing team: paste an old commit ID to Claude and ask it to revert a specific asset to that exact previous version, rather than trying to manually reconstruct what an email sequence or landing page looked like before an unwanted edit.

All commands and the core distinctions in one place.

All commands from this course

# SESSION MANAGEMENT
claude              # start a session
/resume             # resume a previous session
/clear              # wipe context, fresh start
/rewind             # revert conversation and files to an earlier checkpoint

# PERMISSION MODES (Shift+Tab to cycle)
# Plan -> Accept Edits -> Auto -> Bypass Permissions

# AUTONOMOUS EXECUTION
/goal               # runs in a self-correcting loop against defined requirements

# CONTEXT MANAGEMENT
/context            # detailed breakdown of context usage by category
/compact            # summarizes conversation to free up context space

# SKILLS AND PLUGINS
/plugin             # browse and install skills/plugins
/reload plugins     # apply changes after installing

# MODEL SELECTION
/model              # switch between available models

The 3 core relationships

Skills are the SOP: a repeatable workflow, written once.

MCP (or CLI) is the connection: how the skill actually reaches an external tool.

Agents are the specialist: a defined role or personality that uses specific skills, which in turn call specific MCPs or CLIs.

An agent runs a skill. A skill calls an MCP or CLI tool. That is the full chain for any GTM automation built this way.

What to set up first for a GTM workflow

1. Install Claude Code, set up VS Code, create one dedicated GTM project folder
2. Write a CLAUDE.md with your standing brand and campaign rules
3. Set up version control (a private GitHub repo) before building anything you would be upset to lose
4. Start your first real campaign task in Plan mode, review before executing
5. Once a workflow proves reliable, package it as a skill so it never has to be re-explained again
6. Connect the specific tools your stack actually needs via CLI or MCP, choosing based on whether you need team-level access control