An assistant in Claude: skill, project, schedule

"Assistant" is not a Claude term. It's an everyday word for the thing that does your repetitive work. In ChatGPT it maps onto one object — a custom GPT: it has a name, an avatar, instructions, files, and it sits in a list as its own card.

Claude has no single object like that. It has separate parts, each with its own role. Every unfamiliar word below is collected in the glossary at the end.

Three parts you'll build here

• Skill — the method. How to look, what to discard, what shape the answer takes.
• Project — context and workspace. What it knows about you and your subject, where your material lives, where the conversation history stays.
• Scheduled task — initiative. When to do this unprompted.

Three parts that exist alongside

Worth knowing about, but not needed for the basic build — let the head work first.

• Connectors — hands. Access to mail, drive, messengers. Needed when the assistant must not only search the web but reach into your services: read channels, sort mail, file documents.
• Hooks — reflexes. Rules of the form "before or after this action, do that". They fire on their own.
• Subagents — division of labour. Separate helpers with narrow briefs that the main Claude hands work to.

The last two work only in Cowork — Claude's mode for long jobs involving files, a switch in the message box. For now it's enough to know it isn't a separate app and there's nothing to install; scheduling no longer needs it.

How these parts differ, and at what point an assistant becomes an agent — section 9.

Crudely: the skill is the chef's rules and recipes, the project is the kitchen with the ingredients, the schedule is the alarm clock that wakes them on Monday. What you want is the cook — and you have to assemble one from three things, because a ready-made cook doesn't come in a box.

Hence the point everything else rests on: the skill is not the assistant, it's its head. Assistant = skill + project + schedule. Most of the work falls on the skill, which is why it gets the longest section.

There's no single card: you can't send someone a link saying "here's my bot", you can't publish it for others, there's no avatar and no storefront. You assemble three things instead of one.

The skill works everywhere — in ordinary chat, in projects, in scheduled tasks — whereas a custom GPT only lives inside its own bot. It can also be exported as a file and rebuilt on someone else's account.

There are schedules and push notifications, which custom GPTs don't have at all — and that is the difference between "I asked" and "it arrived".

And the logic is edited as plain text, with versions and rollback.

When you create a skill in settings, Claude wraps it in a plugin container. You'll see it on the skill card, and it raises a fair question: why not build a plugin instead of a skill plus a project?

A plugin is packaging, not a replacement. Several skills, connectors and subagents go into it; it installs and updates as a whole rather than piece by piece. What it replaces is not the project but the way skills are stored.

A subagent is a separate helper inside Claude with one narrow brief, which the main Claude hands part of the work to and takes the result back from. One gathers material, another checks facts, a third puts it into shape. The point is that each does one thing and doesn't get in the others' way. Subagents work only in Cowork.

A hook is a rule of the form "before or after this action, do that": save a copy of a file before changing it, run a check once the text is finished. It fires by itself, unprompted. Hooks, like subagents, work only in Cowork.

Four layers and their roles

Where plugins work

Plugins are built in Claude Code — Anthropic's separate command-line tool for programmers. You won't need it: the skill is created right in Settings, and the plugin around it appears by itself. Plugins run more widely than they're built: in web chat, in the Chat tab of the desktop app, and in Cowork. The exception is hooks and subagents — those act only in Cowork and appear greyed out elsewhere. A paid plan is required: Pro, Max, Team or Enterprise.

The main limitation

A plugin can be handed to another person directly only on Team and Enterprise plans, and only if the organisation owner has enabled plugin sharing; the recipient gets it read-only.

So a plugin does not solve the handover problem. It's the same wall as with projects: a project doesn't transfer at all, a plugin doesn't transfer without Team.

When a plugin is genuinely useful

Putting several skills into one plugin makes sense mostly for yourself. One large skill that does three different things grows and starts getting in its own way: instructions for different jobs sit side by side and load together. Three small skills in one plugin behave better — each triggers on its own kind of request and contains only its own material.

Don't do it immediately: let what you've built work first. The sign that the moment has come — when editing one mode forces you to re-read the instructions for the other two so as not to break them.

Open Settings → Capabilities and enable Code execution and file creation.

You'll be copying the contents of the skill files by hand. They're in .md format — an ordinary text file, just with that extension.

