Learn Claude.
This weekend.

Begin with the account and computer you already use. You do not need to buy a higher plan to learn how to give a useful brief.

1. Go to the official Claude download page in the source appendix. Choose your operating system and install the app following its installer.
2. Open Claude and sign in. Check the account or workspace name, especially if you have both personal and work access.
3. Create a folder called Claude Weekend for the templates and results you want to keep.
4. Start a new conversation and paste a small set of notes you own, or use the fictional practice notes below.
5. Give Claude a specific result to produce. Read the answer and ask for one targeted improvement.

If desktop installation is unavailable, use Claude on the web for the text and Project exercises. Check plan and administrator requirements before expecting every advanced feature.

Your practice material

The same notes will carry through the course. Download them if you want a stable file to upload later.

# Weekend practice notes — fictional example
These are invented practice inputs, not real business results.

[N1] Audience: independent service businesses using AI for everyday work.
[N2] This week's topic: turning rough meeting notes into a clear action list.
[N3] Our offer: a free meeting-notes template. No results or time-saving statistics have been measured.
[N4] Deliverables: one newsletter outline, three social post ideas, and an internal action list.
[N5] Nina will draft the outline by Tuesday. Omar will review it by Wednesday.
[N6] The publication date has not been decided.
[N7] Drafts need human approval. Do not send, post, or contact anyone.
[N8] Tone: plain, useful, friendly. Avoid hype and invented quotes.
[N9] Missing input: no customer story or validated performance data is available.

Make the first request concrete

Check that the answer keeps Nina’s and Omar’s tasks separate, leaves the publication date undecided, and makes no measured performance claim. Then ask: “Keep the facts and source IDs. Make the newsletter angle more specific to independent service businesses.”

The video calls these four “modes.” A more useful distinction is what kind of work you are doing. Projects organize ongoing context; they are not a separate model.

Try Projects

Open Projects → New Project and name it Weekly Content Lab. Add the practice notes to project knowledge and put the goal in project instructions. Start a new chat inside it and ask for the content brief. The project name alone does not provide the brief to Claude.

Try a task with a finished deliverable

Optional: try the Code tab

If Code is available, select a new empty practice folder. Use manual permissions for the first exercise. Ask for a small HTML page that displays your brief; then preview it in your browser.

If Code is unavailable, sketch the page outline in chat and mark this part for later. You can still complete the writing workflow.

A master prompt is a short working brief: who you are, who you serve, and what a good response looks like. It reduces repeated explanation when you put it where Claude can actually use it.

Fill in the useful details

Replace the brackets below. Keep the version you use every day short enough to reread. Leave task-specific details, changing deadlines, and client secrets out of an account-wide preference.

Help me work as [role] serving [audience]. My main goal is [goal].
Use plain language and [preferred level of detail]. Default to [format].
Use [spelling convention] and [time zone] when relevant.
Ask a question when missing information would materially change the result.
If a detail is optional, state a reasonable assumption and continue.
Distinguish verified facts, assumptions, and suggestions.
Do not invent sources, dates, quotes, metrics, or client results.
For writing, follow the supplied about-me.md and anti-aistyle.md files.
Before sending, publishing, deleting, or changing shared records, show the proposed result for review.
When I give you a task, return the requested deliverable and flag any unresolved gaps.

Choose where it belongs

Saving a Markdown file on your desktop does not automatically make Claude read it. Paste the relevant text, upload the file, or add it to the intended Project. A master prompt is also not an enforceable permission boundary; review the app’s access and approval settings separately.

Test whether it helps

1. Run your original brief request in a fresh chat with the relevant context.
2. Check the audience, length, format, and treatment of missing facts.
3. Replace vague instructions such as “make it good” with a specific standard such as “include owners and supplied due dates.”
4. Keep the short revision that improved the result.

Pick work you can define and check: a weekly planning brief is a better first exercise than an open-ended instruction to “run my business.” Test the task manually before scheduling it.

Write the task contract

Name the source, date range, output, frequency, time zone, and actions allowed. Decide what should happen when inputs are missing.

Create and inspect the schedule

