Getting Started
with Claude
What's inside
Sixteen chapters covering the parts of Claude that actually matter when you're rolling it out to a team. Read in order the first time. Skim by chapter after that.
Claude's features, menus and allowances depend on your plan, your organization's settings, and staged rollouts that reach accounts at different times. Two colleagues on the same plan can see different things. Where the answer depends on your account, this guide tells you where to look instead of guessing for you. Chapter 16 covers what was left out on purpose.
- Pick one job you already reviewA recurring report, a proposal draft, a supplier comparison. Something with a known-good version you can compare the output against.
- Put its context in a projectTen minutes of setup — the reference material, the definitions, the rule for missing information. Chapter 5 covers what goes in.
- Name the reviewer before the first promptOne person who signs off the output. Without that, you cannot tell a good result from a confident one.
- 01Why this guide existsWho it's for and what to expect
- 02The two interfaces — Chat vs. CoworkWhen to use each, and why it matters
- 03Models — picking the right brainFable, Opus, Sonnet, Haiku, and what each is good for
- 04Context is the real skillThe single biggest predictor of output quality
- 05Projects — persistent workspacesIndexed memory that survives across chats
- 06Skills — repeatable workflowsDefining how a task should be done, every time
- 07Plugins — packaged capabilitySkills, resources, and assets bundled for the org
- 08Connectors — wiring Claude into your stackGitHub, Drive, SharePoint, calendars, custom systems
- 09Artifacts — making things visibleVisual deliverables you can share and reuse
- 10Research and web searchWhen to ask Claude to go deep
- 11Scheduled tasks and automationBriefings, reports, and recurring workflows
- 12Sharing and rolling out to your teamFrom one user to fifty without losing the plot
- 13Claude Code — don't be scaredThe most powerful interface, made approachable
- 14A worked example — building your first pluginPDF sheet-name extraction, end to end
- 15Common pitfallsThe traps every new team falls into
- 16Glossary and next stepsVocabulary and where to go from here
Chapter 01
Why this guide exists
If you've just been given admin keys to Claude and your job is to make it useful for the rest of your team, this guide is for you.
Claude, out of the box, is a clean slate. It works well. But the difference between a person who's been using it for an hour and a team that's been getting compounding value out of it for months comes down to a small number of concepts. None of them are technical. All of them are easy to miss if you're just opening up the chat window and typing.
This guide walks through those concepts in the order they actually matter. The questions covered are the ones every team asks when they first start using Claude seriously. The answers are repeatable, and they're what separate a team that drops Claude after two weeks from one that compounds on it for years.
Who this is for
Operations leads, IT admins, and curious early adopters at companies that have just turned Claude on. You don't need to write code. You don't need to be technical. You do need to be willing to spend a week or two getting comfortable with a few new ideas — interfaces, context windows, projects, skills, and plugins — before you scale this to your team.
What you'll get out of this
- A clear sense of when to use the Chat interface versus the Cowork interface — they look similar, but they're built for different jobs.
- An understanding of why context, not the prompt, is what makes the difference between a frustrating session and a great one.
- A working mental model for projects, skills, and plugins — the three layers that turn Claude from a chatbot into an organizational tool.
- A first concrete workflow you can package up and share with your team, end to end.
- A short list of pitfalls to avoid, drawn from rolling this out to actual teams.
How to read this
The first time through, read it in order. Each chapter builds on the previous one. After that, treat it as a reference — the contents list at the top of this page is laid out so you can jump straight to what you need.
The whole thing should take about an hour to read. Plan on another hour or two trying things in Claude as you go. The single biggest mistake teams make is treating this as theory.
Chapter 02
The two interfaces — Chat vs. Cowork
Claude has historically had two interfaces — Chat for conversation, Cowork for executing tasks on files. Anthropic is now merging them into one experience, and the merge is staged, so what your account shows depends on where that rollout has reached.
Chat — for back-and-forth thinking
Chat is what most people think of when they hear "AI assistant." You type a message, Claude responds, you reply, it adjusts. It runs in the cloud — files Claude creates here live on Anthropic's servers, attached to the conversation. Use Chat when you're researching, analyzing, exploring an idea, or working through a problem that benefits from dialogue.
Chat is the right place for:
- Research and analysis — comparing options, summarizing documents, working through unfamiliar territory.
- Drafting and editing — writing emails, reports, proposals, and refining them through feedback.
- Brainstorming — exploring an idea where you don't yet know what you want.
- Quick one-off questions — anything where you want an answer in under a minute.
Cowork — for end-to-end task execution
Cowork is the side of Claude that works directly with files on your computer. You point a session at a folder on your machine; anything Claude generates goes into that folder, and anything you drop into it, Claude can work with.
One operational detail matters more than any feature here: work that touches local files, the browser or your computer runs only while Claude Desktop is open, while cloud tasks can keep going after you close the laptop. That single line decides where a long-running job should live, and it is the thing people most often get wrong when they first delegate something substantial.
The merged experience also offers an approval setting — Manual by default, with an Auto option. Choose that deliberately, per workflow, rather than once and forever. Manual on anything that sends a message, edits a document someone relies on, or changes a business record.
The right time to use Cowork is when you have a task that's solid end-to-end — you know what you want done, you have the inputs ready, and you know the tools Claude needs to finish it. Cowork is built for execution, not exploration.
Cowork is the right place for:
- Document generation — producing reports, contracts, branded deliverables that follow a defined format.
- Batch processing of files — analyzing a folder of PDFs, renaming a set of plans, organizing a project archive.
- Workflows that touch your local file system — anything where the output needs to land somewhere specific on your machine.
- Tasks that use plugins — where plugins run depends on the surface and on your account; see Chapter 7.
The cleanest way to choose
| If you're doing this | Use this | Why |
|---|---|---|
| Asking questions, exploring | Chat | Built for dialogue and iteration |
| Generating an artifact or visual | Chat | Better artifact rendering and sharing |
| Running a defined task with files | Cowork | Direct file system access |
| Comparing three vendor proposals | Cowork | Drop the PDFs in, run a workflow |
| Researching a market or topic | Chat | Use Research mode for deep web search |
| Building or running a plugin | Cowork or Code | Check where yours is installed and available |
Do this nowOpen your own account and write down which surfaces it actually offers today. That list, not a release note, is what your team's procedure should be written against.
Chapter 03
Models — picking the right brain
Claude is not one thing. It's a family of models — each one tuned for a different kind of work. Knowing which to reach for is part of using Claude well.
The four tiers
Anthropic releases models in tiers. The names change as new versions ship, but the structure holds. Today there are four. Fable 5.1, released in September 2026, sits at the top. Below it is the Claude 5.5 family: Opus 5.5 (September 22), Sonnet 5.5 (September 28) and Haiku 5.5 (October 7). Most teams will live on Sonnet and Opus, and reach for Fable rarely, on the hardest problems.
| Tier | What it's built for | When to reach for it |
|---|---|---|
| Fable 5.1 (most capable) | Anthropic's most capable model, for demanding reasoning and long-horizon agentic work. Slower and more expensive to run than Opus. On paid plans (Pro, Max, Team, Enterprise), in Claude Code and Cowork. | The hardest knowledge work and coding problems, long multi-step agent runs, or work where Opus at higher effort still falls short |
| Opus 5.5 (flagship) | The flagship of the Claude 5.5 family, and the starting point for most serious work | Complex, ambiguous work that needs careful judgment, where being right matters more than being quick |
| Sonnet 5.5 (mid tier) | A faster, lower-cost complement to Opus 5.5 | Everyday drafting, documents, summarizing. A sensible first model to test on well-scoped work |
| Haiku 5.5 (fast tier) | Built for high-volume, cost-sensitive tasks | Repetitive, narrowly scoped work: classification, routing, summarizing at volume |
Do not assume an older model is retired because a newer one exists, and do not assume a model named in an announcement is selectable in your account. The models an account offers depend on plan and rollout; check your own picker rather than a release note.
Why this matters
Different work has different requirements. Reading a stack of scanned documents or technical plans and extracting structured information is a harder job than writing a follow-up email, and the tier you pick should reflect that. Using Opus for everything is slower and costs more, and the easy half of your work gains nothing from it. That goes double for Fable. Save it for the problems where Opus has already come up short.
When you build a skill or a plugin, you can specify which model it should use. That's the right place to make this decision once, so users aren't picking models every time.
A practical default
If you don't want to think about it, leave the default model. Claude's interface will pick a sensible one. The decision matters most when you're building a workflow that will run again and again. There, be deliberate: start with Opus 5.5 or Sonnet 5.5, and move to Fable 5.1 only when the work is long and demanding, or when Opus at higher effort still falls short.
Our recommendation: compare two suitable tiers on a handful of your own real tasks, using approved sample data. Judge by accuracy, the corrections you had to make, time saved and usage. Ignore which name sounds most advanced.
Do this nowTake five real examples of one recurring task, run them through two tiers, and count the corrections. That number is worth more than any benchmark.
Chapter 04
Context is the real skill
A few years ago, the conversation around AI was all about prompting — how to phrase the question. Claude is forgiving of an imperfect prompt. The thing that actually predicts whether you'll get a good answer is context: what it can see while it works.
Context raises the odds of a useful answer. It does not guarantee a correct one. Keep checking sources, calculations and anything that feeds a high-stakes decision, however well-briefed the conversation is. A wrong answer with good context behind it is harder to catch than an obviously uninformed one.
What context actually means
Context is everything Claude can see when it's working on your request. The conversation so far. Files you've attached. Memory from previous sessions. Tools it has access to. Documents indexed into a project. The instructions it was given when the workspace was set up.
If you start a fresh chat and ask "what should we do about the Smith proposal?" — Claude has no idea what the Smith proposal is. The chat has no context. You'll get a generic response, or it'll have to ask you a string of questions before it can help.
If you start that same chat from a project that has the Smith proposal indexed, plus the firm's standard process for reviewing proposals, plus your previous notes — Claude can answer immediately, with specifics, in the way your team works.
The context window
Every conversation has a context window — the maximum amount of information Claude can hold in mind at once, measured in tokens. How large it is depends on the model you selected, the product you are in, and what attachments and tools are in play, so this guide does not print a number or a page equivalence. A "pages of text" conversion is misleading anyway: a dense spreadsheet and a page of prose are nothing alike in tokens.
What matters is how the window behaves. A few practical rules follow:
- Start a new chat for new work. Don't keep one chat open for weeks. The window fills up, and quality drops.
- Don't dump everything into a single message. A long document attached to a chat occupies the window for the rest of that conversation, and upload limits vary by plan and file type. Put recurring material in a project instead. See Chapter 5.
- Retrieval reduces what gets loaded. Material in a project is pulled in when it looks relevant, so you are not carrying every file at all times. But what is retrieved still consumes working context.
A useful habit
Before asking Claude to do something complex, take a beat and think about what context it would need. What documents? What past examples? What constraints? What does "good" look like? You don't have to give it all of that — but the more deliberately you front-load it, the better the result.
A useful pattern is to brain-dump first. Record a voice memo, or just paste a stream of consciousness into the chat. Then ask Claude: "Before you start, ask me anything else you need to do this well." It will come back with a good list of clarifying questions. That's context engineering in action.
Chapter 05
Projects — persistent workspaces
A project is a persistent workspace inside Claude, organizing chats, uploaded knowledge and instructions around one specific job. If context is the secret to good output, projects are how you make context durable.
Projects are available across plans. How many you can create and how well knowledge retrieval works vary by plan, and sharing with colleagues comes with the team tiers. Check what your plan allows before you design a structure around them.
What goes into a project
A project has three main parts:
When to create one
Make a project the second time you find yourself doing the same kind of work, whether that's the same client, the same process or the same recurring report. The first time, just chat. The second time, set up the project so you stop re-explaining.
Indexed memory vs. session memory
This is one of the most useful distinctions in Claude, and it trips people up.
When you add a file to project memory, it gets indexed. Claude pulls in the pieces that look relevant rather than the whole document, so a project can hold far more reference material than a single conversation could carry. What it retrieves still occupies working context — retrieval changes the amount, not the fact.
When you reference a file directly in a chat, you are working against that conversation's window rather than against an index. Fine for one-off analysis; wasteful for material you will reference every week.
Both paths have limits that vary by plan and by product, and both change over time. Rather than memorizing a number, notice the symptom: when answers start drifting from material you know is present, the conversation has too much in it. Start a fresh chat in the same project.
Some projects worth building first
- Brand and style — your visual standards, voice, banned words. Every chat that touches client-facing material starts here.
- Operations — your SOPs, checklists, recurring processes. Useful for anyone who runs them.
- Department-specific — finance, marketing, estimating, contracting. Each one with its own context and instructions.
- Personal — your reading list, your strategic notes, your finances. Private projects are great for individual workflows.
Do this nowBuild one project for the recurring job you picked at the start of this guide. Put the definitions and the missing-information rule in the instructions, then check the member list.
Chapter 06
Skills — repeatable workflows
A skill is a packaged, repeatable workflow. It defines what to do, how to do it, and what good looks like — so anyone in your organization can trigger that workflow the same way, every time.
The shift in mindset
Most teams start by treating Claude like a smart intern they re-explain things to every conversation. Skills are how you stop doing that.
A skill is essentially a set of instructions that says: "When someone asks for X, here is how to do it. Here are the questions to ask first. Here are the references to use. Here is the format the output should follow."
Once a skill exists, anyone in your org can invoke it. They don't have to know the steps. They don't have to remember the format. They just call the skill, and Claude follows it.
A concrete example
Imagine your team produces conceptual budgets for early-stage projects — pricing work before a full scope is defined. The process is well understood internally: you check the project documents, you check what categories of work are involved, you check whether the supporting cost data exists. If anything is missing, you flag it before producing a number.
As a skill, that becomes:
- Trigger: User types
/conceptual-budgetor describes a budget request. - Gather inputs: Claude asks about project documents, categories of work, and available cost data. If any are missing, flag them clearly before continuing.
- Apply references: Use the team's standard cost breakdown and historical project data, both packaged with the skill.
- Produce output: A structured budget in the team's standard format, with clear notes on assumptions.
Once that's defined, anyone on the team gets to that workflow with a single command. The output is consistent. The process is enforced. The reasoning is visible.
Where skills live
Skills can be installed at three levels:
- Personal — just for you, in your settings.
- Organization — available to anyone in your workspace once an admin enables them.
- Public — Anthropic and third parties publish skill libraries that an organization can install.
For most workflows you'll build, organization-level is the right place: the team triggers them without each person setting anything up, and an update lands in one place.
Chapter 07
Plugins — packaged capability
A plugin is a bundle. It packages skills, references, and assets together into a single installable thing. If a skill is "how to do this one workflow," a plugin is "the whole department's way of working."
What's inside a plugin
Why this matters
A plugin gives every user in your organization the working method of your best practitioner, written down and ready to run, in place of whatever each person improvised in their first week.
It also has a limit. A plugin repeats a method at scale. It can't supply the judgment that made the method good, so make sure the method is right before you install it everywhere.
Browsing what's available
There are three sources of plugins:
- Anthropic's own plugins, covering common professional workflows. Browse what your installation actually offers rather than assuming a particular one is there.
- Third-party plugins, published by other developers. Catalogue size is not a useful number — what matters is whether a specific plugin does your job and who maintains it.
- Your own. Plugins you build for your team's specific needs. These are the highest-leverage ones, because nobody else can write them. You don't have to start from a blank page: fork an open library and rewrite it for your firm.
Customizing a plugin
When you install a public plugin, it comes with sensible defaults. Most plugins are designed to be customized. Once installed, you can ask Claude to walk you through tailoring it to your team's process — you'll typically fill in your own templates, references, and conventions, and the plugin's existing structure carries the rest.
The Contractor Toolkit works this way. In Claude Code, fork the repository, run /plugin marketplace add /absolute/path/to/contractor-toolkit, install contractor-initialize@contractor-toolkit and the other plugins you want, then run /initialize. The setup wizard takes about ten minutes and captures the defaults the other plugins draw on. For claude.ai or Cowork, build the zip files with the repository's ./scripts/build-dist.sh, review them, then upload them.
For any plugin, the next step is the same: ask Claude, "customize this to the way our firm works — what would I need to fill in?" It will list what to add.
Chapter 08
Connectors — wiring Claude into your stack
A connector is the bridge between Claude and another system you already use. Drive, GitHub, your project management tool, your custom internal app. Connectors are how Claude stops being an island.
The two layers — personal and organization
Connectors live at two levels:
- Organization-level connectors are turned on by an admin and made available to everyone. SharePoint, the company GitHub, the org's Google Workspace.
- Personal-level connectors are turned on by individual users for their own accounts. Your personal Gmail, your personal Drive, anything you've authenticated yourself.
Both matter. As an admin, you'll set up the organization layer once. Each user activates the personal connectors they need.
Start read-only. Make the first connected workflow retrieve and summarize, and add write access only once the team has agreed who may authorize it. Connector availability also does not mean every app supports every action — check the connector's current tool list and your organization's policy before designing a workflow around it.
Common connectors worth turning on
Not every system below has a ready-made Claude connector. Check the connector directory in your account. Where your system has no connector, a custom connector (MCP, covered below) fills the gap.
| Connector | What it unlocks |
|---|---|
| GitHub | Read, browse, and pull files from repositories — including the place where you'll store your skills and plugins. |
| Google Drive / SharePoint | Reference any file in your shared drives without manually uploading it. |
| Gmail / Outlook | Search past correspondence, draft replies in context, summarize threads. |
| Calendar | See your schedule, draft meeting prep, reschedule conflicts. |
| Slack / Teams | Pull notifications you've missed, summarize channels, search past discussions. |
| Construction project management (Procore, Autodesk Construction Cloud, CMiC) | Read RFIs, submittals and logs, summarize what's open, draft updates. |
| Accounting and job cost (QuickBooks, Sage Intacct, Sage 300 CRE) | Pull financial and job-cost data, generate reports, run quick analysis. |
Custom connectors — when off-the-shelf won't do
If your data lives somewhere without a ready-made connector — your CMiC or Viewpoint Vista data, a custom CRM, a SharePoint setup with a non-standard structure — you can build a custom connector for it. That takes more work than switching on a public one.
A custom connector lets Claude access your internal data dynamically. A user can ask "give me the RFI on project XYZ" and Claude — through the connector — pulls the file, finds the schedule, surfaces the relevant context, and answers in their language. The system feels like an extension of Claude rather than a separate tool to switch to.
A note on Microsoft 365
If your team runs on Microsoft 365 — Outlook, OneDrive, SharePoint, Teams — a Microsoft 365 connector covers a lot of ground at once. Turn it on at the org level; users authenticate individually. What each person can then reach is whatever their Microsoft 365 account already permits, so test with a deliberately restricted account before announcing it, and expect indexing and permission changes to take some time to propagate.
Do this nowTurn on one read-only connector, then have someone who should not see a particular document ask Claude for it. That negative test is worth more than ten successful retrievals.
Chapter 09
Artifacts — making things visible
An artifact is an editable output that sits alongside the conversation — a document, a diagram, a website, a dashboard, a small interactive tool. Artifacts turn an ephemeral chat into something a colleague can pick up.
Availability differs by plan and by artifact type, and paid plans add capabilities that come with their own permission and sharing choices. Treat a shared artifact as a working prototype until someone has checked its data handling, its calculations and who can reach it — not as a production tool because it looks like one.
What you can produce as an artifact
- Text artifacts — reports, memos, briefs, structured documents that you'll send to someone or save for later.
- Visual artifacts — diagrams, flowcharts, process maps, dashboards.
- Interactive artifacts — small webpages or apps that let users explore data, fill in a form, or step through a workflow.
- Code artifacts — scripts, components, snippets you can run elsewhere.
Why artifacts matter for teams
Without artifacts, work in Claude lives inside conversations — which is fine for one person, hard for a team. With artifacts, the output is a tangible thing your team can pick up and run with.
A typical pattern: a project manager runs a meeting prep workflow that produces an artifact — a one-page brief with attendee bios, agenda, recent context, and decision points. They share that artifact with the team. Anyone can open it, comment on it, act on it. The conversation that produced it doesn't matter anymore.
A useful pattern
When you want to walk a client through information, ask Claude to package it as an artifact. Discovery questionnaires, capability overviews, project plans — anything you'd otherwise build in slides or a doc, you can build as an interactive artifact. It is quick to produce and easy to revise.
Sharing artifacts across the org
If you create an artifact inside a shared project, anyone with access to that project can see and use it. This is the cleanest way to distribute work across a team — not as messages forwarded around, but as living artifacts attached to the project they belong to.
Chapter 10
Research and web search
Research is the heaviest tool Claude offers. Turn it on when you need it to go wide — searching across the web and your connected context, then returning an answer with citations you can open.
When to use it
Research is the right tool when:
- You need broad coverage of a topic — markets, competitors, regulatory landscape, recent news.
- You want cross-source verification — checking whether multiple credible outlets agree, surfacing where they disagree.
- The output needs to be citation-grounded — every claim traceable to an actual source.
- You're prepared to wait — a research run takes substantially longer than an ordinary answer, and how long depends on the question and the depth it goes to. Start it and go do something else.
How it works in practice
Turn on research, ask your question, and Claude will typically come back with clarifying questions before it starts. Answer them carefully — this is the cheapest moment to correct a misunderstanding of what you actually want.
The output is a structured report with citations. The citations are the point. Open the two or three sources carrying the claims that would most change your decision, and read them. A citation existing is not the same as a citation supporting the sentence attached to it, and no source count makes that check unnecessary.
A typical use case
Strategic market research, competitor positioning, regulatory monitoring — anything where the value is in synthesis across many sources. If you're a business owner, set Research up to track the moves in your industry weekly. If you're an analyst, lean on it for the literature review portion of any deeper analysis.
It's not the right tool for quick factual questions. For "what time does the meeting start" — just ask. Research is for the questions where the answer takes a paper to explain.
Do this nowRe-run one comparison you have already made by hand, then open its two most load-bearing citations. You will learn more from whether those hold than from the summary.
Chapter 11
Scheduled tasks and automation
Once a workflow is solid, you can put it on a schedule. Recurring work is supported, and a cloud schedule can run when your computer is off. It comes with conditions, covered below, and it is not a guaranteed delivery.
A morning briefing example
A common first scheduled task is a morning briefing that pulls your calendar, overnight email, project-tool activity and team notifications into one summary you read with your coffee. It's a good first schedule precisely because nothing depends on it: if it fails one morning, you open the four tabs yourself.
What you need before scheduling
Scheduled tasks work when the underlying workflow already works. Get it running manually first, refine it, then move it onto a schedule — and settle each of these before you do:
- Where it runs. Work touching local files, the browser or your computer requires Claude Desktop to be open; cloud tasks can continue when it is not. A schedule that silently needs a laptop to be awake is a schedule that will miss.
- Authorization and expiry. Connector authorizations do not last forever. Decide how you find out that one has lapsed, because a run that fails quietly is worse than no run.
- The output channel, and who approves it. A notification reaching you is a different thing from your business sending a client a message. Keep a person between the schedule and anything that leaves the company.
- Failure handling. What should happen when a source is unavailable or a step fails? Decide it now, not the first morning it happens.
- A trial period. Run it for a week and refine the prompt based on what actually shows up.
Other useful schedules
- Weekly business review — Friday afternoons, a roll-up of the week's key metrics, decisions, and open items.
- Tech / industry digest — Research mode runs that pull recent news in your space and summarize what changed.
- Pipeline review — sales or project pipeline status, flagged items needing follow-up.
- Compliance and review reminders — anything time-sensitive that needs to land in someone's inbox at the right moment.
Chapter 12
Sharing and rolling out to your team
The hardest part of rolling Claude out isn't the technology. It's that fifty people will each form their own habits in the first week, and most of those habits won't be the ones you want.
Two ways to share work
Within Claude, there are two ways to share — depending on what you're sharing.
Sharing a project
If you've built a useful project — say, an "Operations" workspace with your SOPs, brand guidelines, and standing instructions — you can share it with another user or with the whole org. Anyone with access can start a chat in that project and inherit all of its context, instructions, and artifacts. This is the right way to share knowledge work in progress.
Packaging a plugin
If you've built or refined a workflow that should be available beyond one project, package it as a plugin and install it at the org level. Once installed, the people in your organization can trigger it wherever plugins run on their account — which, during the current rollout, is worth confirming rather than announcing. This is the right way to share repeatable processes.
A rollout sequence that works
If you're about to onboard a meaningful chunk of your team, here's a sequence that holds up:
- Pilot with five to ten people first. Pick a mix — one or two from each major department. They become your focus group and your future internal champions.
- Document what works. As the pilot group surfaces useful workflows, write them down. The shape of your future plugin library starts here.
- Build your first two or three org-level plugins. Don't try to package everything. Pick the highest-traffic workflows and codify those. For a model of how a real library is laid out, look at the Contractor Toolkit: one repository with a marketplace file, a folder per plugin, shared references, and a build script for the claude.ai versions.
- Set sensible defaults. Mark the plugins everyone should use as install by default. Turn on memory in capabilities. Configure your brand and operations connectors at the org level.
- Run a 30-minute kickoff per cohort of new users. Walk them through Chat vs. Cowork, projects, and one or two plugins they'll use day-to-day. That's enough.
- Stay one step ahead. When questions come in from the team, answer them once and then turn the answer into either a doc, a project, or a plugin. The point is to systematize, not to be the help desk.
Chapter 13
Claude Code — don't be scared
Claude Code looks intimidating. It's a terminal — a text-based interface that runs on your computer. Most people see it once and back away. That's a mistake. Claude Code is the most powerful surface Claude has, and you don't need to be a software developer to use it.
What it actually does
Claude Code is Claude that lives in your terminal and works directly with your file system, your git repositories, your scripts, and your tools. It's the interface where Claude can do real work autonomously — analyzing folders, transforming files, packaging plugins, building integrations, automating tasks across your machine.
The reason it's powerful is that it works where your files and tools already are, rather than through a chat window. That is also the reason it needs the most deliberate setup: scope it explicitly. Point it at one project directory rather than your home folder, give it the narrowest credentials that let the job run, work on a branch you can throw away, and keep approval on anything that writes outside that scope. Treat "what may this touch?" as a decision you make, not a default you accept.
When to reach for it
| Task | Use Code? |
|---|---|
| Building or packaging a plugin | Yes — with the plugin-development tooling installed |
| Running scripts that touch many files | Yes — direct file system access |
| Working inside a code repository | Yes — designed for this |
| Automating a workflow across multiple tools | Yes — most flexible interface |
| One-off questions or drafting | No — use Chat |
| Generating shareable artifacts | No — use Chat |
The "marketing and sales people use code too" rule
Across teams that have rolled Claude out seriously, the people getting the most leverage out of Code are not the engineers. They're the operators. Marketers automating content workflows, sales people building outreach pipelines, finance people transforming spreadsheets and generating reports. The interface is just text — you describe what you want, Claude does it. You don't have to write the code yourself.
Getting comfortable
Spend an hour with Code once, on a copy of something you do not mind breaking. Ask it to do something small — summarize a directory of meeting notes, read a folder of PDFs — and watch what it does before you let it change anything. Once you see how it works, the intimidation drops away. It's the same Claude, operating where your work actually lives, which is exactly why the scoping above matters.
Do this nowMake a copy of one folder, point Code at the copy, and ask it to describe what is in there. Read-only, disposable, five minutes.
Chapter 14
A worked example — building your first plugin
Concepts only land when they connect to something concrete. Here's a worked example — building a small but useful plugin from scratch — that ties together everything in the previous chapters.
The scenario
Your team generates dozens of scanned PDFs every week — marked-up drawings, signed forms, reviewed documents — and they all land in a shared folder as "scan001.pdf," "scan002.pdf," and so on. The actual document name is printed on the first page, but every file has to be opened, read, and manually renamed before it can be filed or shared. Multiply that by the number of documents per week, the number of people doing it, and the time adds up fast.
This is a good first plugin. It's small, it's repeatable, and it demonstrates every concept this guide has covered. Whether it is worth building depends on numbers only you have: time the manual version, time the reviewed version, and count the corrections. Build the second plugin on that evidence rather than on the first one feeling faster.
Step by step
- Work on copies, and produce a plan before any rename. Copy a small batch of scanned PDFs into a scratch folder — never point the first run at the originals. Ask Claude: "Read each PDF in this folder and propose a new filename based on the document name on the first page. Output a table of current name, proposed name and your confidence. Do not rename anything yet." That dry-run manifest is the whole safety mechanism: you review the proposal, not the aftermath.
- Decide what happens in the awkward cases. Two files proposing the same name, a first page with no title, a scan too poor to read. Write the rule down — append a suffix, leave the file untouched and flag it, never overwrite — before you let anything run unattended.
- Check the model on your own documents. This is a document-reading task, so try Opus if Sonnet is struggling. Then measure it: run the dry run on a representative sample and count the proposals you had to correct. Pinning a model in a skill is a sensible default, not a correctness guarantee — it changes the odds, and nothing more.
- Apply only after approval. Once the manifest looks right, approve it and let the rename run against the copies. Verify the result, then do the originals. Keep the manifest — it is your record of what changed.
- Define the skill. Once the manual flow works, ask Claude to package it as a skill — including the dry run, the ambiguity rules and the explicit approval step. Walk through what it should ask the user up front: which folder, what naming convention, what to do when it cannot tell.
- Add references. Include a short document with examples of well-named files from your team — what your naming standard looks like. Claude follows examples better than rules.
- Package as a plugin. In Claude Code, with the plugin-development tooling installed, ask Claude: "Take the skill I built and package it as a plugin called pdf-renamer." You get a folder structure ready to push to GitHub. Check that the dry-run and approval steps survived the packaging — they are the part worth protecting.
- Push to GitHub. Commit the plugin to a private repository. This becomes your team's plugin library — every workflow you build over time lands here.
- Install at the org level. As an admin, open the plugin browser, add your repository as a source, and — if your plan offers it — mark the plugin install by default. The exact wording of those menus changes between releases, so follow what your console actually shows rather than the labels printed here.
- Train the team. Send a short note: "If you have a folder of scanned PDFs that need renaming, run /pdf-rename, review the proposed names it shows you, then approve." Two sentences, and the second one is the one that matters.
What you've just built
What you have at the end:
- A manual workflow you have checked against real files.
- A skill that codifies that workflow so it runs consistently.
- A plugin that bundles the skill with examples and references.
- A GitHub repository that becomes your team's source of truth.
- An org-level installation that puts the workflow in everyone's hands.
Now do it again, with the next workflow. And the next. The compounding starts here.
Chapter 15
Common pitfalls
Every team that rolls Claude out hits the same handful of traps. Knowing them in advance saves a lot of false starts.
Treating Claude like a search engine
The biggest single mistake. People type a single line, get a generic answer, and conclude that Claude isn't useful for their work. The fix is context — give it the right inputs and it transforms. If you're getting generic answers, you haven't given it enough to work with.
Letting one chat get too long
As a chat fills up, the context window saturates and the quality of responses drops. Don't keep one mega-thread open for weeks. Start a new chat for each meaningfully new task. If you find yourself referencing earlier parts of an old thread repeatedly, that's a signal — turn it into a project instead.
Skipping the project layer
Most teams over-rely on chats and under-use projects. The result is repetition — the same files uploaded into chat after chat, the same instructions retyped. A project takes ten minutes to set up and pays for itself within a day. Build them.
Trying to scale without packaging
Some teams wait too long to package workflows. They have one person who's good at Claude, who handles everything for everyone. That person becomes the bottleneck. The escape is plugins — encode that person's workflow so the rest of the team starts from the same method and the same format, instead of each inventing their own.
Giving Claude too much access
When using Cowork, it's tempting to point Claude at your whole Documents folder and let it work. Don't. Create dedicated folders for each project or workflow. Limit Claude's access to those. This isn't about Claude being unsafe — it's about avoiding accidents. A well-scoped folder is harder to mess up than your entire desktop.
Forgetting personal vs. organization settings
Claude has two layers of settings — what's on for the organization, and what's on for each user personally. As an admin, configuring the organization layer doesn't automatically turn things on for your users. They need to flip the personal toggles too. This catches teams off guard. A short onboarding doc that walks through the personal settings each user should turn on solves it.
Building before testing
It's easy to get excited and start building plugins for every workflow. Resist. Get the manual workflow working first, in Chat or Cowork, whichever fits the job. Test it five times. Confirm the output is consistent. Then package it. A plugin built on a flaky workflow will produce flaky output at scale.
Underestimating the rollout
The technical side of this is the easy part. The change-management side — getting your team to actually adopt new habits — takes longer than you think. Start small, support the early adopters, document the wins, and let momentum build. Don't try to make everyone a power user in week one.
Chapter 16
Glossary and next steps
A short glossary, five things to do this week, and where to go next.
Glossary
Five things to do this week
- Audit your organization settings. Confirm memory, interactive content, and the connectors you'll need are turned on. Check personal settings on your own account too.
- Build your first project. Pick something you do regularly — operations, brand, a recurring client. Set it up properly. Notice the difference.
- Try Cowork on a real task. Pick a folder of files that need analysis or transformation. Drop them into a Cowork session. See what's possible when Claude has direct file access.
- Identify your first plugin candidate. What's a workflow you do at least weekly, that has clear steps, that more than one person on your team does? That's plugin candidate number one.
- Schedule one recurring task. A morning briefing, a Friday review, a weekly digest. Pick one, set it up, refine the prompt over a week.
What's left out
Prices, plan matrices, context-window sizes, usage limits and accuracy figures are not in this guide. They change too often, or they depend on your account and your documents. Check current pricing and your own account for the first four. Measure the last one on your own work.
Edition history
A final note
Most of what's in this guide will feel obvious in three months. The interfaces, the structure, the patterns — they'll be muscle memory. The teams who do well with Claude aren't the ones with the deepest technical chops. They're the ones who treated this as a system to set up properly, kept a person on the review step, and trusted the system to compound.
Build the foundation once. Iterate on it. Let it grow.
Reviewed October 10, 2026. Plans, menus and rollouts change; what your account shows may differ.
Claude is a product of Anthropic. Nothing here is legal, engineering or security advice.