On a Mac such files often open in the Claude app rather than an editor: instead of text you get a dialog asking "Attach SKILL.md to this session?". No text visible, nothing to copy from.

The right way: right-click the file → "Open With" → TextEdit or Visual Studio Code.

To stop it recurring: right-click → "Get Info" (⌘I) → "Open with" → pick the editor → "Change All…" and confirm.

If the dialog has already appeared — cancel it, nothing breaks.

Settings → Skills → the Add button. The Create a skill window opens: two fields at the top, the skill's file editor below.

Skill name — lowercase latin, hyphenated, no spaces.

Description — the most important field of all. This is what Claude reads to decide whether to apply the skill without being reminded. Too narrow a description and you'll have to summon the skill by hand every time.

Once all three files are in place — Create at the bottom of the window. The neighbouring buttons: Draft saves work in progress, Cancel discards it.

Right after creation the skill opens as a card. There's almost nothing to change here, but it's worth understanding — especially if you'll be building the same skill for someone else.

It's an on/off switch, not a publish button. Blue means the skill is enabled and in use. Switched off, it stays in the list but is never applied.

Skills are private. The card says Created by: You — the skill lives only on your account and is published nowhere. For it to appear for someone else, it is rebuilt on their account.

Skills in Claude are wrapped in plugins — a shell that can hold one skill or several, and optionally commands and service connections too. When you create a skill with Add, the wrapper is made automatically and takes the same name. It exists so the skill can be enabled as a whole, versioned and exported as a single file. There's nothing to configure inside it.

The version number goes up with every edit, and you can switch between versions on the Contents tab. A bad edit can always be rolled back.

A skill can in principle request access: to web search, to code execution, to files, to connected services — mail, drive, messengers. The card would then list what exactly it asks for.

Ours says Only adds instructions for Claude — it asks for nothing. It's pure text with rules, no permissions.

This shows whether everything landed properly: there should be three files — SKILL.md and a references folder with two files inside. The preview is on the right: the eye shows the text formatted, </> shows it as typed, with all the asterisks and hashes of the markup.

To export the skill as a file, use the ⋮ menu, Download — convenient for rebuilding the same skill on another account. So a separate backup on disk isn't strictly necessary.

Categories are filled in automatically from the content and have no effect on behaviour.

Click the ⋮ at the top right, next to the toggle. The menu has four items.

• Try in chat — open a chat and see the skill work.
• Replace — replace the skill's contents with an uploaded file.
• Download — export the skill as a file to your disk.
• Remove — delete it.

There is no edit button here. The editor you pasted into at creation no longer opens for a finished skill: the Contents tab shows the files, but for viewing only. The one way to change anything is Replace.

Open an ordinary chat — no project — and write something like this:

You're watching one thing: did the skill engage on its own, with no pointer to it. A reliable check is to add a request to state at the end of the answer whether the personal-brand-insight skill was applied.

If it didn't engage — the Description field is too narrow. Add the words people actually use for this job: "digest", "roundup", "what's interesting", "topics for posts".

Not the quality of the findings, but three things:

• was the stop-list respected — the list of subjects and names you banned in the skill: did anything slip through that shouldn't have;
• is there a "Rejected" block at the end;
• has the output drifted into retelling the news instead of making propositions.

Why these three

Judging the quality of findings on a first run is pointless: it depends on what happened in the world that day. These three depend only on the skill and show whether the mechanism works.

The stop-list is the only thing you can check objectively: the rule either fired or it didn't. "Rejected" proves the skill was actually selecting rather than taking everything. Retelling instead of propositions is a sign the output format is described more weakly than it needs to be.

If it drifted, that's fixed by editing the text of the skill. A normal part of tuning, not a fault.

You edit on your computer, not in Claude. A finished skill's card has no edit button: under the ⋮ at the top right sit Try in chat, Replace, Download and Remove. The editor you pasted into opens at creation only.

So the sequence is: edit the files in your own folder in your usual editor → zip the skill folder → ⋮ → Replace → drop the archive in → Save. A security scan runs on save. The whole contents are replaced at once, so the archive must hold every file, not just the changed ones.

It's ordinary prose, no coding. Editing is expected — you just edit your own file and send Claude the result.