On supported paid plans, use Scheduled → New task in the Cowork layout, or describe the recurrence in a conversation in the unified experience. Review the proposed instructions, cadence, time zone, and source access before clicking the app’s scheduling confirmation.

New cloud schedules can run while your computer is off. Tasks that depend on local files or apps run locally and need that computer available; older local schedules can retain that behavior. Use account-stored files or supported connectors for this exercise when you need a cloud run.

Check the first run

Use the task’s on-demand run control where available. Open the output and verify the source and date range. Inspect the saved task rather than relying only on a chat reply that says it is scheduled. Learn where to pause or delete it.

If scheduling is unavailable: save the task prompt and run it manually next Monday. Record the feature as unavailable rather than treating it as successfully automated.

A skill packages instructions for a repeatable task. It can teach Claude a process, output standard, or specialized workflow. It does not train a new model.

Choose a skill that serves the exercise

Look for a trusted document or writing workflow that helps create the reviewed content brief. Open Plugins in the new layout and use the skills filter. In older layouts, open Customize → Skills and browse the directory. Read the card before adding it.

1. Check the publisher, purpose, required capabilities, and included resources.
2. Enable the chosen skill. File-creation skills may require code execution and file creation to be enabled in your settings or by an administrator.
3. Run a small task with the same practice notes. Request the output format the skill supports.
4. Inspect the result for correct facts, useful structure, and an actual file if you requested one.
5. Disable the skill if it does not improve the workflow.

For downloaded community skills, inspect the complete package before enabling it. Instructions, scripts, dependencies, and network requests all matter. A familiar-looking name or a positive scan result does not guarantee harmless behavior.

Keep one before-and-after comparison: the output without the skill and the output with it. Note one measurable improvement, such as fewer formatting corrections. If installation is blocked, use the skill’s process as a manual checklist and record the limitation.

A plugin groups capabilities for a job, often including skills and connectors. Choose it for a task you already have, such as producing a content brief, rather than collecting tools without a workflow.

Make the choice in the directory

1. Open Plugins, or Customize → Plugins in the older layout.
2. Search for the job you want to complete. Read the publisher and the tools, skills, and services it includes.
3. Add one suitable option available to your account. If an organization controls installation, follow its approved library or request process.
4. Give it the same practice task. Connect an external service only if this test needs it.
5. Keep it only if the result or process is better than your baseline.

A plugin can overlap with a skill you enabled earlier. Avoid adding two tools that perform the same step without a reason. Removing a plugin also may leave its connector authorized, so review connected services separately when cleaning up.

A connector lets Claude work with an external service, such as Google Drive, Notion, or Slack. The service, your account permissions, and the granted capabilities determine what it can read or change.

Start with one harmless test document

1. Put a copy of the fictional practice notes in a document in a service you already use. Give it a distinctive name, such as Claude Weekend — Practice Notes.
2. Open the connectors filter in Plugins, or Customize → Connectors in the older layout.
3. Choose the service and connect the intended account. Read its permission screen; request the least access the service offers for the exercise.
4. Confirm that the connector is available in the conversation. Organizational approval may be required.
5. Ask Claude to find the named document and summarize it with a source link.

Open the returned link yourself. Check that it is the intended document, not a similarly named item. Verify a few facts against it. A connection does not mean Claude can find every file immediately, and different services support different actions.

If the source is missing

Check the signed-in account, the document’s sharing permissions, connector enablement, organization policy, and any sync or indexing delay. Give Claude the exact title and location. Upload the small practice file directly if you need a fallback, and record that this tests file input rather than the connector.

The video names about-me.md and anti-aistyle.md. Use the first for stable context and the second for editing preferences. Markdown is plain text with simple headings and lists.

File 1: about-me.md

Fill in the placeholders with facts you want reused. The download button creates a plain-text Markdown file in your browser; it does not upload anything.

# About me
Updated: [YYYY-MM-DD]

## My work
- Role: [your role]
- What I do: [one sentence]
- Audience: [who you help and what they need]
- Current goal: [one outcome]

