Six sections moving from setup to reusable brand rules, a branded deck, a daily meeting brief, and a scheduled task. Each beat has the exact prompt to run and the proof step to check before moving on.
Which funding opportunities should Riverbend prioritize before June 15?
Use these grouping hints:
Group by opportunity type. Show estimated amount, deadline, fit score, and next step.
Prompt
I am attaching this CSV file to this message:[CSV file name or source]Analyze it and add a new "Data visualization" section to design-system.html.First, inspect the actual CSV headers and rows. Choose one chart that helps answer this question:[decision or question this CSV should support]Use these column or grouping hints if they fit the file:[key columns, categories, dates, totals, or grouping rules]If those hints do not match the CSV, ignore them and choose a better chart from the actual data. Do not assume the fallback fundraising schema unless that is the file I attach.Then update design-system.html with a branded chart component.Before styling the chart, use Chrome to study these shadcn chart examples:- https://ui.shadcn.com/charts/area- https://ui.shadcn.com/charts/pieUse those pages as visual references for chart aesthetics:- card container- clear title and short description- muted grid lines- compact axis labels- one or two brand colors from DESIGN.md- legend or caption only if useful- clean report/dashboard feelDo not import shadcn, React, Recharts, Tailwind, or external libraries.Recreate the visual style in plain HTML, CSS, and inline SVG so the file still opens directly in a browser.Add a short note below the chart explaining what the chart shows and what decision it supports.
Why shadcn style?
We are copying the design pattern, not the dependency. The useful parts are the quiet card, clear title, muted grid, compact labels, and clean report feel.
That lets the preview file stay portable: one HTML file, no install step.
You need two things
Block 2 uses real inputs from your real organization. If either of these is missing, take two minutes now to grab them.
1. Your org logo, or a homepage screenshot
Ideally a .png or .svg of your logo on a transparent or clean background. If you do not have the file handy, take a screenshot of your homepage right now. Either works.
2. A one-line mission
One sentence, no jargon. One of these shapes:
“We [mission] for [audience].”
“I help [who] do [what].”
Example: “We fund frontier evidence that makes aid dollars go further for people in poverty.”
Why these two things
The logo gives Claude a visual anchor. Without it, it invents a brand feel from adjectives. With it, the design system we extract in Block 2 inherits your actual colors and shapes.
The one-liner anchors every piece of copy we generate. Decks, briefs, and any downstream prompt all trace back to this sentence. A vague mission yields vague slides. A sharp mission yields sharp slides.
If you do not have them
No problem. Do this now, before Block 2 starts:
Write one sentence describing what your org does and who it serves.
Take a screenshot of your homepage. Save it to your desktop.
That is enough. We improve both in session.
The idea
Claude is good at generating. The problem is that without rules, it generates from averages: average websites, average decks, average nonprofit language, average colors.
That is not a model failure. It is a context failure.
Before we ask Claude to make anything important, we are going to give it reusable rules. We will save those rules as DESIGN.md: a brand brief Claude can read before making decks, reports, charts, and emails.
Quick contrast
Run this intentionally under-specified prompt in a fresh chat:
Make a one-page donor update for my organization.It should feel branded, credible, and polished.Include a short headline, three impact bullets, one simple chart idea, and a closing call to action.My organization is:[one sentence about your org]
Do not give Claude your logo, colors, fonts, or examples yet. The point is to see what it invents.
Cowork may ask a follow-up question. That is useful: it is trying to flesh out the ask before it works. Answer with the shape of the artifact and the research scope, but still do not give brand rules yet:
Please make it an HTML page.Use web search to look up public information about the organization.Cover the organization from founding through today.
Save the result somewhere you can compare later. A screenshot is enough.
What to notice
The output may be useful, but it will probably feel generic. Watch for:
plausible but unearned colors
vague brand language
stock layout choices
chart styling that could belong to any organization
confident polish without real source material
This is the reason Block 2 exists.
The better version
After Block 2, you will run the same kind of task again, but with DESIGN.md in context.
The difference should be visible:
colors come from your site
typography follows your actual brand
cards, buttons, and chart styling follow the preview page
Claude has fewer choices to invent
you have a concrete artifact to inspect
That is the transition from prompting Claude to briefing Claude.
Gate before the prompt
Do this before running the Block 4 meeting brief prompt. The prompt can only work cleanly if Claude can see the same surfaces you expect it to use.
What to check
Claude in Chrome is connected in Claude Desktop.
Chrome is visible on screen.
Google Calendar opens and shows your signed-in work calendar.
Gmail opens at https://mail.google.com.
LinkedIn opens while signed in.
Slack opens while signed in, or you are ready for the brief to label Slack as blocked with the reason.
Superhuman, Apple Mail, Outlook, and other mail clients are closed for the demo.
Any tab you do not want Claude to read is closed.
Fast test
Ask Claude:
Use Chrome. Open Google Calendar, Gmail, LinkedIn, and Slack in separate tabs. Tell me whether each one is signed in. If Slack is unavailable, say the exact blocker. Do not read or summarize any private content yet.
Pass condition
Claude reports that Calendar, Gmail, and LinkedIn are signed in, Slack is either signed in or has a named blocker, and Gmail is the only mail surface open for drafting or sending.
If Calendar, Gmail, or LinkedIn fails, fix that surface before running the meeting brief. If Slack fails, keep going only if the prompt will write Slack blocked: [reason] in the source notes.
What to check
Open Gmail.
Open Drafts.
Look for a draft with subject [date] - Meeting brief (the date should be tomorrow, or the next Monday if tomorrow falls on a weekend).
Open the draft. Confirm there is one section per in-scope non-declined meeting, and each section has a short brief: who you are meeting, what they work on, one thing to know or ask, and source notes.
If all four are true, the prompt worked enough to schedule safely. The workflow produced a reviewable artifact without requiring a live send.
Source notes are part of the proof. They should say what came from Calendar, whether LinkedIn was readable, whether Gmail context was found, and whether Slack context was found, not found, or blocked.
If you explicitly approved sending, also open Sent Mail and confirm the same subject appears there. Sent Mail is optional for the workshop. Drafts is the default proof.
If it did not arrive
Try these in order:
Check Gmail Drafts again. The draft may be under the account Claude used in Chrome.
Check Gmail Sent Mail only if you approved sending. If the message was sent, the draft will disappear.
Confirm Claude used Gmail, not Superhuman. If the browser agent opened Superhuman, another mail client, or a mailto link, re-run with Gmail open at https://mail.google.com and every other mail client closed.
Confirm Claude in Chrome could access Gmail during the demo. If the Gmail tab was not logged in, Claude may have built the brief but been unable to create the draft.
Use the self-paced version. If you are reading this after the session, the step-by-step walkthrough is linked in the post-session notes.
The draft is the artifact. If you cannot find it, do not schedule the live Gmail version yet. Use the repair path, switch to the demo-safe prompt, or rerun the brief after fixing access. Block 5 should schedule a prompt you have seen produce proof.
The rule
Do not debug the browser in front of the room for more than two minutes.
The useful lesson is not “watch someone fix account permissions.” The useful lesson is how to keep the workflow bounded, visible, and honest when one source or write step fails.
Pick the branch
Use the first branch that matches what happened:
Draft exists in Gmail. Move to the draft check.
Brief exists in chat, but no Gmail draft. Treat it as a blocked write step. Save the chat output as the draft candidate, but do not schedule it yet.
Source access failed. Switch to the demo-safe path and use the sample context.
Claude guessed facts. Stop and correct the source rule before accepting any draft.
Two-minute repair prompt
Paste this if the run stalls, opens the wrong mail surface, or cannot prove the artifact:
Pause and report the exact state in four lines:1. Target date:2. Sources successfully read:3. Draft surface used:4. Proof currently visible:If Gmail Drafts is not visible within two minutes, stop trying to create the Gmail draft. Return the complete meeting brief in this chat with subject `[target date in YYYY-MM-DD format] - Meeting brief`, label it `Blocked Gmail draft`, and list the exact blocker. Do not claim a Gmail draft exists unless you verified it in Gmail Drafts.
If sources failed
Switch immediately to the demo-safe prompt in the live or demo-safe path card.
Say:
Browser access is the variable. I am switching to public-safe sample context so we can still inspect the prompt shape, source notes, proof gate, and scheduling handoff.
Then paste the demo-safe prompt.
What counts as proof
Accept these proof states:
Ready for Block 5: Gmail Drafts shows the exact subject and the brief has one section per in-scope non-declined meeting.
Good workshop fallback: Claude returns a complete plain-text draft with source notes and a visible blocker.
Not ready to schedule: Claude cannot name the sources read, cannot show the draft surface, or guessed facts.
Pass condition
The room sees either a verified Gmail draft or a clearly labeled fallback draft. Nobody leaves thinking a scheduled task is safe just because the chat sounded plausible.
Done looks like
Your saved prompt is ready for Block 5 when someone else could schedule it without asking what you meant.
Check that the note includes:
the exact prompt that produced the useful Gmail brief
the meeting scope, such as tomorrow, next Monday, first 3 non-declined meetings, or all non-declined meetings
the source rules for Calendar, LinkedIn, Gmail, and Slack status
the source-notes rule for every meeting section
what Claude should do when a source is missing, private, or blocked
the Gmail draft-first rule and Drafts proof step
optional send behavior, if you plan to approve sending later
one correction from the live run, if you had to give one
any repair-path blocker that must be fixed before scheduling
Pass condition
You can move to Block 5 when the saved note answers three questions:
What should run?
When should it run?
What proof should I check after the first scheduled run?
If any answer is missing, fix the saved prompt now. If the only proof was a plain-text fallback, do not schedule the live Gmail version yet. Block 5 should schedule a verified prompt, not invent a new one.
Done looks like
Before Claude touches Gmail, you can say exactly what it is allowed to do.
Fill this in:
For this run, Claude should brief [tomorrow / next Monday] and include [first 1-3 non-declined meetings / all non-declined meetings] using [Calendar, LinkedIn, Gmail, Slack / demo-safe context]. It may create a Gmail draft. It may send only if I explicitly approve after reviewing the draft.
Source rules
Use these rules before the prompt starts:
Calendar decides which meetings count.
The scope cap decides how many non-declined meetings Claude researches before drafting.
LinkedIn can describe external attendees only when the profile is visible.
Gmail can supply recent context and must create the final draft.
Slack should be checked when available. If it is blocked, the source notes should say Slack blocked: [reason].
Missing or private information must be labeled, not guessed.
Sending is optional. Draft proof comes first.
Pass condition
You are ready to run the prompt when four things are true:
the meeting scope is clear
the live-room cap is clear if the day has more than 3 non-declined meetings
Gmail is the only draft or send surface
the proof is Gmail Drafts, or Sent Mail only after you approve sending
Watch for these signals
During the browser run, check whether Claude is staying inside the rules you gave it.
It should do this
Read Calendar first.
Include non-declined meetings only.
Skip declined meetings.
Apply the meeting scope before researching attendees.
Treat external attendees as people with a different email domain from yours.
Research at most 3 external people per meeting.
Mark unreadable profiles as LinkedIn not available.
Search Gmail for recent context.
Search Slack for recent context, or label the exact Slack blocker.
Add source notes for each meeting.
Use Gmail for the final draft.
Verify the message in Gmail Drafts.
Stop and correct if you see this
Claude guesses a role, employer, or bio without a readable source.
Claude includes declined meetings.
Claude researches meetings outside the agreed scope.
Claude opens Superhuman, Outlook, Apple Mail, or a mailto link.
Claude keeps researching too many attendees for one meeting.
Claude leaves out source notes, or the notes claim a source was checked without visible evidence.
Claude sends before you explicitly approve it.
Claude says the draft exists before checking Gmail Drafts.
Correction prompt
Use a short correction and continue from the current step:
Pause. Follow the meeting brief rules exactly. Apply the meeting scope before researching attendees. Exclude declined meetings only. Do not guess missing LinkedIn details. Add source notes for each in-scope meeting, including Slack found, not found, or blocked. Use Gmail only for the draft. Do not send unless I explicitly approve. Continue from the current step and verify the final draft in Gmail Drafts.
Pass condition
You saw Calendar, LinkedIn where applicable, Gmail, and Slack used or labeled as blocked in the expected order. The draft includes source notes for each in-scope meeting and was verified in Gmail Drafts.
Gateway checklist
Open design-system.html again and inspect the chart section.
Check:
the chart is inside the same preview page
you can screenshot design-system.html with the chart visible
the chart values come from the CSV, not placeholder data
the colors match DESIGN.md
the title explains what the chart shows
the note below the chart explains what decision the chart supports
the page still opens directly in a browser
If the chart is generic
Ask Claude:
Revise the chart section so it uses the brand rules in DESIGN.md more clearly.Keep it quiet and report-like. Do not add decorative gradients or unrelated colors.Use the primary or accent colors from DESIGN.md and keep grid lines muted.
If the data looks wrong
Ask Claude to audit the CSV parsing:
Check the chart data against this CSV:[CSV file name or source]The chart was supposed to support this decision or question:[decision or question this CSV should support]Show me the rows and columns you used, the aggregation you performed, and the final values plotted in the chart.If the CSV has quoted fields or commas inside cells, use a proper CSV parser instead of splitting on commas.
Proof
Take a screenshot of design-system.html with the chart section visible. This is the final Block 2 artifact: your brand rules applied to real data.
Before you choose
Check that Block 2 produced enough real brand material to drive a deck:
DESIGN.md is saved in the Cowork project
DESIGN.md contains real # hex values
at least one font family is named
button, card, link, or section patterns are described
design-system.html opened successfully, or you have a screenshot of the preview
If DESIGN.md is weak, repair it before drafting:
Before we make the deck, audit DESIGN.md.Check whether it has:- real hex colors- font families- spacing or radius rules- button, card, link, or section patterns- source notes for the main visual choicesIf anything is missing, revisit the source website with Claude in Chrome and update DESIGN.md with actual computed values. Mark uncertain values as uncertain instead of inventing them.
If the room needs a clean demo path, use the fallback files:
Use Block 3 to make one small, useful deck. Do not try to make every deck your organization will ever need.
Choose one:
Organization deck: for donors, partners, board members, funders, customers, or collaborators
Personal deck: for positioning yourself, explaining your work, or opening a conversation
Use HTML as the first slide format. The next card will ask for a browser-viewable draft, not a PPTX first, because HTML is faster to inspect and revise live.
Stay in chat until the brief is specific enough to draft. The useful output from this card is not a file yet. It is a clean brief you can paste into the HTML draft prompt.
Make the HTML PPTX-ready:
one 16:9 slide-sized section per slide
real text, images, and simple shapes instead of one flattened screenshot
named slide sections and stable class names for title, body, media, footer, and notes
simple CSS that can be translated into PowerPoint shapes later
no scroll-dependent layouts, reveal animations, nested tables, or browser-only effects in the core slide content
Organization path
Use this if the deck needs to explain an organization, project, program, or product.
Copy this prompt and fill in the variables:
Using DESIGN.md and design-system.html from this project, prepare a concise brief for a 5-slide organization deck.Organization, project, program, or product:[organization name]What it does:[one sentence on what it does]Audience:[target audience]Ask or next step:[one specific ask or next step]Proof points:[one or two real proof points, or NEEDS FACT if missing]Constraints:[anything the deck should avoid, emphasize, or verify]Slide format:HTML first, with one 16:9 section per slide and clear PPTX export affordances. Keep editable text as real text. Use simple CSS, stable class names, and image fallbacks only where a visual treatment would be hard to translate into PowerPoint.Return:1. The deck goal in one sentence.2. The audience and what they need to believe.3. The strongest core message.4. A 5-slide outline with one sentence per slide.5. A short format note for the HTML draft and later PPTX export.6. Any missing facts I need before drafting the deck.Do not draft the full deck yet. Help me make the brief clear first.
Personal path
Use this if the deck needs to explain you and what you do.
Copy this prompt and fill in the variables:
Using DESIGN.md and design-system.html from this project, prepare a concise brief for a 5-slide personal deck.Name:[your name]Work:[one sentence on the work you do]Audience:[target audience]Goal:[what you are looking for]Recent highlights:[one or two recent highlights, or NEEDS FACT if missing]Constraints:[anything the deck should avoid, emphasize, or verify]Slide format:HTML first, with one 16:9 section per slide and clear PPTX export affordances. Keep editable text as real text. Use simple CSS, stable class names, and image fallbacks only where a visual treatment would be hard to translate into PowerPoint.Return:1. The deck goal in one sentence.2. The audience and what they need to understand.3. The strongest positioning message.4. A 5-slide outline with one sentence per slide.5. A short format note for the HTML draft and later PPTX export.6. Any missing facts I need before drafting the deck.Do not draft the full deck yet. Help me make the brief clear first.
Keep it small
The goal is a 5-slide working draft. You can expand it later. For now, one path, one audience, one clear next step.
What the extension does
Claude in Chrome is the browser extension that lets Claude see and control your Chrome browser as you. When the brief prompt runs, Claude opens tabs in your actual Chrome session. It reads what you would read if you opened those pages yourself.
It uses your existing logins
You do not hand Claude a password or an API key. The extension rides on the sessions already open in your browser. If you are logged into Gmail, LinkedIn, Slack, and Google Calendar in Chrome, Claude is logged into them too for the duration of the task. Log out of Chrome and Claude loses access.
That is the whole security model. If you would not want Claude to see a tab, close it before running the brief.
Speed tradeoff vs. native connectors
Two ways Claude can reach Gmail, Calendar, and Slack:
Chrome. Slow but universal. Works with anything you can log into in a browser. Each lookup is a browser tab opening, rendering, and being read. Expect minutes for a multi-meeting brief.
Native connectors. Fast but requires setup per service. Gmail, Google Calendar, and Slack each have direct API connectors in Claude. No tabs, no rendering. Seconds instead of minutes. The tradeoff is the one-time setup per connector.
For the demo we use Chrome so you can see every step. Block 5 is where you start swapping in connectors for the things you run every day.
Before the demo
Chrome is open
Claude in Chrome extension is active (icon visible, permissions granted)
You are logged into Gmail at https://mail.google.com, LinkedIn, Google Calendar, and Slack in Chrome
Superhuman or any other mail client is closed for the demo
Any tab you would not want Claude to read is closed
If the extension is not active, Claude falls back to asking you questions it cannot answer. You will see it stall rather than read.
Gmail draft rule
For this workshop, Gmail is the only approved draft or send surface. Browser agents are literal: if another mail client is already open, they may use it. Keep Gmail open, close other mail clients, and make the prompt name Gmail at https://mail.google.com.
Draft first. Sending is optional and only happens after human review.
What to check
Open Claude Desktop, go to Connectors, and look for Claude in Chrome.
You are ready when it shows a green checkmark and Chrome is open on your screen.
If it is not connected
No checkmark, or Claude in Chrome is missing?
Open the Chrome Web Store in your browser.
Search for Claude in Chrome by Anthropic. Install it.
Sign in with the same Anthropic account you use in Claude Desktop.
Return to Claude Desktop and refresh the Connectors menu. The green checkmark should appear.
If the checkmark still does not appear, quit and relaunch Claude Desktop. The Connectors list refreshes on startup.
If Claude in Chrome is still missing after relaunch, your plan, rollout state, or organization admin settings may be blocking it. Stop debugging and switch to the demo kit. Use sample DESIGN.md, sample PLAN.md, and sample fundraising CSV for the rest of Block 2.
Why this matters
The live extraction path runs through Claude in Chrome. Without the connector, the extract step can fail silently and you burn five minutes on a recoverable setup issue. Catching it here keeps the block on time.
Pass condition
You either have the green checkmark, or you have chosen the demo kit before the extraction prompt starts.
What this extension does
Claude in Chrome puts a Claude sidebar directly inside your browser. During the DESIGN.md exercise, we’ll ask Claude to browse your org’s website live and extract your brand colours and design patterns. Without the extension, Claude can only see what you paste in. With it, Claude can read any page you’re looking at.
Claude in Chrome is a beta feature for paid plans. Admin settings, browser profile issues, and rollout state can still affect what appears in your account. Treat this card as an access check, not a promise that every account will see the same option.
If your account does not show Claude in Chrome, do not spend the workshop trying to force it. Use the demo kit for Blocks 2 and 4, then repeat the live-browser path later when access is available or your admin enables it.
For the workshop, use trusted, low-risk sites only. Do not use Claude in Chrome on financial, legal, medical, or other sensitive pages during the live demo.
You’ll see a small Claude icon appear in your Chrome toolbar once the install completes.
Enable the connector in Claude Desktop
The extension doesn’t activate automatically. You need to turn it on in Claude Desktop for the conversation where you want browser access.
Open Claude Desktop and open (or create) a Cowork project.
Look for the Connectors menu, the plug icon near the top of the chat input.
Toggle Claude in Chrome to on.
Claude will now be able to browse pages you have open in the same Chrome window.
Important: install in the right profile
Chrome profiles keep their extensions separate. If you use more than one Chrome profile (common if you have a personal and a work Google account), install the extension in each profile where you want it to work.
For today’s session, install it in the profile where you are logged into LinkedIn and Google Calendar. That’s the profile Claude will use to read those pages during the exercise.
It’s working
Once installed and connected, clicking the Claude icon in your toolbar opens the sidebar. You can ask Claude about whatever page you’re currently viewing.
If it is not available
Write this in your notes:
Claude in Chrome is not available in my account yet, or my admin has not enabled it. For the live workshop I will use the demo kit path, and I will repeat the browser steps later when access is enabled.
That is a valid prework pass. The live session is about prompt shape, source discipline, proof, and fallback behavior. Browser access is only one way to run the workflow.
Why the desktop app, not the browser tab?
Claude at claude.ai is great for quick questions. But the desktop app unlocks two things the browser tab can’t do:
Claude Cowork: Claude can run tasks on your computer: reading files, controlling Chrome, running scripts, and calling external tools.
Scheduled tasks and connectors: Claude can connect to Gmail, Calendar, Slack, and scheduled workflows from one app.
Claude Code: a terminal-based interface for coding and agentic workflows. You only need to know where it lives today.
These live in one app. If you only use the browser, you’ll miss the surfaces the workshop uses for real work.
Download
Go to claude.com/download. You’ll see download options for macOS, Windows, and mobile.
Download the version for your operating system. macOS users: open the .dmg and drag Claude to your Applications folder. Windows users: run the installer.
Sign in
Open Claude Desktop and sign in with your Claude account. Use the same email and password as claude.ai.
What you’ll see after sign-in
The default view is Claude Cowork. It greets you with “Let’s knock something off your list” and shows recent tasks in the sidebar.
This is the hub. Claude Cowork is the default view. Claude Code is one click away at the top if you need it later.
What Cowork will extract automatically
In the next step, you’ll give Cowork your homepage URL and it will pull the following directly from your live site:
Logo: the image file, downloaded as logo.svg or logo.png
Font: the primary typeface, read from the page’s computed styles
Brand colours: primary and accent hex codes, extracted from headings and backgrounds
You don’t need to find these yourself. Cowork handles the extraction.
The one thing you do need to prepare
Your mission line. One sentence describing what your organisation does and who it serves. Cowork can’t write this for you. It’s the anchor for every piece of copy we generate in Blocks 2 and 3.
Two formats that work:
“We [mission] for [audience].”
“I help [who] do [what].”
Write it now. Keep it plain, no jargon, no qualifiers. Claude will refine it in session.
Example: “We fund frontier evidence that makes aid dollars go further for people in poverty.”
Worked example: anthropic.com
Logo: anthropic-logo.svg (starburst mark)
Font: Tiempos Headline (headings), Inter (body)
Primary colour: #D97757 (terracotta)
Mission: “AI safety for the long-term benefit of humanity”
If Cowork can’t reach your site
Some sites block automated scraping or have no CSS custom properties on :root. If extraction comes back incomplete, the fallback is simple: take a screenshot of your homepage, drop it into Cowork’s chat, and ask Claude to identify the colours and font from what it can see visually. It won’t be as precise, but it’s enough for Block 3.
Why connectors?
Block 4 is the live demo where Claude reads your calendar, looks up the people you’re meeting, scans Gmail for context, and drafts a meeting brief. This will work slowly with the Claude in Chrome connection but will be much faster if you set up the relevant connectors. They are point-and-click OAuth, no terminal, no install.
You need Gmail and Google Calendar for the session. Slack is useful if your team uses it, but it is not a hard blocker. If Slack is not available, the meeting brief should say Slack blocked: [reason].
Open the Connectors panel
In Claude Desktop, click the gear icon to open Settings, then click Connectors in the left sidebar.
You’ll see a list of apps Claude can connect to. Anything you’ve already connected shows Connected in blue. Anything else shows a Connect button.
Connect Gmail and Google Calendar
Click Connect next to Gmail.
A browser window opens to Google’s sign-in page. Pick the account you use for work.
Google will list the permissions Claude is asking for (read messages, read labels). Click Allow.
The browser redirects back to Claude Desktop. Gmail now shows Connected.
Repeat for Google Calendar.
If you have multiple Google accounts, double-check you picked the right one. The connector uses whichever account you signed in with.
Connect Slack
Scroll down or click Browse connectors if Slack isn’t in the visible list.
Click Connect next to Slack.
Slack will ask which workspace to connect. Pick the one your team uses.
Approve the permissions, return to Claude Desktop. Slack shows Connected.
If you’re in multiple Slack workspaces, you can connect more than one. Block 4 only needs the main one your team uses.
Then run the TEST card
After the connectors you will use show Connected, run the next TEST card. It checks that Claude can see Calendar and Gmail, plus Slack or a named Slack blocker, while asking for only access signals, not private summaries.
Do not skip the TEST card if you are joining live. A connector that looks connected but cannot return data will slow down Block 4.
Heads up
Connectors are scoped to your Claude Desktop install on this machine. If you join the live session from a different laptop, you’ll need to reconnect there.
Permissions are read-only by default. Connecting Gmail lets Claude read mail. Sending the Block 4 brief still happens through Gmail in Chrome unless your account explicitly prompts for and grants a write permission later.
Disconnect any time. The same Connectors panel has a ... menu next to each connected app where you can revoke access.
Run a connector smoke test
Open a new chat in Claude Desktop. Keep this lightweight. You are checking access, not asking Claude to summarize anything sensitive.
Paste this:
Check whether you can access my Google Calendar, Gmail, and Slack connectors.For Calendar, tell me only whether you can see today's calendar and how many events are visible.For Gmail, tell me only whether you can see my inbox and whether at least one message is visible. Do not name the sender, subject, or message content.For Slack, tell me only whether Slack is connected and whether at least one workspace or channel is visible. Do not name the workspace, channel, sender, or message content.Do not summarize private content.
Pass condition
Claude returns a real signal from Calendar and Gmail without asking you to reconnect. Slack is a pass if it returns a real signal or you explicitly write Slack blocked: not connected.
Good enough:
Calendar: event count for today.
Gmail: inbox visible, with at least one message visible.
Slack: connected and visible, or explicitly marked Slack blocked: not connected.
If something fails
Open Settings > Connectors in Claude Desktop. Disconnect and reconnect the failed app, then run the same smoke test again.
If Slack is not available in your organization, write Slack blocked: not connected in your notes. Block 4 can still run with Calendar, Gmail, and LinkedIn, but the brief should name the Slack blocker.
Done looks like
Claude gives you a compact handoff that you could paste into a new chat without losing the work.
Run this at the end of any long or messy thread:
Summarize this conversation as a handoff brief for a fresh Claude chat.Include:- goal- decisions already made- files, links, or facts referenced- open questions- risks or assumptions- the exact next prompt I should runKeep it concise enough to paste into a new chat.
Check it
The handoff is useful only if it removes clutter. Before you paste it into a new chat, confirm it has:
the actual goal, not a vague topic
the decisions you do not want Claude to reopen
the next prompt, written as something you can run
The idea
Claude can only use what fits in its context window: your messages, Claude’s replies, files you attach, and anything a connector brings into the conversation.
Think of it as a desk. The more useful material you put on the desk, the richer the work can be. But the desk has a finite size. When it gets crowded, Claude has to compress, prioritize, and sometimes loses track of details that felt obvious earlier.
#2 · Context Window
Your working memory
01,000,000 tokens
Haiku: 200k · Sonnet + Opus: 1M
CONTEXT ROT
Long conversations degrade. As the context fills, earlier turns are weighted less. Symptoms: circular responses, forgotten instructions, and repeated answers.
Compaction: Claude automatically summarises older context to make room. Starting fresh is good hygiene.
What changes in practice
Short conversations are usually sharp because the important facts are near the front of Claude’s attention.
Long conversations can degrade. This is often called context rot. Claude may forget a prior instruction, loop on an idea, contradict an earlier decision, or answer as if a file you discussed twenty turns ago is no longer present.
The fix is simple: start a fresh chat when the task changes, or ask Claude to compact the current thread into a handoff summary before you continue.
Quick quiz
For each case, decide what Claude can actually see. Then open the answer.
Case 1You ask for a shorter version of the email Claude just drafted
Keep going in the same chat.
The draft is still in the context window. Claude can revise it without you pasting the whole email again.
Case 2You open a new chat and say “use the budget number from earlier”
The budget number is not in context.
A new chat starts with an empty desk. Paste the number, attach the file, or bring over a handoff summary before asking Claude to use it.
Case 3A long chat now includes brand work, deck edits, meeting notes, and a new task
Start fresh with a handoff.
The thread may still contain the facts, but the desk is crowded. Ask Claude to summarize the useful context, then paste that summary into a new chat.
What to notice
The context window is not memory in the human sense. It is the material currently available to the conversation. Same chat means continuity. New chat means a clean desk. Long chat means useful context may be mixed with clutter.
When the conversation gets long, do a reset:
Summarize everything important from this conversation as a brief for a fresh Claude chat. Include decisions made, open questions, files or links referenced, and the next prompt I should run.
Paste that brief into a new chat. You keep the useful context and leave the clutter behind.
Gate before export
Export only after PLAN.md and branded-deck-draft.html pass this check. Fix content, fit, and brand problems while the deck is still easy to revise in HTML.
Check the draft
Open branded-deck-draft.html in a browser, then read PLAN.md. Mark each item pass or fix:
PLAN.md names the audience, ask, source files, and export criteria
the HTML file opens directly in a browser
each slide has one clear idea
titles are specific, not category labels
bullets are short enough to fit on the slide
no text overflows or gets clipped
tone sounds like the organization or person
claims are grounded in facts you provided
visual styling is implemented in HTML/CSS
colors and fonts are not invented
the final slide has a clear ask or contact path
If a slide is vague
Use a focused repair prompt:
Slide [number] is too generic.Rewrite only this slide in branded-deck-draft.html so it makes a specific claim for [audience].Keep the 5-slide structure.Replace vague phrases with concrete language.Mark any missing proof points as NEEDS FACT instead of inventing them.Update PLAN.md if the slide goal changes.
If the draft is too dense
Cut it before export:
The HTML draft is too dense for slides.Revise branded-deck-draft.html so each slide has:- one title- one sentence of main message- no more than 3 short bullets- one clear visual compositionKeep the strongest idea on each slide and move everything else out.Update PLAN.md if the outline changes.
Pass condition
You would be willing to export this deck without changing the structure, facts, or brand treatment.
Gateway checklist
Open the exported .pptx or branded-deck.html.
Check:
there are 5 slides or slide-like sections
the file opens without extra setup
text fits on every slide
slide titles are readable
colors and fonts match DESIGN.md
the revised slide is present
no placeholder text remains
the ask or contact slide is clear
If the brand drifted
Ask for a focused visual repair:
Compare the exported deck against DESIGN.md and design-system.html.Keep the deck content the same, but revise the visual styling so colors, typography, spacing, and component treatment match the brand rules more closely.Do not invent new colors or fonts.
If facts are missing
Do not let Claude invent proof:
Replace any unsupported claims with [NEEDS FACT].Show me a short list of the facts I should provide before I use this deck externally.
Proof
Take one screenshot of the opened deck. That screenshot is the Block 3 checkpoint: brand rules turned into a usable presentation artifact.
Gate before drafting
Do not start the deck prompt until you can point to each item below.
Required inputs
DESIGN.md is saved and contains real colors, fonts, and component notes.
design-system.html opens, or you have a screenshot of the rendered preview.
You chose one path: organization deck or personal deck.
You named one audience.
You named one ask or next step.
You have one or two proof points, or you are ready to mark missing proof as [NEEDS FACT].
One-sentence test
Fill this in before drafting:
I am making a [organization/personal] deck for [audience] so they can [decision or next step].
If that sentence is vague, fix it now. A vague audience produces generic slides.
If DESIGN.md is weak
Repair the source before drafting:
Audit DESIGN.md before we make the deck.Tell me whether it has:- real hex colors- font families- spacing or radius rules- button, card, link, or section patterns- source notes for the main visual choicesIf anything is missing, use Claude in Chrome to revisit the source website and update DESIGN.md with observed values. Mark uncertain values as uncertain instead of inventing them.
Pass condition
You can say the deck path, audience, ask, and one proof point out loud without rereading the guide.
Gate before export
The review ritual works only if Claude changes the named slide and leaves the rest alone.
Check the revision
Compare the revised draft against the version before your follow-up.
the named slide changed
the other four slides did not drift
the problem you named is actually fixed
the strongest original details stayed
no new facts were invented
the slide is short enough to fit
visual direction still follows DESIGN.md
If Claude changed too much
Pull it back:
You changed more than the requested slide.Restore the other slides to the prior version.Keep only the revision to slide [number].Then show me the full 5-slide draft again.
If the fix is weak
Name the narrowest next move:
Slide [number] is still not specific enough.Rewrite only the title and main message.Make the title a concrete claim, not a category label.Keep the bullets and visual direction unchanged.
Pass condition
You can identify the single slide that improved, and you can explain why the revision is better in one sentence.
What to check
Check that DESIGN.md contains enough real brand information to drive the preview page. If this file is weak, everything downstream becomes generic.
Gateway checklist
File contains # hex values
At least one font family name is present
Button, card, link, or section patterns are described
Main colors and fonts say where they came from: CSS variable, page element, or visual estimate
File is saved in the project, not just shown in chat
Why this matters
The preview page and chart section both depend on DESIGN.md. Without real hex values and a named font family, Claude falls back to invented colors and generic typography, and the whole brand fidelity story breaks.
If the check fails
Run this recovery prompt:
The DESIGN.md is missing real hex values or font names.Revisit [your org website].Use JavaScript in the browser to inspect computed styles for:- body text- the main heading- a primary button or call-to-action- a card or repeated content block- the page backgroundFor each element, extract color, backgroundColor, fontFamily, fontSize, fontWeight, and borderRadius.Update DESIGN.md with the actual values. If a value is uncertain, mark it as uncertain instead of inventing it.
Once # hex values and a font family show up, you are ready to render the preview.
Done looks like
Before Claude reads a site, write down the source and how Claude in Chrome should use it. A weak source choice produces a weak DESIGN.md even when the browser works.
Fill this in:
For this run, Claude should use [source URL] as the brand source of truth. It should use Claude in Chrome to open the page, extract [colors, fonts, spacing, components, visual patterns], and refuse to guess [voice, impact claims, strategy, missing facts].
Source rules
Use these rules before the extraction starts:
Pick one source of truth, not a pile of tabs.
Prefer a public homepage, design system page, or product page with visible UI.
Keep one sentence about the organization ready. Claude should not invent the mission.
Name at least one thing Claude must refuse to guess.
Keep the source page open in the Chrome profile where Claude in Chrome is connected.
Pass condition
You are ready to extract when four things are true:
the source URL is visible in Chrome
the extraction target is specific
the no-guess boundary is explicit
Claude in Chrome is the named way to read the page
What you need
Choose the site Claude should treat as your brand source of truth.
Best option: your organization homepage.
Fallback options:
use agenticworkflowsclub.org during the live workshop, then repeat the step with your own site later
one sentence describing what your organization does
Claude Cowork open in Claude Desktop
Claude in Chrome connected, or the demo kit chosen
You are not doing CSS for its own sake. You are giving Claude the same brand rules a designer would use: colors, type, spacing, and repeated patterns.
Live-demo cut line
Do not spend the workshop debugging one website. If Chrome cannot read the page, the site blocks automated access, or the extraction is still empty after two minutes, switch to the demo kit and keep the learning path moving.
Say:
The website is the variable, not the workflow. I am switching to the demo kit so we can still inspect DESIGN.md, render the preview, and build the deck path.
Then use sample-design.md as the DESIGN.md for the next cards. Repeat the live extraction later when the site is ready.
Self-paced proof
Before moving on, you should be able to point to:
the source website open in Chrome, or the demo kit file you will use
Claude Cowork open in Claude Desktop
Claude in Chrome connected in the Connectors menu, or the demo kit chosen
a fallback choice if the live site cannot be read
If any of those are missing, fix them before running the extraction prompt.
The idea
Create the draft artifact before the export. The approved brief from the previous card is the plan. The HTML draft makes slide fit and visual direction visible in a browser before you ask for a .pptx.
Using DESIGN.md, design-system.html, and the approved brief below, create a browser-viewable HTML draft for a 5-slide organization deck.Approved brief:[paste the organization deck brief from the previous card]Organization:[organization name]Audience:[Who this deck is for]Ask:[The specific next step or decision this deck should support]Create branded-deck-draft.html.Requirements:- standalone HTML file that opens directly in a browser- five 16:9 slide sections- one idea per slide- title, one-sentence message, and no more than 3 short bullets per slide- visual treatment implemented in HTML/CSS, not just described in notes- colors, typography, spacing, and component patterns taken from DESIGN.md- no external libraries, no invented colors, no invented fonts- text must fit on each slide without overflowAfter creating branded-deck-draft.html, use Chrome to open it and verify the design visually. Check every slide at a 16:9 desktop viewport for:- the slide rendered fully, with no blank or broken sections- no text overflow, clipping, or overlapping elements- no missing images, icons, fonts, or CSS- brand colors, typography, spacing, and component treatments match DESIGN.md and design-system.html- the layout still feels exportable to PPTXIf anything fails, revise the HTML/CSS and check it again in Chrome before you respond. In your final response, include a short "Chrome verification" note with what you checked and any issues you fixed.Use this slide structure unless the approved brief makes a better one obvious:1. Mission2. Problem we solve3. Our approach4. Impact so far5. What we are asking forDo not create a .pptx yet. Give me branded-deck-draft.html first so I can review it.
Personal prompt
Using DESIGN.md, design-system.html, and the approved brief below, create a browser-viewable HTML draft for a 5-slide personal deck.Approved brief:[paste the personal deck brief from the previous card]Name:[your name]Audience:[Who this deck is for]Goal:[What this deck should help you get or start]Create branded-deck-draft.html.Requirements:- standalone HTML file that opens directly in a browser- five 16:9 slide sections- one idea per slide- title, one-sentence message, and no more than 3 short bullets per slide- visual treatment implemented in HTML/CSS, not just described in notes- colors, typography, spacing, and component patterns taken from DESIGN.md- no external libraries, no invented colors, no invented fonts- text must fit on each slide without overflowAfter creating branded-deck-draft.html, use Chrome to open it and verify the design visually. Check every slide at a 16:9 desktop viewport for:- the slide rendered fully, with no blank or broken sections- no text overflow, clipping, or overlapping elements- no missing images, icons, fonts, or CSS- brand colors, typography, spacing, and component treatments match DESIGN.md and design-system.html- the layout still feels exportable to PPTXIf anything fails, revise the HTML/CSS and check it again in Chrome before you respond. In your final response, include a short "Chrome verification" note with what you checked and any issues you fixed.Use this slide structure unless the approved brief makes a better one obvious:1. Positioning2. Work I do3. Recent highlights4. What I am looking for5. How to reach meDo not create a .pptx yet. Give me branded-deck-draft.html first so I can review it.
What to notice
The chat brief is the operating brief. branded-deck-draft.html is the visual proof. You need both before export.
Before you move on, check:
the approved chat brief names the audience, ask, sources, and export criteria
branded-deck-draft.html opens directly in a browser
every slide has one clear idea
titles are specific, not category labels
text fits inside the slide
visual styling is implemented in HTML/CSS, not left as notes
Chrome verification confirms every slide rendered cleanly
claims are grounded in facts you provided
missing facts are marked as NEEDS FACT
colors and fonts come from DESIGN.md
If the copy is generic
Ask for a tighter pass:
This draft is too generic.Revise branded-deck-draft.html so each slide makes a specific claim about [organization or person].Keep the 5-slide structure.Replace vague phrases with concrete language.Mark any missing proof points as NEEDS FACT instead of inventing them.Do not create a .pptx yet.
If the slides are too dense
Cut before you export:
The HTML draft is too dense for slides.Revise branded-deck-draft.html so each slide has:- one title- one sentence of main message- no more than 3 short bullets- one clear visual compositionKeep the strongest idea on each slide and move everything else out.Briefly summarize any outline changes in chat.Do not create a .pptx yet.
If the branding is weak
Send Claude back to the source:
The HTML draft is not using DESIGN.md strongly enough.Revise the CSS and layout in branded-deck-draft.html so each slide uses the relevant brand rules from DESIGN.md: colors, font choices, spacing, card/button treatment, or section style.Do not invent new colors or fonts.Briefly summarize the brand rules you used in chat.Do not create a .pptx yet.
Use case
The morning brief prepares the day. The evening debrief closes it.
Schedule this only if you would actually read the email. A scheduled task is valuable when the output changes what you do next.
Prompt
Copy this into a new scheduled task:
Use Chrome for browser work. Use Gmail at https://mail.google.com for all email searching and for creating the final draft. If any email link or browser state opens somewhere else, open Gmail instead.Look at my Google Calendar for today. List the non-declined meetings I attended.Open Gmail in Chrome at https://mail.google.com and find the emails I sent and received today that are worth noting: decisions made, requests received, and threads that need a reply. Ignore newsletters, automated notifications, and calendar invites.Open Slack in Chrome and check my most active Slack channels for today's key threads. If Slack cannot be reached or I am not logged in, note `Slack blocked: [reason]` once at the top of the email and continue with Calendar and Gmail.If today had no meetings and no notable email activity, write a 1-line note saying so and skip the rest of the debrief.Otherwise write a 3-bullet debrief:- What I worked on or decided today that matters- What needs a follow-up tomorrow- One thing I can clear or prepare now to make tomorrow easierCreate a Gmail draft addressed to me. The subject line must be today's date in YYYY-MM-DD format followed by ` - End of day`. For example, if today is April 25 2026, the subject is `2026-04-25 - End of day`. Substitute the actual date. Do not send the literal words `today's date`.Before you finish, verify the message exists in Gmail Drafts. Do not send it unless I explicitly approve after reviewing the draft. If Gmail blocks draft creation, tell me exactly what is blocking the action and do not claim it worked.
Schedule
Set this task for weekdays at 6:00 PM.
If your workday ends at a different time, schedule it 15 minutes before you usually shut the laptop. The debrief is most useful while the context is still fresh.
Proof
After the first run, check Gmail Drafts for the subject [date] - End of day.
If the email is useful, keep it. If it feels noisy, tighten the prompt around fewer sources or fewer bullets.
Use the evidence triangle
Ask for three concrete things before opening Q&A:
Score I want to improve: [Cost-Effectiveness / Prompt Decomposition / Failure Response / Metacognition]Artifact I would revise for real use: [DESIGN.md / deck / meeting brief / scheduled task]Proof that would make the next version safer: [source check, screenshot, Drafts proof, file export, or human review]
Use it to choose questions
Start with the lowest score or the artifact most people actually produced.
If the score is Cost-Effectiveness, ask where context, model choice, or task scope drifted.
If the score is Prompt Decomposition, ask what goal, constraint, file, or success criterion was missing.
If the score is Failure Response, ask what people did when Claude went wrong.
If the score is Metacognition, ask where a visible explanation, critique, or comparison would have changed the decision.
If no score is available, start from the artifact and proof step.
Pass condition
Q&A is grounded when each answer names a transcript moment, artifact, or proof step. If the conversation drifts into general AI opinions, bring it back to the artifact someone has on screen.
The idea
Now that the draft has passed review, ask Claude for the actual deck file.
Prompt
Create a PowerPoint file from this reviewed 5-slide deck.Requirements:- .pptx format- one slide per section- use the brand colors, fonts, spacing, and component patterns from DESIGN.md- keep text large enough to read- avoid dense paragraphs- preserve the revised slide exactly- include speaker notes only if usefulAttach the .pptx as a downloadable file.
If no file appears
Ask directly:
Please attach the .pptx as a file I can download, not as code blocks or instructions.
If the file still does not appear within two minutes, stop the export attempt and use the HTML fallback proof in the next card. Do not tell the room the PowerPoint is done until an actual .pptx opens.
Say:
The export step is blocked, but the reviewed deck still needs visible proof. I am switching to a browser HTML artifact so we can inspect fit, brand, and content.
If the deck is visually crowded
Ask for a layout repair, not a full rewrite:
The exported deck has text overflow or crowded slides.Keep the same content and brand direction, but revise the layout so each slide has more whitespace and less body text.Do not rewrite the whole deck.
Open it
Open the file in PowerPoint, Keynote, or Google Slides. The artifact is not real until you have opened it and checked the slides.
The exercise
Open a new task in Claude Cowork and paste this prompt. Replace the placeholder URL with your org’s real homepage before you send it.
Visit [your org's homepage URL] using Claude in Chrome.Extract the following and save them to a new folder called brand-assets on my Desktop:1. Download the logo image (SVG preferred, PNG if not available) as logo.svg or logo.png2. Find the primary font family from the page's computed styles, save as font.txt3. Find the primary and accent brand colours as hex codes, save as colours.txt4. Create a file called brand-brief.md with this structure:# Brand Brief**Mission:** [I will fill this in]**Homepage:** [the URL you visited]**Logo:** logo.svg (or logo.png)**Font:** [font name]**Primary colour:** [hex]**Accent colour:** [hex if found]
What Cowork will do
Uses Claude in Chrome to visit and read your live website
Runs JavaScript against the page to pull computed font-family and colour values from headings and backgrounds
Downloads the logo with curl or wget
Creates the folder and writes the four files automatically
What you do
Replace [your org's homepage URL] with your actual URL before pasting
After Cowork finishes, open brand-brief.md and fill in your mission line. One sentence, “We [what we do] for [who]”
Check the logo. If Cowork grabbed the wrong image (a hero photo, a partner logo, a favicon), right-click your actual logo on the site and “Save image as” manually into the brand-assets folder
What to bring to Block 2
Keep the brand-assets folder on your Desktop. It’s a useful reference during the session. Block 2 runs a fresh DESIGN.md extraction directly from your live website, so the folder isn’t a required input, but having your logo and mission line ready means you won’t need to look them up mid-session.
The idea
DESIGN.md is a reusable brand brief for Claude. Once it exists, you do not need to re-explain your colors, fonts, spacing, or component style in every prompt.
Run this in Claude Cowork with Claude in Chrome enabled.
Use Claude in Chrome to visit [your org website].Create a file called DESIGN.md for this site.Extract:- Brand colors as hex values- Font families and where they are used- Type scale for headings and body text- Spacing and border-radius patterns- Button, card, link, and section patterns- Any repeated visual rules that would help someone make a branded slide deck or reportFor each important color and font, include where it came from: a CSS variable, a page element, or a visual estimate.Use the live page and computed styles where possible. If the site exposes CSS variables on :root, list the variable names and values.If the site blocks access or computed styles are not available within two minutes, stop and report the exact blocker. Do not invent a complete design system from adjectives. Ask me whether to use a homepage screenshot, agenticworkflowsclub.org, or the demo kit sample DESIGN.md for the live workshop.Keep the file practical. This is a working spec for generating branded artifacts in the next steps.
What Claude is doing
Claude is reading the live page instead of guessing from adjectives. On modern sites, the strongest source is often CSS variables on :root. On other sites, Claude may need to inspect computed styles from visible elements.
That distinction matters. We want source-of-truth values, not plausible color names like “warm terracotta” or “deep slate.”
What success looks like
You should have a saved file called DESIGN.md with:
real hex colors, such as #D97757
at least one font family
short source notes for the main colors and fonts
notes on buttons, cards, links, or repeated sections
enough detail to guide a deck, report, or chart
If Claude only prints the markdown in chat, ask it to save the file in the project.
If extraction stalls
Use this recovery prompt before switching paths:
Pause and report the extraction state in five lines:1. Source URL:2. Browser access status:3. Values successfully observed:4. Values still missing:5. Recommended fallback:If you cannot observe real colors, fonts, or component patterns within two minutes, stop. Do not invent missing values. I will choose a screenshot fallback, the workshop site, or the demo kit sample DESIGN.md.
For the live workshop, it is better to use the demo kit than to produce a fake DESIGN.md. A truthful fallback keeps the artifact proof clean.
What Fieldmark scores
Fieldmark now works through prompts you paste into your agent. From the front page, you can refine a prompt before you send it, or score the session when you are done.
The session score shows four skill dimensions:
Cost-Effectiveness: how tightly you managed context, tokens, and scope
Prompt Decomposition: how well you framed goals, constraints, and reasoning
Failure Response: what you did when the agent’s first attempt missed
Metacognition: how often you reflected on process instead of just issuing instructions
The point is not a grade. The point is a sharper next rep.
Paste it into the agent session you want to score.
Let the agent fetch the Fieldmark URL and submit the score.
Open My Scores and review the score cards.
Your transcript stays on your machine. Fieldmark receives session metadata, the scores, and short quoted excerpts the agent selects as evidence.
What to discuss
Use the lowest or most surprising score as the first question:
If Cost-Effectiveness is low, ask where context, model choice, or task scope drifted.
If Prompt Decomposition is low, ask what goal, constraint, file, or success criterion was missing.
If Failure Response is low, ask what happened after the agent got something wrong.
If Metacognition is low, ask where a pause to compare, critique, or explain would have changed the work.
Pass condition
Fieldmark should show a scored session in My Scores with four dimensions:
Cost-Effectiveness
Prompt Decomposition
Failure Response
Metacognition
The score detail should also include session metadata and short evidence excerpts. If you can see those, the reflection step worked.
If scoring fails
Check these first:
You are signed in to Fieldmark with GitHub.
You copied the Score your session prompt, not the prompt-coaching one.
You pasted it into an agent that can fetch URLs.
The session has enough real work for the agent to summarize and quote evidence.
If it still fails during the live session, do not stall the close. Ask the fallback questions:
Which artifact from today would you revise for real use?
Where did Claude need a better brief, correction, or explanation?
What proof step would make the next revision safe to share?
What to capture
Take a screenshot of the score cards if you want a personal benchmark. If Fieldmark fails, capture the fallback answers instead. The next useful comparison is after you have run three more real tasks, not after one more test prompt.
You’re in. Now ask something real.
Once you log in at claude.ai you land on the home screen.
Don’t start with “what can you do?” Start with something you actually want to know. The more specific the question, the more useful the answer.
Try a question like this
Ask Claude something that’s genuinely useful to you right now. Use a question with a clear place, timeframe, and proof expectation. Here’s an example: a question about dressing for the weather in Nairobi this week.
Notice the useful shape: Claude used a specific location and timeframe, gave a structured answer, and cited the source it used. That’s what a well-scoped question gets you.
If Claude cannot search the web or does not cite a source, the pass condition changes: it should say what source is missing instead of pretending the answer is current.
Things to think about
claude.ai runs in the browser, so it can’t access your local files or private systems
Every conversation starts fresh. Claude has no memory of previous sessions unless you’re using a Project
The model shown in the bottom-right matters. Sonnet handles everything in today’s session. Opus is useful for deeper planning if your plan includes it, and Haiku is useful for fast cleanup. If Claude shows newer model labels, choose the newest Sonnet first
Claude can be wrong. It’s confident by default, so verify anything factual before acting on it
Done looks like
You have a saved example of the generic donor update from the previous prompt, plus a short list of the brand choices Claude invented.
Check it
Before moving on, mark three things in the output:
One color, font, or visual style that did not come from your source site.
One phrase that sounds plausible but not specific to your organization.
One layout or chart choice that could belong to almost any organization.
Keep the proof
Take a screenshot or save the response text. You will compare it to the DESIGN.md-driven output later.
If you are working in Cowork, use this follow-up:
Good start. Before we revise it, save this version as the baseline.Please take a screenshot of the current donor update and save it as `generic-donor-update-baseline.png`. Do not change the design yet.Then give me a short note with:1. what you saved2. three ways the presentation design feels generic, off-brand, or hard to use3. what brand evidence we should gather before improving it
The point is not to criticize Claude. The point is to make the missing context visible.
The problem
Funders and grant managers miss deadlines because checking is manual and irregular. You remember to look when you remember. By the time you check, the window is two days out, or already closed.
A Monday morning scheduled task fixes this. One setup, and every week starts with the list already in your inbox.
The prompt
Copy this into a new scheduled task:
Use Chrome for source gathering. Use Gmail at https://mail.google.com for the final draft. Do not use Superhuman, Apple Mail, Outlook, or any other mail client.Open my bookmarked grant databases in Chrome. For each one, look for funding opportunities closing in the next 14 days.If a bookmarked database is not accessible, note `source not accessible` for that source and continue. Do not invent opportunities from memory.List each opportunity: funder name, programme name, source link, deadline date, and a one-line description of eligibility.Sort by deadline, closest first.Create a Gmail draft addressed to me. The subject line must be `Grant deadlines closing soon - ` followed by today's date in YYYY-MM-DD format. For example, if today is April 25 2026, the subject is `Grant deadlines closing soon - 2026-04-25`. Substitute the actual date. Do not send the literal words `today's date`.Before you finish, verify the message exists in Gmail Drafts. Do not send it unless I explicitly approve after reviewing the draft. If Gmail blocks draft creation, return the full list in chat, label it `Blocked Gmail draft`, and tell me exactly what blocked the draft.
Setup
Bookmark your grant databases in Chrome first. Claude reads whatever is bookmarked. Common ones: Candid, GrantStation, funder portals you track manually, your country-specific grant aggregators. Whatever your current manual checking list is, that is the bookmark set.
Create the scheduled task. Paste the prompt into a new scheduled task in Claude Desktop.
Schedule it. Every Monday at 7:30am. Before the inbox fills up.
What you get
Every Monday morning, a draft sorted by urgency. The closest deadline is at the top. You decide in five minutes what is worth pursuing this week, instead of finding out on Thursday that something closed on Tuesday.
Swap in native connectors once they are available for your grant sources. Chrome works universally, connectors are faster where they exist.
Proof
After the first run, check Gmail Drafts for the subject Grant deadlines closing soon - [date].
Open the draft and confirm every listed opportunity has a source link and deadline. If the draft is missing, use the chat fallback only as a repair note. Do not schedule a send-first version until the draft path works.
The idea
Claude can sound confident even when it is wrong. That is not a reason to avoid using it. It is a reason to build a verification habit.
The practical distinction is simple: trust the shape of work you can inspect, verify the facts you would be embarrassed to get wrong.
#5 · Hallucination and Trust
Confident, not always right
Verify these
Numbers and statistics
Citations and quotes
Names and titles
Dates and deadlines
Legal or financial claims
Trust these
Document structure and flow
Logical reasoning you can follow
Drafts you can read and check
Code you can run and test
Summaries of text you provided
NEXT STEP
Systematic trust-building is called evals: define what Claude needs to do reliably, run test cases, and measure accuracy before depending on it.
What changes in practice
Do not ask, “Can I trust Claude?” Ask, “Which parts of this answer need proof before I use them?”
Claude is often useful for structure, synthesis, drafts, critique, and reasoning you can follow. It is riskier when it gives specific facts that are easy to invent but hard to notice: citations, statistics, names, dates, titles, prices, policies, legal claims, or financial claims.
That means your job changes by task:
For a workshop agenda, check whether the structure fits the room.
For a grant claim, verify the statistic before it goes into the proposal.
For a donor email, read the tone and factual details before sending.
For code, run the code and tests before trusting the implementation.
For a summary, compare it against the source text you provided.
Watch the visible work trace
While Claude is working, watch the visible activity trace. You are not trying to read hidden chain of thought. You are checking whether Claude actually used the tools the answer depends on.
If the answer needs current facts, you should see search, browser, connector, file, or command activity. If the answer needs repo proof, you should see file reads, diffs, commands, or tests. If the answer needs a Gmail draft, browser action, or saved artifact, you should see that surface open or the artifact appear.
This matters because a polished answer can arrive before any real evidence was gathered. If Claude gives a factual answer but you never saw it call a source, treat the output as an unverified draft. The next prompt is simple: “Show me which sources or tools you used, and mark any claim you answered from memory.”
Model comparison prompt
Use one prompt and run it in three fresh chats: Haiku, Sonnet, and Opus. If your plan does not include all three, use the models you have and keep the prompt unchanged.
Use a real topic if you have one from the workshop. If the room is quiet, use the demo case below.
Demo case:
Should our nonprofit use AI-generated donor segments for a Q3 fundraising campaign?Context:- We have 8,000 newsletter subscribers and 1,200 donors.- We want to increase repeat donations without making supporters feel surveilled.- The briefing is for the COO and fundraising lead.- We need to understand upside, privacy risk, bias risk, and what facts must be checked before acting.
Paste this same prompt into each model:
I need to prepare a short internal briefing on this topic:[Paste a real topic from my work, or use the donor-segmentation demo case above.]Give me:1. A 150-word briefing draft.2. A trust checklist with two columns: - Safe to use after review - Must verify before sharing3. For every item in "Must verify," tell me exactly how I should verify it.Do not invent citations. If you are unsure, mark the claim as "needs source."
Before you act on any answer, highlight every sentence that contains a number, date, named person, organization, title, citation, policy, legal claim, or financial claim. Those are your verification targets.
What to notice
Compare the three answers side by side:
Which model gives the clearest briefing?
Which model marks uncertainty most honestly?
Which model gives the most usable verification steps?
Which model sounds confident without enough evidence?
Claude should separate useful drafting from factual proof. The briefing draft may be a good start even if several details need verification.
The lesson is not that Opus always wins. The lesson is that model choice changes depth, caution, and verification behavior. A calibrated answer does not pretend every sentence is equally safe. It tells you which parts are judgment, which parts are structure, and which parts need evidence from a reliable source.
If Claude gives confident facts without marking uncertainty, follow up:
Review your previous answer for unsupported claims. Make a table with:- claim- why it matters- confidence level- source needed- whether I should remove it, soften it, or verify it before sharing
The habit
Treat Claude like a fast colleague whose drafts are useful but whose facts still need review. The more consequential the output, the more explicit the verification step should be.
For low-stakes drafts, a quick read may be enough. For public, legal, financial, medical, grant, hiring, or board-facing work, require sources, check the facts yourself, and keep a short record of what you verified.
That is the bridge to evals: when you need Claude to do a task reliably every time, do not rely on vibes. Define the expected behavior, run test cases, and measure whether the system is accurate enough for the job.
Why this matters
Long browser workflows fail for boring reasons: the laptop sleeps, Chrome suspends, or the desktop app is closed. Scheduled tasks only help if the machine is awake when the schedule fires.
What to set
In Claude Desktop, open Settings and look for a Keep Awake or equivalent power setting. Turn it on before running overnight or early-morning scheduled tasks.
Then check your operating system power settings:
macOS: System Settings -> Battery -> Options -> prevent sleep on power adapter.
Windows: Settings -> System -> Power & battery -> set sleep to a long enough window while plugged in.
Before an overnight scheduled task
Claude Desktop is open.
Chrome is open in the profile with Gmail, Calendar, Slack, and LinkedIn logged in.
Laptop is plugged in.
Keep Awake is on.
Any mail client other than Gmail is closed.
This is not a productivity trick. It is a reliability check. If the machine sleeps, Claude cannot drive the browser.
The rule
Do not start by asking “Which Claude product should I use?” Start by asking where the work lives.
This is teaching a routing habit. A surface is not a feature list. It is the place where the task has the right inputs, permissions, and proof.
1What is the job?
Draft, research, inspect a page, edit files, or change a repo.
→
2Where are the inputs?
Clean chat, local files, logged-in browser pages, or source code.
→
3What proves it worked?
Source links, screenshots, exports, Gmail drafts, tests, or a diff.
The right surface is the one that already has the input, permission, and proof path the task needs. If you choose the wrong surface, Claude either guesses, asks you to copy too much context, or cannot show that the result is real.
Four surfaces
Clean thinkingClaude Chat
Use it for drafting, critique, synthesis, planning, and questions where the important context fits in the conversation.
Needs: prompt, pasted context, files you choose to upload.
Files and workspaceClaude Cowork
Use it when the work needs local files, a persistent project workspace, or visible step-by-step steering.
Use it when the task needs to inspect source files, edit code, run tests, commit, reason across a repo, or make the work multiplayer with GitHub.
Needs: working tree, commands, tests, diffs, GitHub.
Surface chooser
Board update memoStart in Claude Chat
The work is mostly drafting and judgment. Paste the facts and ask for structure.
Brand rules from website assetsStart in Claude Cowork
The work needs files, artifacts, and a workspace you can keep steering.
Meeting brief from Calendar and GmailStart with Claude in Chrome
The work depends on logged-in web apps and visible browser evidence.
Fix the course pageStart in Claude Code
The work depends on source files, local checks, diffs, and version control.
Zoom chat prompt
Ask everyone to answer with the surface and the reason:
For [target artifact], I would start in [Claude Chat / Claude Cowork / Claude in Chrome / Claude Code] because it needs [clean conversation / files / browser state / repo access].
Then open the agentic ladder. The ladder answers a different question: not “where do I start?” but “how much agency am I giving the tool?”
The idea
In Block 3, Claude made a branded deck from your rules and content. Block 4 uses the same briefing discipline for a daily operating artifact: an email that prepares you for tomorrow’s meetings.
The agent is not magic. It follows a visible sequence:
1. Open CalendarFind tomorrow’s meetings. If tomorrow is a weekend, use Monday.
→
2. FilterKeep non-declined meetings, apply the scope cap, and skip declined ones.
→
3. Research PeopleUse LinkedIn for external attendees. Cap research at 3 people per meeting.
→
4. Check ContextSearch Gmail and Slack for recent threads. If Slack is blocked, say why.
→
5. Draft BriefCreate one ordered Gmail draft, then verify it appears in Drafts.
Why this matters
The deck showed Claude making a polished artifact from a reusable spec. The daily brief shows Claude doing operating work from a reusable spec.
The prompt has to say:
which source to read first
which meetings count
how many non-declined meetings are in scope
which people deserve research
where email search happens
what the final email must contain
how Claude proves the draft exists
What you are proving
Before we schedule this in Block 5, we run it once by hand. The proof is a Gmail draft with:
the exact YYYY-MM-DD - Meeting brief subject format
one section per in-scope non-declined meeting
a useful thing to know or ask
source notes for Calendar, LinkedIn, Gmail, Slack, and unknowns
a matching copy in Gmail Drafts
Once that works, the same prompt can become a scheduled task.
The choice
Use the live path if Calendar, Gmail, LinkedIn, and Slack are already open and signed in, or if the Slack blocker is known before the prompt starts.
Use the demo-safe path if any account, permission, browser tab, or network step is not ready within two minutes.
The learning goal is the same either way: source order, fallback behavior, draft-first proof, and a reusable scheduled-task prompt.
Live path
Use your real browser sessions.
Scope the run tightly:
tomorrow, or next Monday if tomorrow is a weekend
non-declined meetings only
first 1-3 non-declined meetings if the day is crowded
Gmail draft first
optional send only after human review
Demo-safe path
If the live path stalls, do not keep debugging in front of the room. Paste this demo-safe prompt instead and say, “Same workflow, public-safe inputs.”
Use only the demo context below. Do not browse. Do not open Calendar, LinkedIn, Gmail, or Slack for source gathering. Do not invent biography, funding history, private emails, or Slack context.Demo calendar:- 2026-05-01 10:00 AM, Partnership intro with Greenfield Community Clinic- External attendee: Maya Patel, Executive Director, Greenfield Community Clinic- Internal attendee: me- Meeting goal: explore whether their clinic wants a lightweight donor reporting templateDemo recent context:- Maya asked for examples of reports that combine program outcomes with fundraising asks.- We want to show one practical next step, not a full proposal.- Slack blocked: demo context has no live Slack access.Demo source rule:Use only the sample context above. Mark anything else as `not available in demo context`.Create a meeting brief draft with subject `2026-05-01 - Meeting brief`.The draft must include:- meeting title and time- who I am meeting- what they likely need- one useful question to ask- unknowns to verify live- source notes for the meeting that say the brief used demo-safe context onlyIf Gmail is open and ready, create a Gmail draft addressed to me and verify it appears in Gmail Drafts. If Gmail is not ready within one minute, do not debug Gmail. Return the complete plain-text draft in this chat and label the proof `Plain-text fallback draft`.
Demo-safe proof
The fallback still needs a visible artifact. Accept either:
a Gmail draft with subject 2026-05-01 - Meeting brief
a plain-text fallback draft in Claude with the same subject and source notes
Cut line
If live access fails, say this and move on:
Browser access is the variable, not the workflow. I am switching to the demo-safe path so we can still see the prompt shape, proof gate, and scheduling handoff.
Pass condition
You know which path you are running before the prompt starts, and the fallback produces a reviewable draft even if account access stalls.
The idea
This prompt is the brief. It tells Claude what to read, what to ignore, where to search, how much research to do, what shape the output should take, and how to prove the draft exists.
Read it once before running it. The structure is what makes it reusable in Block 5.
Prompt
Run this in Claude Desktop with Claude in Chrome active:
Use Chrome for browser work. Use Gmail at https://mail.google.com for all email searching and for creating the final draft. If any email link or browser state opens somewhere else, open Gmail instead.Meeting scope for this run: brief the first 3 non-declined meetings by start time. If the target day has fewer than 3 non-declined meetings, brief all of them. If I explicitly edited this sentence before sending the prompt, use the edited scope.Before doing browser work, write one line in chat with the target date rule, meeting scope, source order, and draft-first proof rule you are about to follow.Look at my Google Calendar for tomorrow. If tomorrow is a Saturday or Sunday, use the next Monday instead. Exclude declined meetings only. Include accepted, tentative, maybe, and no-response meetings. Apply the meeting scope before researching people. Do not research meetings outside the scope. If there are no in-scope non-declined meetings for that day, create a Gmail draft addressed to me with subject `[the target date in YYYY-MM-DD format] - Meeting brief` and body `No non-declined meetings scheduled.` Then verify the draft appears in Gmail Drafts and stop.For each in-scope non-declined meeting, identify the attendees. Separate external attendees (different email domain from mine) from internal ones.If a meeting has at least one external attendee, open each external attendee's LinkedIn profile in Chrome. Read their current role, organization, and one line on what they are focused on. Prioritize external attendees and cap at 3 people per meeting. If a LinkedIn profile is not publicly accessible, is private, or cannot be found, write `LinkedIn not available` next to that person's name and move on. Do not guess, do not fabricate a role or bio.If a meeting has only internal attendees, for example a standup or team sync, skip the LinkedIn lookups entirely. Instead write one short line describing what the meeting is about based on the calendar title, description, and any attached agenda.Open Slack in Chrome and search it for recent threads with each in-scope meeting's attendees. Pull relevant context into the brief. If Slack cannot be reached or you are not logged in, write `Slack blocked: [reason]` in the source notes for each affected meeting and continue. Always search Gmail at https://mail.google.com for recent threads with each in-scope meeting's attendees as well.For each in-scope meeting write a short brief with these fields: meeting title and time, who I am meeting, names and orgs, what they work on, one thing I should know or ask, and source notes. Source notes must list Calendar status, LinkedIn status, Gmail context found or not found, Slack context found, not found, or blocked, and any unknowns. Do not include private email excerpts in source notes.Create a Gmail draft addressed to me. The subject line must be the target date in YYYY-MM-DD format followed by ` - Meeting brief`. For example, if the target date is April 25 2026, the subject is `2026-04-25 - Meeting brief`. Substitute the actual date, do not send the literal words `Tomorrow's date`.Do not send the draft during the workshop unless I explicitly reply `send it`. Before you finish, verify the draft exists in Gmail Drafts. If I approve sending, send it from Gmail and then verify the message exists in Gmail Sent Mail. If Gmail blocks draft creation or sending, tell me exactly what is blocking the action and do not claim it worked.
What Claude is doing
Claude is following a source order:
Calendar for the meeting list.
LinkedIn for external attendees.
Gmail for recent context.
Slack for recent threads with attendees.
Gmail again to create and verify the draft.
The email surface is explicit because browser agents use the state they can see. Keep Gmail open and make the prompt say Gmail so Claude uses the right draft surface.
What success looks like
You should see Claude produce one Gmail draft with:
subject in the exact [date] - Meeting brief format
one section per in-scope non-declined meeting
external attendees capped at 3 people per meeting
LinkedIn not available where a profile cannot be read
Slack context found, not found, or blocked with a reason
source notes for each in-scope meeting that name Calendar, LinkedIn, Gmail, Slack, and unknowns
a final check that the message appears in Gmail Drafts
The first line in chat should also prove Claude understood the scope before it starts clicking: target date, meeting scope, source order, and draft-first proof.
If Claude stops to ask
If Claude asks you to narrow the scope, that is not a failure. A good agent flags a long or risky brief before producing it.
Answer with a constraint, for example:
Use only the first 2 non-declined meetings tomorrow and continue.
or:
Use the first 2 non-declined meetings, search Slack and Gmail for each, and continue.
If you choose to send
Only send after reviewing the draft. The safe live-demo path is draft-first. Sending is a human decision, not the proof that the workflow works.
The rule
Start with Sonnet unless you have a reason to move.
Haiku: short pass. Sonnet: structured default. Opus: big work.
Move down to Haiku when the work is repetitive, low-stakes, and easy to inspect.
Stay with Sonnet for most drafting, analysis, and daily work.
Move up to Opus when a weak plan would waste more time than the extra usage.
Quick quiz
Pick the model first, then open the answer.
Task 1Clean 200 CRM notes into tags
Best fit: Haiku.
The work is repetitive and easy to check. You can scan the output, spot obvious mistakes, and rerun a small batch if needed. Speed matters more than deep judgment.
Task 2Draft a donor brief from notes
Best fit: Sonnet.
This is the normal default: it needs synthesis, structure, and good writing, but the cost of a first draft being imperfect is manageable because you will review it before sending.
Task 3Choose one Q3 strategy from three tradeoffs
Best fit: Opus.
The task is ambiguous, high-leverage, and expensive to get wrong. You want deeper planning, sharper assumptions, and better questions before you commit the team.
Check yourself
If you cannot explain why a task is easy to inspect or expensive to get wrong, use Sonnet.
The idea
Claude models trade off speed, cost, and judgment. The exact labels in the selector change over time, so teach the pattern first: Haiku is the fast tier, Sonnet is the best balance, and Opus is the deepest planning tier.
Memory hook: these are writing words. Haiku is short and fast. Sonnet is structured and balanced. Opus is the big work when the task rewards deeper judgment.
HaikuFast
Use it for sorting, summarizing, labeling, and first-pass cleanup. The current fast model is Claude Haiku 4.5.
SonnetBalanced
Use it as your default for most workshop tasks and daily work. The current balanced model is Claude Sonnet 4.6.
OpusDeep
Use it when planning quality matters more than speed or usage. The current deep model is Claude Opus 4.7.
The beginner rule is simple: start with Sonnet. If Sonnet is not available, use the best balanced model your plan shows. Reach for Opus when a weak plan would waste more time than the extra usage. Use Haiku when the task is repetitive, easy to inspect, and speed matters. If your selector shows newer labels than these, keep the tier pattern and use the newest model in that tier.
Quick test
Run the same prompt three times in fresh chats, once per model available in your Claude plan. Do not tune the prompt between runs. The point is to feel the model difference, not to make the prompt perfect.
I run a small nonprofit with a $500,000 annual budget. We have three possible priorities for the next quarter:1. Write two grant proposals that could bring in $150,000, but each has a low chance of success.2. Improve our donor reporting system, which would save staff about 4 hours per week.3. Run a small pilot with 40 participants, which would create stronger evidence for future fundraising.We have one senior operator, one program lead, and one part-time analyst. We cannot do all three well.Recommend one priority for the next quarter. Give me:- your recommendation- the strongest argument against it- what evidence would change your mind- the first three actions for Monday morningKeep it under 300 words.
What to notice
Haiku should be fastest. It often gives a decent summary, but may flatten tradeoffs or miss second-order consequences.
Sonnet should usually give the cleanest default answer: structured, practical, and good enough to act on.
Opus should spend more effort on ambiguity. It may surface better caveats, sharper assumptions, or a more nuanced decision rule. It is not automatically “better” for every task; it is better when the task rewards deeper judgment.
Worked example
If one of your model runs fails, or if you are reading this later without access to all three models, open these examples and compare the shape of the answers.
Haiku responseChose donor reporting
Recommendation: Improve your donor reporting system.
This is the highest-leverage use of your constrained team capacity. Four hours weekly recovered is about 200 hours annually, equivalent to adding 0.1 FTE. For a three-person org, that is meaningful breathing room to pursue other opportunities without burnout.
Strongest argument against it: The grant proposals offer higher upside and might feel more urgent. If you are cash-constrained, chasing funding feels more pressing than internal efficiency.
Evidence that would change my mind: you are losing donors due to poor reporting, the senior operator is close to leaving, committed grant funding is already pending, or cash runway is under three months.
Monday actions: audit the reporting problem, scope one quick win, and set a decision gate so you can pivot if the audit shows the problem is smaller than expected.
Sonnet responseChose grant proposals
Recommendation: Write the grant proposals.
With a $500K budget, a $150K infusion represents 30% of annual revenue. That is existential stakes, not marginal upside. Capacity constraints make this the right forcing function: the senior operator owns one proposal, the program lead owns the other, and the analyst handles research and formatting support.
Strongest argument against it: low-probability bets with high staff cost may be the worst use of constrained capacity. If both proposals fail, you have spent a quarter with nothing to show, and the reporting problem is still draining time.
Evidence that would change my mind: the grants require stronger outcome data, reporting problems are causing donor attrition, or the senior operator is already too overloaded for proposal quality to be credible.
Monday actions: pull the RFPs, block calendar time through submission, and draft a one-page logic model tying current outcomes to funder priorities.
Opus responseChose the pilot
Recommendation: Run the pilot.
The pilot is the only option that creates a durable asset. Grants without strong evidence are lottery tickets, and the reporting system is real efficiency but not a path to growth. A well-run 40-person pilot generates evidence that turns future grant proposals into credible asks.
Strongest argument against it: cash flow. If runway is under six months, a pilot that pays off in 12-18 months is a luxury. Grants may be the only option that can put money in the bank this quarter.
Evidence that would change my mind: runway under six months, a high-fit grant or warm funder relationship, reporting errors that are actively damaging trust, or existing pilot-adjacent data.
Monday actions: have the program lead draft a one-page pilot design, have the senior operator confirm runway and funder champions, and have the analyst scope a lightweight measurement plan.
The point is not that Opus is always right. The point is that the models noticed different things. Haiku optimized for capacity. Sonnet optimized for near-term revenue. Opus optimized for sequencing and durable evidence.
Debrief prompt
After you read the three answers, paste the best one into Sonnet and ask:
Critique this answer as an operator. What did it assume, what did it miss, and what would you ask me before acting on it?
That second prompt is the real habit. Model choice matters, but review discipline matters more.
The problem
Relationship maintenance with funders suffers when inboxes get busy. A thread you meant to reply to on Wednesday drifts to Friday, then to the following week. By the time you remember, the reply is awkward to write.
A Monday sweep surfaces what needs attention before the week starts, so you can answer the important one before anything else demands your focus.
The prompt
Copy this into a new scheduled task:
Use Chrome for browser work. Use Gmail at https://mail.google.com for all email searching and for creating the final draft. If any email link or browser state opens somewhere else, open Gmail instead.Open my Gmail in Chrome. Search for emails from my key funders received in the last 7 days that I have not replied to.Then open Slack in Chrome and check my most active Slack channels for threads involving those funders. If Slack cannot be reached or I am not logged in, note `Slack blocked: [reason]` once at the top of the draft and continue with Gmail.List: funder name, source surface, what they sent or said, how many days since I last replied, and the Gmail thread or Slack channel where you found it.Flag the one thread most worth a response today.Create a Gmail draft addressed to me. The subject line must be `Funder follow-ups - ` followed by today's date in YYYY-MM-DD format. For example, if today is April 25 2026, the subject is `Funder follow-ups - 2026-04-25`. Substitute the actual date. Do not send the literal words `today's date`.Before you finish, verify the message exists in Gmail Drafts. Do not send it unless I explicitly approve after reviewing the draft. If Gmail blocks draft creation, return the full summary in chat, label it `Blocked Gmail draft`, and tell me exactly what blocked the draft.
About “key funders”
The prompt leaves “key funders” implicit. Claude will surface whoever is emailing you most, which is usually a reasonable proxy. If you want tighter control, add a line listing the funders explicitly, by name or email domain. For example:
Tight lists miss genuine new funders who are not on the list yet. Implicit lists drift toward whoever is loudest. Pick the one that matches how you work.
Schedule
Every Monday at 8am. Paired with the grant deadline scan at 7:30am, your Monday morning Drafts folder starts with a clear picture: what is closing, who is waiting on you, and the one thing to do first.
Proof
After the first run, check Gmail Drafts for the subject Funder follow-ups - [date].
Open the draft and confirm the flagged thread has a source surface and a next action. If the draft is missing, treat the chat output as a repair note and keep the task draft-first until Gmail verifies cleanly.
Gate before you leave
Do not leave with “use Claude more” as the plan. Pick one real task you will run after the session.
Fill this in
By [day and time], I will use [prompt or workflow from today] on [real task], and I will trust the output only after [proof step].
Examples:
By Thursday at 3pm, I will use the DESIGN.md extraction prompt on our partner site, and I will trust the output only after I compare the colors and fonts against the live page.
By Friday at 10am, I will use the deck review ritual on next week's board update, and I will trust the output only after I check every slide has one idea and one ask.
By Monday at 9am, I will use the weekend research watch on one real question, and I will trust the output only after I confirm every claim has a source link.
Check the shape
The next rep is ready when it has:
a real task, not a practice task
a prompt, spec, or workflow from today
one proof step you can verify
a clear day and time
Pass condition
You can paste the sentence into your calendar or task manager without rewriting it.
The ritual
Pick one slide to improve. Not the whole deck.
Choose the slide with the biggest problem:
title is vague
tone is wrong
proof point is missing
too much text
visual direction does not match the brand
the ask is unclear
Prompt template
Revise slide [number]: [slide title].Problem:[Name the specific problem.]Fix:[Say exactly what should change.]Keep:[Name anything from the current slide that should stay.]Do not change the other slides.
Examples
Revise slide 3: Our approach.Problem:The headline is too generic and could describe any organization.Fix:Rewrite it as a specific claim about how we deliver results.Keep:The three-part structure and the visual direction.Do not change the other slides.
Revise slide 5: What we are asking for.Problem:The ask is polite but not concrete enough.Fix:Make the next step explicit and easy to say yes to.Keep:The warm tone and the contact line.Do not change the other slides.
Why one slide
“Make it better” gives Claude no diagnosis. A named slide, named problem, and named fix gives it a target.
After the revision
Check:
only the named slide changed
the slide now has a clearer message
the strongest original details were preserved
no new facts were invented
the slide is short enough to fit
visual direction still follows DESIGN.md
If Claude changed too much, pull it back:
You changed more than the requested slide.Restore the other slides to the prior version.Keep only the revision to slide [number].Then show me the full 5-slide draft again.
If the revision is still weak, do one more targeted pass:
Slide [number] is still not specific enough.Rewrite only the title and main message.Make the title a concrete claim, not a category label.Keep the bullets and visual direction unchanged.
Once the revised slide is better, stop editing. The goal is a usable first deck, not a perfect one.
When to use this
Use the HTML preview if:
the .pptx export is slow
the .pptx export is blocked
you want a quick shareable visual
you want to inspect brand fidelity before committing to PowerPoint
you are working self-paced and want a browser artifact
Prompt
Render this reviewed deck as a standalone HTML file called branded-deck.html.Requirements:- one clearly labelled section per slide- full visual system from DESIGN.md- CSS custom property tokens where useful- readable slide-like sections- dark or light background based on what best fits DESIGN.md- no frameworks- plain HTML and inline CSS only- no external build stepThe file should open directly in a browser.
If Claude gives a code block
Ask:
Save that as branded-deck.html and give me the local file path or download link.
What it is for
This is a proof artifact. It is useful for screenshots, comments, Notion embeds, and quick review. Use .pptx when you need an editable presentation file.
Pass condition
Open branded-deck.html in a browser and take one screenshot. If PowerPoint export failed, label this as HTML fallback proof and keep the .pptx task as a follow-up instead of claiming export is complete.
The idea
DESIGN.md is useful to Claude, but it is still abstract for humans. The preview page makes the brand rules visible.
Run this after DESIGN.md passes the gateway check.
Render DESIGN.md as a standalone file called design-system.html.The page should show:- Color swatches with labels and hex values- Typography examples for headings, subheads, body, and captions- Buttons, cards, links, and section examples- A short report-style section using the brandUse plain HTML and inline CSS only.No React, no Tailwind, no external build step.The file must open directly in a browser.
Council demo
DESIGN.md is portable context. Once it exists, the prompt is no longer trapped inside one Claude thread. You can run a lightweight LLM council by giving the same spec to another model and comparing the answers.
For the live demo, paste DESIGN.md and the same render prompt into ChatGPT as a second reviewer:
I am using you as a second reviewer in an LLM council.Here is the same DESIGN.md and HTML preview prompt I gave Claude. Do not invent brand details outside DESIGN.md.Please review the planned design-system.html and tell me:1. what brand details the preview must preserve2. what generic design moves to avoid3. one concrete improvement to the preview structureDESIGN.md:[paste DESIGN.md]Preview prompt:[paste the render prompt]
The point is not to make two models compete for style. The point is to give both models the same reusable context, then use the second answer as a critique before you trust the artifact.
If Claude gives you a code block
Ask:
Save that as design-system.html and give me the local file path or download link.
What to notice
The preview is the moment DESIGN.md stops being a text file and becomes a reusable artifact.
If the page looks generic, the problem is usually upstream: DESIGN.md did not capture enough real brand information.
Gate before you leave Block 5
Pick one scheduled-task candidate you would actually keep if it worked. A vague automation idea does not count yet.
Fill this in
I want a scheduled task that [does what task] every [schedule] using [inputs].If [input] is missing or stale, Claude should [skip it, label the blocker, or ask me to repair it].I will know the first run worked when [proof].
Examples:
I want a scheduled task that drafts my meeting brief every weekday at 8am using Calendar, Gmail, LinkedIn, and Slack. If Slack cannot be reached, Claude should write Slack blocked with the reason and continue. I will know the first run worked when the draft appears in Gmail Drafts.
I want a scheduled task that scans grant deadlines every Monday at 7:30am using my bookmarked grant databases. If one source is inaccessible, Claude should label source not accessible and continue. I will know the first run worked when a Gmail draft lists funder, programme, source link, deadline, and eligibility.
I want a scheduled task that finds unanswered funder threads every Monday at 8am using Gmail and Slack. If Slack cannot be reached, Claude should use Gmail only and label the Slack blocker. I will know the first run worked when a Gmail draft names one thread worth answering today with its source surface.
Check the shape
The candidate is ready to try when it has:
a repeated task
a clear schedule
stable inputs Claude can reach
a missing-input rule
an output you would read
a proof step you can verify
Pass condition
You can say the scheduled-task sentence out loud in one breath. If you cannot, keep it manual for now and sharpen the task before scheduling it.
Where to find it
Open Claude Desktop and go to Claude Cowork. Look for Scheduled tasks. If your UI still says Routines, use that tab. The workshop idea is the same: save a prompt and a schedule together.
For the live run, capture a screenshot after creating the Morning meeting brief draft scheduled task. That screenshot is the proof that Block 5 worked and belongs in the post-session notes.
What a scheduled task is
A scheduled task is two things saved together:
A prompt. The same kind of prompt you run in a regular session.
A schedule. Daily, weekdays, weekly, or a custom cadence.
When the clock hits the scheduled time, Claude runs the prompt in Claude Cowork using the same capabilities as a manual Cowork run. No code, no external automation tool, no cron syntax.
Reliability rules
Schedule only prompts you have run once by hand.
Keep the computer awake when the task is due.
Keep Claude Desktop open.
Keep the needed browser sessions and connectors available.
Start with a draft-first output until you have seen one scheduled run work cleanly.
What connectors change
Scheduled tasks can use the same Claude Cowork capabilities as a regular session. This matters.
A Block 4 style brief built through Chrome takes minutes because Claude is opening tabs. The same prompt with native connectors for Gmail, Google Calendar, and Slack can run faster. For a daily scheduled task running at 8am, faster means the brief is ready before you sit down, not while you are drinking coffee.
Set up connectors once. Every scheduled task that touches those services inherits the speed.
The asymmetry
A one-off prompt answers a question once. A scheduled task answers the same question every day without you remembering to ask. The prompt does not change. Only the clock does. That asymmetry is the whole point.
Check the artifact
Before scheduling anything, prove what happened:
Clean pass: Gmail Drafts shows [date] - Meeting brief, with one section per in-scope non-declined meeting and source notes.
Good fallback: Claude returned a complete plain-text brief in chat and clearly named the blocker.
Not ready: Claude guessed facts, skipped source notes, used the wrong mail surface, or cannot name what it read.
If proof is missing, stop here. Do not schedule the live Gmail version yet.
Save the exact prompt
Create a note called Morning meeting brief prompt and include:
the full prompt that ran
any correction you gave during the run
the meeting scope that actually ran
the Gmail Drafts proof rule
the source-notes rule for Calendar, LinkedIn, Gmail, Slack, and unknowns
the blocker, if the run only produced a fallback draft
Handoff
Block 5 should schedule the saved prompt only after the draft proof passes. Keep the first scheduled run draft-first. Change it to send automatically only after you have seen a scheduled draft arrive cleanly.
Before you schedule it
Use the exact prompt that worked in Block 4. Do not rewrite it during this step.
The saved prompt should still include:
the Gmail-only rule
the meeting scope that passed in Block 4
the Calendar, LinkedIn, Gmail, and Slack source order
the draft-first rule
the Gmail Drafts verification rule
any limits you added during the live run
If the Block 4 draft never appeared, schedule it only after you have run the prompt once and found the proof draft in Gmail.
Say this out loud before saving:
I am scheduling the same prompt that already produced a Gmail draft. The proof today is the saved task screenshot. The proof after the first scheduled run is a Gmail Drafts screenshot with the expected subject.
Create the scheduled task
In Claude Cowork, ask Claude to create the schedule for you:
Create a scheduled task in this Cowork project.Name: Morning meeting brief draftSchedule: Monday through Friday at 8:00 AM in my current timezoneUse this exact prompt as the scheduled task body:[paste the verified Block 4 meeting brief prompt]Keep the task draft-first. It should create a Gmail draft, verify it appears in Gmail Drafts, and never send unless I explicitly change the task later.After you create it, take me to Scheduled so I can inspect the saved task details.
What to expect
After Cowork creates the task, open Scheduled. If your UI says Scheduled tasks or Routines, use that tab. Inspect the saved task before moving on:
The task is named Morning meeting brief draft.
The schedule is Monday through Friday at 8:00 AM.
The timezone is correct.
The prompt is the exact verified Block 4 prompt.
The prompt still says to create a Gmail draft and verify Gmail Drafts before any send.
The task appears in the Scheduled list after you close and reopen the details.
At 8:00 AM on the next weekday, Claude runs the same meeting brief prompt automatically.
The success condition is not just that Claude ran. The success condition is a Gmail draft with the expected subject in Drafts. Once that works, you can decide whether to change the prompt to send automatically.
For the live workshop, capture the Scheduled task details now. That is the Block 5 artifact. Do not wait for tomorrow in front of the room.
If you have native connectors
Use the same prompt at first. Once Gmail, Google Calendar, and Slack connectors are confirmed for your account, you can remove some browser navigation language and keep the same meeting scope and verification rule.
Keep Gmail explicit for drafts and sending until you have tested the write path.
Gate before scheduling
Do not schedule a prompt just because it sounds useful. Schedule it only when the first run can leave proof you can inspect.
Fill this in before creating a task:
This is worth scheduling because it repeats every [cadence], uses [inputs Claude can reach at run time], and produces [artifact I will actually read].If [input] is missing or stale, Claude should [skip, label the blocker, or ask me to repair it].The first-run proof is [screenshot, Gmail Drafts subject, source-linked list, or saved file].
Pass condition
The task is ready to schedule when all four statements are true:
The cadence is real, not aspirational.
The inputs are available without you watching the run.
The output is draft-first or review-first.
The proof is visible after the first scheduled run.
Cut line
If the missing-input rule is vague, keep the task manual. A scheduled task should fail clearly when context is missing, not produce a confident empty answer.
What you’re producing today
Four working artifacts:
01DESIGN.md + design-system.html
Machine-readable brand rules and a browser preview extracted from your own website.
02Branded deck
A five-slide deck generated from a short brief and your DESIGN.md.
03Meeting brief agent
An agent that reads your calendar and pulls live context before the call.
04Scheduled task
A reusable weekday run that creates the brief without rebuilding the prompt.
Nothing here is a toy example. You leave with artifacts you could use at your desk on the next workday.
How the time is shaped
Six blocks, paced by artifact gates. Some are longer build blocks, some are short handoffs. The rail on this page tracks exactly where we are and how much time is left.
1Introduction
Frame the shift, surfaces, and working habits.
2Brand rules
Extract DESIGN.md from your site in Cowork.
3Deck
Build a branded five-slide deck from a one-liner.
4Brief agent
Use Chrome and Gmail to prepare a meeting brief.
5Scheduled task
Schedule the verified brief for weekday reuse.
6Close
Collect feedback and decide what comes next.
What to have open
Two windows, side by side:
Left half: Claude Cowork in Claude Desktop, a new task open and ready to prompt.
Right half: this guide page. Every card you see is something we will run, discuss, or show on screen.
Chrome: signed into the Google account you use for Calendar and Gmail.
Claude Cowork vs claude.ai
Claude Cowork is a project workspace inside the Claude desktop app. Same model as claude.ai, but with a persistent context window per project, first-class file support, and the Connectors menu (including Claude in Chrome). Today we stay in Claude Cowork because every action is visible and steerable in real time.
The idea
A spec file is a plain text brief that gives Claude durable context for a project. Instead of retyping your brand rules, working preferences, constraints, and current plan in every chat, you keep them in files Claude can read at the start of the work.
The habit is simple: write the context once, then keep it current.
#4 · Spec Files and Planning
Persistent memory for Claude
DESIGN.md
What your org looks like: colors, typography, tone, and component rules.
PromptCopy prompt
1## Colors
2primary: #2D5A8E
3accent: #F4A261
4## Voice
5Warm, direct, no jargon.
CLAUDE.md
How Claude should behave: priorities, constraints, formats, and avoid lists.
PromptCopy prompt
1Always use UK English.
2Never add emoji.
3Respond as a strategist.
4Check numbers before citing.
SKILL.md
How to repeat one workflow: triggers, steps, examples, and guardrails.
PromptCopy prompt
1---
2name: deck-review
3---
4Use this when reviewing slides.
5Check brand fit, one idea per slide,
6and export readiness.
PLAN.md
What you are building now: goals, constraints, decisions, and next steps.
PromptCopy prompt
1## Goal
2Brand a deck for Agency Fund.
3## Constraints
4Max 10 slides, no stock photos.
5## Next step
6Export to PDF.
One hour of writing, infinite sessions. The brief you write once can guide every future prompt in the project.
The four files
Use these as a starting set:
DESIGN.md: what your organization looks and sounds like. Colors, fonts, voice, imagery, slide rules, writing style, and examples to follow or avoid.
CLAUDE.md: how Claude should work with you. Response style, default assumptions, formatting preferences, verification rules, and recurring constraints.
SKILL.md: how Claude should repeat a workflow. When to use it, what steps to follow, examples, guardrails, and what good output looks like.
PLAN.md: what you are building right now. Goal, scope, decisions already made, open questions, files involved, and next action.
You do not need all four for every task. The useful distinction is stable context versus live context. DESIGN.md, CLAUDE.md, and SKILL.md should change slowly. PLAN.md should change whenever the work changes.
Why it matters
Long conversations drift. A spec file gives you a clean reset point. When a chat gets crowded, you can start fresh and point Claude back to the same source of truth.
This is especially useful in Claude Code, where project instructions and skills can live beside the files Claude is editing. It is also useful in normal Claude chats: paste the relevant spec at the top of a new conversation, attach it as a file, or keep it in a Claude Project.
Quick test
In a new Sonnet chat, write a tiny planning file for one real workshop task. Pick something small, such as improving a donor update deck, cleaning a CRM export, drafting a grant follow-up email, or preparing your brand materials.
If you need a demo task, use this:
Task: Prepare a one-page donor update for board members.Context:- Organization: small climate resilience nonprofit- Audience: board members who want concise progress and risks- Files or links I may provide: last quarter's program notes, fundraising dashboard, three participant quotes- Constraints: no invented metrics, no stock language, under 700 words- What "done" means: a clear update with three wins, two risks, and one ask for the board
Then paste this prompt:
Help me write a PLAN.md for a small AI-assisted work session.Task:[Paste my real task, or use the donor-update demo task above.]Context:- Organization:- Audience or user:- Files or links I may provide:- Constraints:- What "done" means:Create a concise PLAN.md with these sections:- Goal- Inputs- Constraints- Decisions so far- Open questions- Step-by-step plan- Definition of doneKeep it practical. Ask up to three clarifying questions only if the plan would be risky without them.
When Claude returns the draft, do not treat it as finished. Edit it until it sounds like something you would actually hand to a colleague.
What to notice
A good PLAN.md should reduce the number of instructions you need in the next prompt. After you have the plan, try this follow-up in the same chat:
Using the PLAN.md above, give me the first action I should take and the exact prompt I should run next.
Claude should stop guessing about the shape of the work. It should use your goal, constraints, and definition of done as the operating brief.
Keep it alive
At the end of a work session, ask Claude to update the plan:
Update this PLAN.md based on what we decided. Keep completed work, open questions, and next steps clear enough that I can paste it into a fresh chat tomorrow.
That update is the payoff. You are not just prompting better today. You are leaving tomorrow’s Claude a better starting point.
Done looks like
Claude Cowork launches separate subagents or parallel workstreams, then returns one synthesis from the parent.
Run this in Cowork:
We are in Claude Cowork.Use separate subagents or parallel workstreams if available. If you need to show me the plan first, keep it brief, then launch the work.Task: summarize what the world is paying attention to right now.Shared brief:- Use only public, visible headlines. Do not bypass paywalls.- Pick five major newspapers from different regions. Suggested set: The New York Times, The Guardian, Le Monde, The Hindu, and The Japan Times.- If one site blocks access, choose another major newspaper from a similar region.- Return style: concise, with source names and links.Launch five independent workers:1. Worker A: The New York Times Summarize the top visible homepage headlines.2. Worker B: The Guardian Summarize the top visible homepage headlines.3. Worker C: Le Monde Summarize the top visible homepage headlines.4. Worker D: The Hindu Summarize the top visible homepage headlines.5. Worker E: The Japan Times Summarize the top visible homepage headlines.Each worker should return:- newspaper name- 3-5 top headline themes- one representative headline or link- anything that looks region-specificAfter all workers return, synthesize the results into:- the 3 biggest global themes- one theme that only appears in one region- one sentence on what the parallel workers found faster than one serial scan would have
Check it
The check passes when you can see:
Cowork kept the parent task in control.
Five workers or workstreams ran separately, one newspaper each.
Each worker returned source-backed headlines, not just a general opinion.
The final answer found cross-source patterns instead of pasting five unrelated summaries together.
If Cowork cannot start separate lanes, revise the prompt to say: “simulate five independent news researchers, keep their notes separated, then synthesize.” That is weaker than real subagents, but it still teaches the branching pattern.
The idea
Subagents are separate agents that the parent agent can send out to do bounded work. Each one gets its own context window, its own task, and its own return format. The parent stays responsible for the brief, the final decision, and the merge.
#3 · Subagents
A model running inside a model
Parent agent
delegates
research task
summarise task
verify task
returns
results
Extends context
Each subagent has its own fresh window, so the parent never fills up with raw research or intermediate work.
Parallelises work
Run three tasks at once, not three in sequence. Wall-clock time shrinks when the tasks are independent.
Isolates failure
One child failing does not kill the parent. The parent sees a failed return and decides what to do next.
The useful question is not “can I make three agents busy?” It is “does this task branch cleanly, and can I merge the answers without losing control?”
Where this lives in Claude
Subagents do not mean exactly the same thing on every Claude surface:
claude.aiResearch fans out
Use Research when the work is mostly web, docs, or connected knowledge. You steer the question; Claude handles the branching.
Best for: cited research, internal docs, broad scans.
Claude in ChromeBrowser lane
Use it when the work lives behind logged-in tabs. Chrome gives Cowork page access; it is not where you define agents.
Best for: dashboards, Gmail, Calendar, GitHub, web apps.
Claude CoworkToday’s surface
Use Cowork when the task needs local files, connectors, browser state, and long-running work. Ask for parallel workstreams or subagents after the graph is clean.
Best for: reports, decks, files, browser workflows.
Claude CodeNamed subagents
Use Code when the lanes are repo work. Code can use built-in or custom subagents for search, review, tests, and implementation.
Best for: repos, logs, commands, diffs, tests.
Today we are in Claude Cowork, so the check after this card should not stop at the graph. It should launch a small set of independent workstreams, then make the parent synthesize the returns.
Real task graph
Here is the shape for a dry-run improvement pass on this guide:
Parent briefImprove the guide before a dry run
Audience, scope, files, and definition of done.
branches
Lane ATeaching sequence
Find one concept jump that would confuse a new user.
Lane BDemo readiness
Find one place the facilitator needs proof or fallback.
Lane CPage mechanics
Find one card, label, or flow issue in the UI.
joins
SynthesisOne owner merges
Compare evidence, choose the patch, run checks.
A graph like this is a DAG: arrows move forward, the lanes do not wait on each other, and everything rejoins at a synthesis point.
The architecture move
Think in boundaries:
Information boundary: what does this lane know that the others do not need?
Decision boundary: what decision can this lane make without blocking another lane?
Integration boundary: what output will come back so the parent can compare results?
If the work has no clean boundary, do not split it. Keep it in one thread and make the next decision first.
If the work has clean boundaries, parallel agents can help because each lane gets its own context window and failure mode.
Demo test case
Use this small demo case before launching anything:
We are improving /learn-claude/guide before a dry run.The audience is operators who need practical Claude workflows.The page already has:- Block 1 intro cards- guide dialogs- slide cards- tests and proof stepsThink architecturally before delegating.First draw the dependency graph. Then propose at most three parallel work lanes.For each lane, give:- the boundary- the input it needs- the output it should return- the proof that would make the output trustworthy- what must wait until synthesisDo not launch the workers yet.
The answer should not be “three people review everything.” That is not architecture. A better split would look like this:
Lane 1Teaching sequence
Check whether the course introduces concepts in the order a new user needs them.
Returns: one confusing jump and one rewrite.
Lane 2Demo readiness
Find where the facilitator needs a concrete test case, visible proof, or fallback path.
Returns: one demo risk and one safer run plan.
Lane 3Page mechanics
Look for broken flow, card density, stale references, or checks that do not match the UI.
Returns: one product issue and the file to edit.
SynthesisOne owner merges
The parent agent compares the evidence and decides which changes actually belong in the course.
Returns: a prioritized patch plan.
When to actually use workers
Use parallel workers when the lanes can all start from the same brief and return comparable evidence.
Do not use them when:
one lane needs another lane’s answer before it can start
the task is mostly one unfolding judgment
the return formats will be impossible to compare
the integration work will take longer than just doing the task
The point is not to create more activity. The point is to shorten the critical path without losing control of synthesis.
The Cowork launch prompt
Only after the split is clear, launch the workers in Cowork:
We are in Claude Cowork.Use separate subagents or parallel workstreams if available.Launch the three lanes above as independent workers.Each worker should return:- one finding- the evidence it used- the exact next action- a confidence score from 1-5Do not edit files yet.After all three return, synthesize the results into a prioritized action list with no more than five items and name the file each item would affect.
If Cowork shows separate progress lanes, narrate that as the point: the parent keeps the brief while the workers spend their own context.
Sign up at claude.ai
Go to claude.ai and create a free account using your email.
Choose your plan
Claude offers individual tiers. Prices and included features can change, so use this as the planning baseline and confirm the current details on the billing page before the session.
Free. Good for trying it out. Usage limits apply and access to the top models is restricted, not enough for today’s session.
Pro ($20/mo in the US, discounted annually where available). Priority access to Sonnet with higher usage than Free. The minimum for the core workshop path.
Max 5x ($100/mo). Five times Pro’s limits. For heavy daily use.
Max 20x ($200/mo). Twenty times Pro’s limits. For power users running Claude throughout the workday.
For today’s core work you need at least a Pro account, or an organizational plan with Claude Desktop and connector access. Claude in Chrome is in beta for paid plans, but admin settings and rollout state can still affect access. If it is not available in your account, you can still complete the live learning path with the demo kit and the fallback prompts. Claude Code is useful for the optional coding and subagent examples, but it is not required for the brand, deck, meeting brief, or scheduled-task artifacts. Check claude.ai/settings/billing to confirm which plan you’re on.
What to expect
Once logged in you’ll see Claude’s chat interface. During the session we’ll use:
The chat interface at claude.ai for quick questions
Claude Cowork in Claude Desktop for the hands-on exercises in Blocks 2 and 3
Claude in Chrome when your account has access, or the demo kit when it does not
Scheduled tasks in Claude Desktop for the Block 5 workflow
Claude Code only if your plan includes it, as an optional surface for coding or subagent examples
The next prework steps cover installing each of these.
Done looks like
You can route four fixed tasks to the surface that can see the right inputs, use the right permission, and leave proof.
Surface router quiz
Pick the surface for each task.
Four task check0 of 4 answered
Task 1Turn rough notes into a donor update email.
The notes are already in front of you. No files, apps, browser state, or repo access required.
Task 2Create a branded workshop handout from a local DESIGN.md and agenda file.
The source material lives on your computer, and the output is a reusable document.
Task 3Prepare a meeting brief using Calendar, Gmail, and LinkedIn, then leave a Gmail draft.
The task depends on pages and accounts you are already signed into.
Task 4Fix a broken Astro component and prove the build or tests pass.
The work needs source files, command output, and a reviewable diff.
Quick guide
Use Claude Chat when the task is mostly thinking, drafting, or reviewing text.
Use Claude Cowork when the task needs local files or connected apps.
Use Claude in Chrome when the task depends on logged-in browser pages.
Use Claude Code when the task needs to inspect or change a repo.
Check it
If the task needs a live website, logged-in account, or Gmail draft or send step, do not call it a plain chat task.
If the task needs source files, tests, or version control, do not start in a browser-only surface.
The real lesson: pick the surface that can see the input, act with the right permission, and leave evidence behind.
The exercise
Run this only if Claude in Chrome is visible in your account.
Open a website you visit regularly. A news site, a sector report, your org’s homepage, any real page works.
Click the Claude icon in the Chrome toolbar to open the sidebar.
Type this: “Summarise what this page is about in 3 bullet points.”
Watch Claude read the live page and respond.
What a good result looks like
Claude should return three specific, accurate bullets drawn from what’s actually on the page, not a generic description. Here’s an example of Claude reading Hacker News and pulling out the top stories:
The key signal: Claude names actual content from the page, not vague categories. If the bullets are generic (“this page contains news articles”), the extension may not have connected properly. Check that the Connectors toggle is on in your current project.
Go further
Once the summary lands, ask a follow-up question about something specific you spotted on the page. For example: “What is the third story about, and who wrote it?” or “Does this page have a contact email?”
Follow-up questions are where the real value shows. Claude holds the full page content in context and can answer detail questions without you having to scroll or search.
If Chrome access is missing
This is still a pass if you choose the fallback before the workshop starts.
Write:
Chrome access is missing. I will use the demo kit for live browser-dependent cards, then rerun the Chrome steps when the connector appears in my account.
Keep the demo kit links open for Block 2 and Block 4. The facilitator should not debug account access once the room is moving.
The exercise
Claude Code is optional for this workshop. Run this check if your plan includes Code or you expect to use the coding examples later. If your plan does not include Code, skip this card and continue with Claude Cowork.
In Claude Desktop, look for the mode switcher at the top of the window. You’ll see two tabs: Cowork and Code. You were in Cowork for the last exercise. Click Code.
Start a new task in Claude Code.
In the message bar, type this exactly:
“Which model are you?”
Press Enter and wait for the reply.
What a good result looks like
Claude should name a specific model, for example “I’m Claude Sonnet 4.6”, “I’m Claude Opus 4.7”, or “I’m running as Claude Haiku 4.5”. Any named Claude model such as Haiku, Sonnet, or Opus is a pass.
If Claude dodges the question or says something like “I’m an AI assistant made by Anthropic” without a model name, use the visible model selector or task header instead. The goal is only to confirm that Code opens and responds.
If you cannot open Claude Code because your plan does not include it, that is not a blocker for today’s required artifacts. Mark it optional and move on.
You’re ready
You’ve now seen both sides of Claude Desktop if your plan includes both. Claude Cowork is the main surface for today’s build. Claude Code is there when you want Claude working closer to files, terminals, and coding workflows later.
The exercise
Open Claude Desktop. You should land on the Cowork home screen.
In the message bar at the bottom, type this exactly:
“What’s today’s date and what operating system am I running?”
Press Enter and wait for Claude to respond.
What a good result looks like
Claude should answer immediately with today’s actual date and your OS version, for example “macOS Sequoia 15.3” or “Windows 11 Home 23H2”. It pulls this from your live system, not from training data.
If Claude returns a generic answer like “I don’t have access to your system information,” Cowork’s system access is not enabled. Check that you’re in the desktop app, not the browser tab, and that you opened a new task from the home screen rather than the chat interface.
You’re ready
A specific, accurate answer here means Cowork can see your machine. That’s everything Block 2 needs to get started.
What to check
Open Claude Desktop.
Open Claude Cowork.
Open Scheduled tasks. If your UI says Routines, use that tab.
Confirm your brief task appears in the list.
Check the schedule: Monday through Friday, 8am.
Open the task details and confirm the prompt still says to create a Gmail draft and verify Gmail Drafts before any send.
Take a screenshot of the task details.
If you see the scheduled task with the right schedule and draft-first prompt, the live workshop gate passes. It will fire at the next scheduled time while Claude Desktop is open and the computer is awake.
First-run proof
Write the proof check into your notes before leaving this step:
After the first scheduled run, I will open Gmail Drafts and look for [YYYY-MM-DD - Meeting brief]. If the draft is missing, I will keep the task draft-first and repair access before relying on it.
The saved-task screenshot proves setup. The Gmail Drafts screenshot proves the workflow worked unattended.
If it does not appear
The save step may not have completed. Create it again from the Scheduled tasks tab:
Click New scheduled task or New Routine.
Paste the Block 4 brief prompt.
Set the schedule to Monday through Friday, 8am.
Save, and verify it shows up in the list before closing the dialog.
Reopen the task details and confirm the Gmail Drafts proof rule survived the copy-paste.
Testing without waiting for tomorrow
The task will not run automatically until the next scheduled time. If you want to confirm it works end to end now, look for a Run now option on the task (three-dot menu, or a play icon depending on the Claude Desktop version). That triggers the prompt immediately using the same capabilities it would use at 8am.
If Run now is not available in your version, you can still copy the prompt back into a regular session and run it there. The scheduled run will behave the same way.
The rule
You do not need to become technical to follow the workshop. You only need enough shared language to know what Claude can see, what it can do, and what proof it leaves behind.
When a term feels fuzzy, ask three questions:
Input: what information can the tool see?
Action: what is it allowed to do?
Proof: what artifact or screenshot shows it worked?
Core workflow terms
Model
The engine doing the reasoning. The exact labels change, but the useful pattern is stable: Haiku is fast, Sonnet is the best balance, and Opus is deeper and uses more capacity.
Prompt
The instruction you give Claude. A good prompt names the job, inputs, constraints, output shape, and proof step.
Context
The information Claude has available right now: your message, files, previous chat, browser page, or connected app data.
Context window
The amount of information Claude can hold in one conversation before older details become harder to use reliably.
Artifact
The useful thing you leave with: DESIGN.md, an HTML deck draft, a Gmail draft, a scheduled task, or a screenshot.
Proof gate
The check before you trust the output. Examples: a real hex color, a working HTML file, a Gmail draft, or a test result.
Claude surfaces
Clean thinkingClaude Chat
The normal chat surface. Best when the important context fits in the conversation.
Use for: drafting, synthesis, critique, planning.
WorkspaceClaude Cowork
The Claude Desktop workspace where Claude can use local files, connected apps, and visible step-by-step work.
Use for: brand files, decks, browser-guided tasks.
Logged-in webClaude in Chrome
The browser connection that lets Claude use pages you are signed into, such as Gmail, Calendar, LinkedIn, or a CRM.
Use for: live websites and private browser state.
Repos and testsClaude Code
The coding surface for reading files, editing a repository, running commands, and showing a diff.
Use for: code, courseware, tests, commits.
Agent words
Agent
Claude doing a multi-step task with tools, not just answering one question. You still set the goal, boundaries, and proof.
Connector
A permissioned link to an app like Gmail, Calendar, Slack, or Google Drive. It gives Claude a cleaner way to read that source.
Scheduled task
A prompt plus a schedule saved in Claude Desktop. It should only run after the prompt has worked manually at least once.
Subagent or worker
A focused helper assigned one lane of work. Use it when the lanes are independent and the results can be compared.
Hallucination
A confident-sounding claim that is not grounded in the available sources. Treat names, dates, numbers, and legal or financial claims as verification targets.
File words
Markdown
Plain text with light formatting. Files ending in .md are easy for humans and Claude to read.
DESIGN.md
Your machine-readable brand brief: colors, typography, voice, component rules, and examples to follow or avoid.
PLAN.md
Your operating brief for the current task: goal, inputs, constraints, decisions, open questions, and definition of done.
HTML
A browser-viewable file. In this workshop, HTML is the fast proof that a design or deck visually works before export.
CSV
A spreadsheet-like data file. Claude can use it to make a chart, but the chart still needs a real-data proof check.
Useful sentence
If you get lost, use this:
I think this term means [plain-English guess]. What input does it use, what action does it take, and what proof should I check?
What to watch
Claude in Chrome is the slow version of this agent, and that is useful for the workshop. You can see each browser tab open, each search happen, and each decision land in the final brief.
Watch for this sequence:
Calendar read.
Non-declined meetings filtered from declined meetings.
External attendees identified by email domain.
LinkedIn profiles opened for external attendees.
Gmail searched for recent threads.
Slack checked, or labeled as blocked with the reason.
Source notes written for each meeting.
Gmail draft created and Drafts verification.
Narration while it runs
Claude is working one tab at a time. That visible pace is the transparency. With native Gmail, Calendar, and Slack connectors, the same work can run much faster, but the browser version makes the sequence easy to audit.
Claude is also working purely from the prompt text. There is no hidden configuration file. Every rule it follows, from excluding declined meetings to capping external attendees, came from the prompt.
Decisions the prompt controls
The prompt narrows decisions that would otherwise be implicit:
which meetings count
which attendees deserve research
when LinkedIn should be skipped
how Slack should be reported when it is found, not found, or blocked
what source notes must appear in the final draft
what the email subject must be
what proof is needed before Claude can say the draft is ready
The cap at 3 people per meeting rule is especially important. Claude may self-limit anyway, but explicit rules survive model changes. Implicit behavior does not.
If something looks wrong
Use a targeted correction instead of starting over:
Pause. Use Gmail only for the draft. Close the Superhuman tab, open https://mail.google.com, and continue from the draft step. Do not send unless I explicitly approve.
or:
Pause. Do not guess LinkedIn details. Mark any profile you cannot read as `LinkedIn not available`, then continue.
The follow-up becomes part of what you learn for the next version of the prompt.
Homework
Set up one research automation before you leave, then read the brief on Monday.
The learning goal is scoping. A useful automation has a narrow question, source rules, and a proof step you can judge without trusting the model blindly.
Pick a question
Use a question you already care about. Keep it narrow enough for five sourced updates.
Examples:
What changed this weekend in AI policy that affects universities?
What new examples appeared of companies using agents in sales or support?
What credible updates appeared on [project topic]?
What did our peer organizations publish or announce this weekend?
Prompt
Copy this into a new scheduled task:
Use Chrome for source gathering. Use only sources you can open and link.Run a weekend research watch on this question:[question]Search for credible material published since Friday at 5pm in my local time.Prefer primary sources, official pages, company blogs, regulator pages, standards bodies, research labs, and reputable news outlets. Do not use unsourced social posts unless they point to a primary source.Write a Monday brief with:- 3 to 5 sourced updates, each with a link- why each update matters for my work- what is fact versus interpretation- one question I should investigate nextKeep the brief under 500 words. Do not make claims without links. If sources disagree, say so.Return the brief in chat. If Gmail is available, create a Gmail draft addressed to me with subject `Weekend research watch - [topic]`. Do not send email.Before you finish, verify each update has a working source link. If no credible updates appear, write `No credible update found` and list the searches you tried.
Schedule
Set it to run Monday at 8:00 AM.
If the topic moves fast, set a second run for Sunday evening and keep the same output format. Do not add more sources until the first brief is useful.
Monday check
Open the brief and check:
Does every claim link to a source?
Does it separate facts from interpretation?
Does it say when nothing credible changed?
Can you name one sentence that would make the next run better?
Pass condition
You can decide in under five minutes whether to keep, revise, or delete the automation.
Ask everyone to drop one message in the Zoom chat before you move on. Give them 60 seconds.
The format:
[Name] / [Role] / [Org]
Biggest AI win, one sentence
Biggest AI loss, one sentence
Target artifact: brand rules, branded deck, or meeting brief
Proof it would need before you used it with a real colleague
Why this format: wins and losses together surface the real picture. The target artifact gives everyone a practical lens for the rest of the workshop, and the proof line keeps the room anchored on usable work instead of AI novelty. Read a few out loud. The losses are usually more instructive than the wins.
Facilitator notes:
“Loss” means a moment where it failed you: hallucinated, misunderstood the task, wasted your time, or gave you false confidence.
If the artifact answers cluster, name the pattern and move on. You do not need a separate poll.
If the chat is quiet, go first. Share your own win and loss briefly.
Keep it moving. You’re not doing a full debrief, just warming the room and establishing that honest assessment is expected here.
The shift in one picture
The useful framing is not “AI is a chatbot.” It is “AI is new infrastructure for making professional work cheaper, faster, and more repeatable.”
01Infrastructure
Like electricity, AI changes the shape of work around it. The tool matters less than the operating model it enables.
02Abundance
Artifacts that used to be too expensive to make now become routine: briefs, decks, research scans, reports, and follow-ups.
03Judgment
The advantage shifts to people who can decompose problems, ask for the right output, and decide what proof is good enough.
04Investment
AI infrastructure is being built at global scale. This is not a software trend. It is construction.
05The bar moves
Teams are starting to expect AI fluency. The new baseline is not using AI once. It is steering it reliably.
What changes for your week
When output gets cheaper, the bottleneck moves. The hard part is no longer producing a plausible draft. The hard part is deciding what is worth producing and proving it is safe to use.
BeforeScarce output
One deck, brief, or report took enough time that you had to choose carefully.
→
NowCheap drafts
The first version is easy. You can produce more options than you can responsibly use.
→
New bottleneckVisible proof
Sources, screenshots, exports, draft evidence, tests, or reviewer signoff.
What “ready” means
This guide is ready when a live attendee can follow along without losing the room, and a self-paced reader can prove each step worked without you present.
The proof is simple: every major block ends with a visible artifact or screenshot.
Artifact gates
Before presenting, run the guide once and collect these:
Prework: screenshot of Claude Desktop with Claude Cowork open and Claude in Chrome connected, or a note that Chrome access is missing and the demo kit is the chosen fallback.
Block 1: one filled-in target sentence naming artifact, risk, proof, surface choice, and why that surface has the right inputs.
Block 2:DESIGN.md with at least one hex value, one font family, and source notes.
Block 2: screenshot of the rendered design-system.html preview.
Block 3: generated .pptx or standalone HTML deck opened successfully.
Block 4: Gmail Drafts screenshot with the exact YYYY-MM-DD - Meeting brief subject, the meeting scope used, plus source notes in each in-scope meeting section, or a clearly labeled demo-safe fallback draft.
Block 5: screenshot of the saved Morning meeting brief draft scheduled task with next run time.
Block 5: one filled-in scheduled-task candidate sentence with task, schedule, inputs, and proof.
Block 6: one filled-in next-rep sentence with day, time, real task, workflow source, and proof step.
If any artifact is missing, the next card is not ready for self-paced use yet.
Live workshop rule
Use the artifacts as cut lines. If Block 2 runs long, skip the CSV bonus. If Block 4 runs long, stop once the Gmail draft or demo-safe fallback draft exists and explain that the self-paced gate is Drafts verification. Sending is a human-confirmed bonus, not the workshop gate.
The workshop promise is not that every participant finishes every optional branch live. The promise is that they leave with the structure, prompts, and checks needed to finish cleanly.
Done looks like
You have one target artifact for the session and one risk to watch.
Write it in this format:
Today I want to leave with [brand rules / a branded deck / a daily meeting brief].I would trust it enough to use when [specific proof, check, screenshot, source, or review step].The risk I will watch for is [generic output / wrong facts / weak fit / missing source / hard-to-repeat workflow].
Check it
Your answer should be specific enough that you can use it later in the workshop.
If you chose brand rules, your proof might be real colors, fonts, and examples from the source site.
If you chose a branded deck, your proof might be one idea per slide, accurate claims, and visible brand fit.
If you chose a daily meeting brief, your proof might be a Gmail draft, Drafts confirmation, and named source checks.
If your answer still says “better AI output,” make it more concrete before moving on.