Building the archive

The Replace dialog takes three things: a .zip, a .skill file, or a single .md. A single .md works only for a skill with no references/ folder: one file is the whole skill.

With more than one file you need an archive of the whole skill folder, references/ included. On a Mac: right-click the folder → Compress. On Windows: right-click → Send to → Compressed (zipped) folder. You get personal-brand-insight.zip, and that's what you drop in.

Check two things before sending: the archive contains a SKILL.md (the dialog requires it), and that file has its metadata header with name and description. Folders and nesting Claude works out by itself.

Why edits are nearly always local

Each section of the skill is responsible for something specific, and the symptom tells you where to go.

What you change is not "the text of the skill" but the section responsible for the symptom. If you can't tell which one, that is itself the diagnosis: the sections inside the skill are poorly separated, and the first job is to separate them rather than rewrite phrasing.

To confirm the description arrived, look at the Overview tab, where it's shown in full. If the text is unchanged after a replace, the file had no header.

In the sidebar, Projects → new project. The dialog has two fields and one button:

What are you working on? — the name, which becomes the project heading. Keep it short enough to recognise in a list:

What are you trying to achieve? — the description, not the instructions. One or two sentences: what this project is and what comes out of it.

Use a folder — connect a folder from your computer. More on that in 6.04.

After creation a four-part panel appears on the right. Each is for something different — one at a time.

Memory is not the same as Instructions. Instructions are what you set; memory is what Claude drew from the conversation itself. While there are few chats it stays empty, labelled "Project memory will show here after a few chats".

Press + next to Instructions and paste:

There are two routes, and you can use both at once.

A folder from your computer — preferable

Use a folder at creation, or Folder in the panel. Under the folder name it says On this computer: the project reads the files where they already live.

The point is that a file you edit on your computer doesn't have to be uploaded to Claude again. You keep the material in an ordinary folder, edit it in your usual editor, and the project works with the current version. That removes the main headache — the drift between what's on your disk and what the assistant sees.

The folder is available only while the app is open on that computer. From a phone or another machine its contents won't be there.

Context — for individual files

The + next to Context. Right when there's one file, it doesn't change, and it has no reason to live in the folder: someone else's PDF, an export, a one-off document.

The project is built — one step remains before the schedule, and it can't be skipped. The first run is done by hand, in an ordinary chat inside the project, as a single line:

Nothing else needs adding. The skill should work out what's wanted on its own and open its own reference files. If you had to prompt it — that's the first finding: the skill's Description is drawn too narrowly.

Then judge the output point by point, not by whether you like it.

The schedule comes last — once manual runs start satisfying you, not before. Otherwise something you have to redo will arrive every week.

A scheduled task is a prompt plus a time. Create it inside the project you built in section 6: open the project → New task → Set up manually → name, instructions, frequency → Save. Five minutes, once.

Because then it sees the project's material: its instructions and its uploaded files. There is nothing to pick — the task was created inside and belongs to it. That's why its window has no Work in a project row: there is no choice to make.

Create the task elsewhere — on the shared Scheduled page in the left menu — and that row appears, with the project to be named by hand. Until it is, the run works on its own: the skill is still there, the project's material is not.

The Scheduled page is for something else — it's the list of every task: what runs, when and how often. That's where you review, edit, pause and run things outside the schedule.

Check the link right after creating: run the task on demand and look at the output. The reliable sign is whatever only your material and the skill produce — here, the "Rejected" block with reasons and the skill's own rubrics. The unreliable sign is files being named: the run reads them but has no reason to mention them. If the output reads like an ordinary chat answer, without your structure, the material didn't come through.

• Every run starts from a blank slate. It remembers none of your chats, so the instruction has to carry everything: what to do, where to look, what the result should look like.
• What a run can use: web search, connected apps (Gmail, Google Drive) and files on your computer — the last only with the Require this computer switch on; see 7.04.
• Approvals. By default a run stops when an action needs your OK — and at nine in the morning nobody is there to give it. Hence automatic approval.
• You stay in control: edit, pause, run on demand, delete — at any time.

The task always sees the project's files. A folder on your disk is a different matter — that's the Require this computer switch, and it is a choice between two modes.

