1. The Map — Projects, Plugins, Skills, and Agents
🎥 Video lesson — video not yet migrated (source Skool video id:
0e52af692aff4155a8f56efbab7c9044).
🎯 What you'll learn
→ The 3 ways to interact with Claude — Chat, CoWork, and Code — and what each one is actually for
→ The difference between a Project and a Plugin, and the exact triggers that tell you which one to build
→ The 3-layer hierarchy: Plugin, Skill, Task — and the AI First name for each
→ How Claude's official terminology maps to plain business language you already know
→ What plugin.json, SKILL.md, and individual capability files actually do
→ When to stay standalone vs package into a plugin
📦 What we're building We install a live sales plugin directly in Claude Desktop and walk through its file structure — so every layer of the hierarchy becomes concrete before you build anything yourself.
✅ What you'll leave with A clear mental model of the 3-layer hierarchy, the decision triggers that tell you when to use each layer, and a terminology map that makes any Claude plugin readable from day one.
→ Next up: CW-2 (How Plugins Actually Work) — we go deeper into how Claude loads skills, how namespacing works, and what the cache means for your edit-test loop.
Part 2 — Lesson Body
The 3 ways to interact with Claude
There are three ways to use Claude, and they get progressively more powerful — and more structured.
Claude Chat is the simplest. It's Claude on the web, your phone, or the Chat tab in Claude Desktop. Good for conversations, quick research, and asking questions. You can also build Projects here — give Claude a set of instructions and upload files it can draw on, and it'll behave like a custom assistant for that topic. Projects are a great first step.
Claude CoWork is the next level. Accessible from the Claude Desktop app, CoWork lets you browse and install plugins, connect to external tools (called MCP servers or connectors), and run agents that can actually do things — not just answer questions.
Claude Code is the developer layer. It runs in the terminal and gives you full control over how Claude interacts with your computer and your files. That's where you'll build plugins from scratch. We'll get there in CW-3.
The pattern to remember: Chat is the easiest to start, Code is the most powerful to build with, CoWork sits in between as the place most teams will actually operate day-to-day.
Projects vs Plugins — what's the difference?
Projects are great for simple, single-user use cases:
- Custom instructions loaded for every session
- Knowledge files Claude can reference
- Some conversational memory across chats
But projects have limits. You can't connect them to external tools. You can't share them with a team as a fully packaged setup. And there's no structure for repeatable, executable workflows.
When you need that — repeatable tasks, tool connections, team sharing — you build a plugin.
The practical trigger: if you've written the same prompt three times, you should make a skill for it. If you're pasting the same context into every conversation, it should live in a skill file. If you need to pull data from Google Drive, Slack, or any external system, you need a connector. That's when a project isn't enough and a plugin is the right move.
The terminology map
Before the file structure makes sense, the terminology needs to. Here's how official Claude terms map to business language:
Claude's official termAI First termWhat it actually isPluginDepartmentThe overarching bundle — a folder on your computerSkillSOP replacementA standard operating procedure for one jobCapability (.md file)TaskA single bite-sized piece of work inside a skillAgentEmployeeRuns a skill in its own isolated context windowSub-agentExtra staff memberDelegated work — Claude breaks a task into pieces and assigns themMCP ServerConnectorA connection to an external tool (Slack, Google Drive, etc.)CLAUDE.mdBusiness brainA map that tells Claude where to find information and how to behaveHookEvent ruleSomething Claude does automatically when a certain action happens
When you hear "department" in this framework, that's a plugin. When you hear "SOP replacement", that's a skill. The hierarchy is the same thing described twice — once by Anthropic's engineers, once in plain business language.
The 3-layer hierarchy
A plugin has three layers:
Layer 1 — Plugin (Department) A plugin is just a folder on your computer. It has a configuration file (plugin.json) that acts like the label on the box — it tells Claude what's inside, what the plugin is called, and where to find the agents and skills. The plugin name also drives how you invoke skills: if the plugin is called sales, you invoke its skills with /sales:skill-name.
Layer 2 — Skill (SOP) Each skill is a folder inside the plugin. The most important file in that folder is SKILL.md — this is the parent-layer file that loads when you trigger a slash command. It's literally a documented standard operating procedure written in plain language. Claude reads it and knows exactly how to behave. The SKILL.md can also reference other files in the skill folder — brand voice, audience profiles, playbooks — which Claude reads only when it needs them.
Layer 3 — Task (Capability file) Inside each skill folder, you can have individual .md files for specific tasks. These are bite-sized and focused: one file for one job. If your ideation process changes, you update one file. If you want to share a specific task across multiple plugins, you can. Version control is clean because each task is isolated.
That's it. Plugin → Skill → Task. Three layers. Everything else (agents, connectors, hooks, CLAUDE.md) supports those three layers rather than adding more.
Tour: installing and reading a live plugin
In Claude Desktop, we install the default sales plugin from Anthropic's marketplace. What we immediately see: a list of slash commands, and a skills section with expandable files.
When we open SKILL.md for the create-an-asset skill, we're reading plain English instructions. Triggering the slash command is literally copying and pasting that prompt — except we never have to copy and paste anything. The slash command does it instantly.
The skill's description field also controls auto-triggering. A trigger of auto means Claude will activate the skill automatically if your conversation is relevant — you don't even need to type the slash command.
When we look at a skill that has multiple files (like quick-reference.md alongside SKILL.md), we see how extra context works: SKILL.md tells Claude where to look for more information when it needs it. Those extra files might contain brand voice, audience definitions, or process steps. They're only loaded when relevant — keeping the active context lean.
Decision triggers — what tells you what to build next
These are the signals that tell you a new layer is needed:
SignalWhat to buildClaude makes the same mistake twiceAdd a rule to CLAUDE.mdYou keep typing the same prompt to start a taskMake it a skillYou paste the same context into every conversationAdd it to a skill's reference filesYou need data from a tool Claude can't seeAdd a connector (MCP server)A side task floods your context with output you won't reuseDelegate it to a sub-agentYou want something to happen automatically on a file eventBuild a hookA second project or team needs the same setupPackage it into a plugin
Read these as friction signals. When you feel friction, one of these applies.
Standalone skill vs plugin — when to package
Skills don't have to live inside a plugin. A standalone skill (saved to .claude/skills/) is invoked with a simple slash command and needs no plugin structure around it. That's the right starting point for personal workflows, single-project experiments, or anything simple.
Convert to a plugin when:
- A second project or team member needs the same setup
- You want to share it across a team as one installable package
- You need version control and marketplace distribution
The content assistant example in this lesson is a plugin because it gets shared with teams. If you were building it for personal use on one project, you'd start standalone and package it later when the reuse case actually arrives.
Don't over-engineer at the start. Build standalone, ship it, and package when the reuse case arrives.
What's next
goes deeper into how plugins actually load — how Claude reads the manifest, how namespacing works, how the cache interacts with your local files, and what that means for the edit-test loop.
is where you start building. You'll create the folder structure for your own plugin from scratch, and by the end of that module you'll have a working skeleton. Everything in this lesson will click into place as soon as you have real files in front of you.