## Practical preferences
- Preferred deliverables: [briefs / tables / drafts / other]
- Typical tools: [tools you actually use]
- Time zone: [your time zone]
- Spelling and units: [your preferences]

## Context boundaries
- Use only facts I supply or sources you can verify.
- Ask before saving sensitive or personal information as reusable context.
- Treat temporary project details as temporary, not permanent facts.

## Example of my work
[Paste one short example you own and want to emulate.]

File 2: anti-aistyle.md

Describe the writing you want, including a short example of your own. The name is a reminder about style; these preferences cannot guarantee AI-detector results or hide authorship.

# Writing preferences
Updated: [YYYY-MM-DD]

## Sound like this
- Clear, direct, specific, and warm.
- Use concrete examples and active verbs.
- Vary sentence length naturally.
- Keep the original meaning and preserve necessary technical terms.

## Avoid by default
- Empty introductions such as "In today's fast-paced world".
- Words such as "delve", "leverage", and "game-changing" when a simpler word works.
- Repeated "It's not X, it's Y" constructions.
- Invented statistics, fake anecdotes, and unsupported certainty.
- Repetitive summaries, decorative headings, and unnecessary emoji.

## Editing method
1. Check accuracy and meaning first.
2. Tighten structure and remove repetition.
3. Replace vague claims with specific evidence where available.
4. Proofread names, dates, links, and punctuation.
5. Flag missing facts rather than filling them in.

## My own example
[Paste 100-200 words of writing you want to sound like.]

## Exceptions
[Words or formats that are required for a client or audience.]

Make the files available

Edit the downloaded files in a plain text editor. Add the relevant versions to project knowledge or attach them to the conversation. In project instructions, explicitly ask Claude to use them. Keep private background separate from a team’s shared writing standards.

Open a fresh Project chat and repeat a small request to check that the files are in scope. Keep them updated when your role, audience, or standards change. Local filenames alone do not trigger automatic loading.

Make one shared source of context for briefs, drafts, and references. First make the workspace useful on your own; then invite the people who need access.

Set up the knowledge and instructions

1. Open your Weekly Content Lab Project or create a new team-specific one.
2. Add the current approved brief, a team-safe style guide, and the practice notes. Replace them with your own approved references when ready.
3. Use the template below as project instructions after replacing its placeholders.
4. Start a new Project chat and ask for the weekly brief. Test whether Claude can identify its sources and missing information.

# Weekly content workspace
Owner: [name]
Updated: [YYYY-MM-DD]

## Purpose
Prepare a weekly content brief for [audience] using approved references.

## Source priority
1. Current approved brief and dated reference files.
2. Supplied meeting notes and source documents.
3. Suggestions, clearly labeled as suggestions.
Flag conflicting sources; do not silently choose a fact.

## Standard output
- Audience and one useful angle
- Newsletter outline
- Three social post ideas
- Action list with owners and supplied due dates
- Missing information and source references

## Definition of done
Every factual claim has support in the inputs or a source link.
No invented results, quotes, deadlines, or customer stories.
Follow anti-aistyle.md. Keep personal about-me.md private unless intentionally shared.
Produce drafts for review. Sending, publishing, deleting, and changing shared records require approval.

## Team workflow
[Owner] maintains source files. [Reviewer] approves final drafts.
Save accepted decisions to the project knowledge; do not rely on another chat having seen them.

Share with the right access

Project sharing is available within Team and Enterprise organizations when enabled by an administrator. Open the Project’s sharing control, select the intended colleagues, and choose view or edit access. Prefer a private, invite-only Project while testing.

Project knowledge and instructions can be shared while individual chats remain private unless separately shared. Put accepted facts and decisions in the shared knowledge instead of assuming another chat has seen them. Review documents before adding personal or client-sensitive information.

If you work solo or cannot share: complete the Project setup privately and write a short handoff note naming the references, output standard, and reviewer. The exercise still produces a repeatable workspace.

Finish with a small end-to-end task

Verify the artifact or file itself. Check that N6 still has no publication date, N9 is treated as missing evidence, and no invented client success story appeared. Save the reviewed version and one lesson for next week.