• On — the task runs on your computer: it reads the folders you've allowed and can save the result straight into them. But it only runs while the machine is awake; lid shut at the appointed time means the run is skipped.
• Off — the task runs in the cloud and always fires, but sees only what has been uploaded to Claude: project files and connected apps. It can't open a folder on your disk.

Material on your computer — switch it on. Delivery whatever happens matters more — upload the material into the project and leave it off.

The real task behind the assistant in this guide — both fields copy with a button.

The path is a placeholder — put your own in. The easiest way is to open the folder in Finder, press ⌥⌘C and paste, so it arrives whole and without typos. The subfolder names are yours too.

The rest of the fields: Frequency — Weekly, Monday, 10:00 (the digest is ready for the start of the week). Permissions — Automatically approve: the task runs while you're away and would otherwise stop at the first question. Require this computer — on, or the task never reaches the folder. Leave the model alone.

The channels combine. From simplest to most trouble:

1. A push on your phone — a short notice that the run is done; the text opens in its session. Easiest to set up, but the digest won't fit in a notification.
2. An email notice — the same short summary as mail.
3. The full digest by Gmail — Claude sends the result to your inbox, links and formatting intact. Needs Automatically approve: sending mail requires approval.
4. Google Drive — a new document in a Drive folder each time, readable from a phone. Automatic approval again.
5. A file on your computer — as in the example above. Needs Require this computer on and the machine awake.
6. Telegram — the cloud can't reach it: you'd need a script on your computer to pick the finished file up and send it.

The best pairing is 3 + 1: the full digest by email and a push saying it has arrived. The computer can stay off.

Whatever you choose, each run stays a separate session: visible in the left-hand list and on the Scheduled tasks page. That's where to look when a notification goes missing.

Assembling a skill is half the job. The difference between a working one and a mediocre one lies not in length but in seven things. This section is reference material: useful when you edit your skill for the second time.

1. Keep the main file light, put the weight in references

SKILL.md loads in full on every trigger. Files in the references/ folder load only when the skill decides to open them. So the main file holds the procedure: what to do, in what order, what to discard. Everything bulky — the profile of a person, examples, reference lists — moves into references.

The test is simple: if a paragraph isn't needed every time, it doesn't belong in the main file.

2. Never write the same thing in two files

The most common mistake and the least visible. You describe the audience in SKILL.md and again in a reference file — a month later you fix one and forget the other. The skill starts receiving two slightly different descriptions and works worse, and you'll never trace why: it doesn't break, it just goes dull.

The rule: every fact has one home. Everywhere else, a pointer to it.

3. The final check is a mandatory step, not advice

"Read the list before your first run" and "go through the list before every run" are different instructions, and the model will pick the first. If you have an acceptance test, it belongs as the last section of SKILL.md, with the word mandatory and a list to be walked point by point.

Say plainly there what wins in a conflict. For example: verification beats volume — four items are better than five with one unverified. Without that sentence the model will pad to the number.

4. A version line inside the file

One line under the heading: Version 2.0, 14 September 2026. As soon as the skill exists on two accounts, that's the only way to know who has which copy and why the output differs.

5. A table of contents in reference files over a hundred lines

Anthropic recommends putting a plain list of sections at the top of any file in references/ longer than a hundred lines. Not for looks: the model uses it to decide whether to read the whole file and where to look — and reads more precisely.

A list with no links, just the headings. Ten lines that save far more.

6. A README — for humans, not for the model

A separate README.md beside SKILL.md: what the skill does, what it's made of, how it's installed, which requests trigger it, what you can safely change.

The model never reads it — it isn't wired into the procedure and costs you nothing. People read it: you, six months from now, opening the folder and not remembering what this was; and whoever you hand the skill to.

7. Not every rejection is final

If your skill has a filter — a stop-list, selection criteria, anything that discards — it has to tell a final rejection from a provisional one. Otherwise the filter quietly cuts into good material and you never see it happen.

Final is when the material itself doesn't fit: the stop-list is triggered, the fact won't verify, the conclusion is obvious. Nothing to salvage there.

Provisional is when it was the first angle found that didn't fit. The subject is already covered, the conclusion repeats earlier material, the turn is banal. That's a complaint about the framing, not the material — and a second angle is nearly always right there, it just didn't come first.

The rule to put in the skill: on a provisional rejection, one attempt at a different angle is mandatory, and only then the rejection — naming both angles it tried. One line in the procedure, and it saves the most valuable thing there is: strong material that would otherwise be lost for an accidental reason.

The word "agent" is everywhere and its boundary is vague. Sorting it out matters not for the terminology: what step your build stands on determines what you are risking.

Map of the parts

The parts don't divide into major and minor. They divide by role — and the roles differ.

The plugin falls out of this row. The rest are capabilities; it adds no capability, it only packs. Which is why it has no place in the question "what is an agent made of".

The ladder

"Agent" is not a Claude term with a sharp edge, it's a description of behaviour. A working definition: a system that has a goal, chooses its own steps, acts in the world and checks its own result. By that test you get a ladder:

• skill — a tool. Method without context and without hands;
• skill + project — an assistant. Knows your subject, but works only when asked;
• + schedule — an assistant with initiative. It comes to you. But the initiative is calendar-driven: not "spotted something", but "it's Monday";
• + connectors — this is where an agent begins. The ability to act appears, rather than to produce text;
• + hooks — reaction to events, not only to the clock;
• + subagents — able to split the work into roles.

What this guide builds is not yet an agent. It's an assistant with initiative: the output is text, the decision is made by a person.

And that's a choice, not an omission. When the job is selection and judgement, a mistake should be cheap: a weak result simply doesn't get used.

The two things people confuse most

A subagent is not part of an agent, it's another agent inside. The difference is between "this employee has hands and memory" and "this department has employees". Adding a subagent doesn't extend one worker, it hires a second.

A hook is not initiative. Initiative is "decided to act". A hook is "fired because an event happened". A reflex, not a decision. People expect judgement from a hook, and it simply fires.

Skill

Instructions plus a description of when to apply them. Added once in settings and works everywhere — in chat, in projects, in scheduled tasks. Claude decides when to bring it in.

Project

A workspace: its own instructions, its own files, its own conversation history. The closest thing to a custom GPT. It can't be handed to another person — it is rebuilt on the account that needs it.

Container, also called a plugin

The shell around a skill. Created automatically, and needed so the skill can be enabled as a whole, versioned and exported as a single file.

Scheduled task

The same work, but on a schedule and without a person. Tasks live under Scheduled in the left menu; every run is a separate session from a blank slate.

Subagent

A helper inside Claude with one narrow brief: the main Claude hands it part of the work and takes back the result. Useful when there are many steps better kept apart — gather material, check facts, format. Works only in Cowork.

Hook

A rule: "before or after this action, do that". Fires automatically, unprompted: save a copy before an edit, run a check once the text is done. Works only in Cowork.

Connector

Access to an external service: mail, drive, messenger, calendar. Needed when the assistant must not only search the web but reach into your services. Connected separately from the skill.

Artifact

A page with its own address. Private until the owner shares it. Useful for showing a result by link without sending a file.

Lens

The angle the assistant is required to view every fact from. Not "what to look for" but "what to do with it once found". Lenses are what separate a set of insights from a news feed.

The first assistant is built. From here you can grow in four directions — each with a sign that the moment has come.

Deeper: sharpen the output

The most underrated direction. After the first week the skill is working at half strength, because it was tuned on guesses about yourself rather than on real results. Keep a file where you add one line after every run: what landed, what didn't. In a month those lines add up to a precise edit — worth more than any added complexity.

The sign: you keep discarding the same type of result.

Wider: a second assistant for another job

Same mechanics, only the text inside changes. The second takes an hour, because you already understand everything. Put it in the same plugin rather than starting a new one beside it.

The sign: you catch yourself explaining the same thing to Claude for the second time.

Outward: add hands

Connectors to mail, drive, messengers — so the assistant doesn't only search but reaches into your services. Remember the change in the class of risk from section 9: add them one at a time, with checks.

The sign: you keep moving the result out of chat by hand into wherever it's needed.

Onward: hand it to someone else

A skill travels as text: it is rebuilt on someone else's account from these same instructions. You'll need a description of who it works for — that file in references.

The sign: a colleague asks you to make them one.