You already use Claude, Projects in the Claude Desktop app, to write business plans. This is the step up: move that work from the Chat tab to the Cowork tab, where Claude works on your real files, and run it with a method: research first, a source behind every claim, distrust the numbers, and a loop you can point at anything.
A lot here? Read the principle + diagram in each topic first. Switch to Everything for the steps, prompts & checklists.
At a glance
The whole thing on one screen, tap any line for the detail. Come back here when you just want the reminder.
The moveChat tab → Cowork tab. Same Claude Desktop app you already use.▸
Cowork is the next tab over in Claude Desktop, no new app to install. The difference that matters: a Cowork Project works on your real files and runs the whole job, while a Chat Project is just a knowledge base for Q&A. Why Cowork, in full →
The method1 Start a Project · 2 Research first · 3 Source every claim · 4 Distrust the numbers · 5 Run the loop▸
Five moves, in order: each builds on the last, and removing one breaks the chain. See the method map →
Never skipA source behind every claim · verify the model's numbers (not your own knowns) · you sign off▸
Three non-negotiables: this is what makes the work trustworthy:
Source every claim, and actually open the source to confirm it says what you wrote. A link that loads isn't proof. Topic 3 →
Verify the numbers the model gives you: anything Claude calculates, projects, or pulls from memory gets rebuilt in your spreadsheet and checked. Your own known figures (real costs, signed contracts, actual revenue) are the source of truth, you don't re-derive those, just put them in the assumptions tab and sanity-check. Topic 4 →
You sign off: a human does the final verifying; never ship on the model's say-so alone.
The multiplierUse the most capable model your plan offers on the thinking, a ~2% edge per step compounds.▸
On a paid plan you can pick Claude's most capable model (with usage limits). Spend it on the judgment-heavy steps (questions, sources, synthesis, the numbers logic, red-teaming) and use a faster model for the mechanical bits. A small edge per step compounds to roughly +49% over a 20-step project. The compounding edge →
SetupClaude Desktop (Pro) → Cowork tab → new project on a real folder → standing instructions → “Ask before acting”▸
The five-minute setup: point the project at a real folder (one per client), paste the standing-instructions block, and leave it on “Ask before acting” so it shows a plan before touching files. Start the Project, step by step →
Why move from chat Projects to Cowork
You're already in Claude Desktop, using the Chat tab with Projects, good. Cowork is the next tab over in the same app. One thing that trips people up: "Projects" exists in both tabs: a Chat Project is a knowledge base for Q&A, while a Cowork Project is a real folder Claude works inside. Same word, very different power. For a business plan, a multi-file, multi-step, numbers-heavy job, the Cowork kind is the difference between a chat that talks about the work and an assistant that does it.
What you're doing
Chat tab + Projects (now)
Cowork tab (the step up)
In the app
The Chat tab (also on web / mobile)
The Cowork tab, same Claude Desktop app
Your files
You upload copies into a knowledge base
Works on your real files in a folder: reads, writes, renames
Finding the context
It retrieves matching bits, not always the right ones, so you steer it to the file
It reads the files itself and keeps its own evolving notes to pull from
Multi-step work
Answers in chat; you copy results out
Runs the whole job and saves finished files
Plan before acting
No
Yes, shows a plan / to-do and waits (“Ask before acting”)
Deep research
You copy the report somewhere
Saves the cited report straight into the project folder
Recurring jobs
No
Scheduled tasks (e.g. a month-end pull)
Real documents
Drafts text
Builds real .xlsx / .docx / .pdf files
The subtle difference: who pulls the context in
Both can use your files, the difference is how. A Chat Project is knowledge-driven: it retrieves matching chunks from your uploaded knowledge base each message (and it switches to retrieval early, so it rarely holds everything at once), which is why it doesn't always surface the right bit, and you end up pointing it at the file. Cowork is task-driven: it reads the actual files itself and writes and re-reads its own evolving notes, effectively building its own working "wiki" of the project, so it pulls its own context instead of waiting for you to direct it. The catch that doesn't change: in both, only what's in the project's files is reliable, so keep the truth in files, not in the chat thread.
Keep both
The Chat tab stays great for quick Q&A and brainstorming. Switch to the Cowork tab when you're actually building the deliverable, like the business plan and its spreadsheet.
How to use this guide ▸
Read it top to bottom. The order is the lesson. Each topic teaches one first principle, shows why it beats your current chat-Project workflow, gives you the exact Cowork steps, and hands you a copy-paste asset. The five build on each other: remove one and the chain breaks.
Tick the checkboxes as you go (they save in your browser), copy the assets straight into your own project, and end on the loop in Topic 5. That is the part that transfers to any task, not just business plans.
Why this method works (the short version)
Research first → keep it as the project's knowledge → draft from that base → a source behind every claim. That isn't a preference, it's the documented best practice: it's hand-built RAG (retrieval-augmented generation) with a human in the loop. You ground the model before it writes, where you have the most control, and you leave an audit trail. Which is just an accountant's instinct, every figure ties to a source document, applied to AI.
⚠ Two-minute setup check
Cowork is Claude working on your actual computer and files, inside the Claude Desktop app (Mac or Windows), not the browser or mobile. It's part of your paid Claude plan (Pro or above), in the Claude Desktop app for Mac and Windows. Update Claude Desktop to the latest build, then click the Cowork tab at the top (next to Chat / Code). The app must stay open and the computer awake while it works.
The pieces: rules, skills, memory & connectors
Four levers shape how a Cowork Project behaves, set them once and they apply every time. Tap each for the detail.
RulesStanding orders you write. Claude follows them on every task.▸
Two levels: Global Instructions (in Settings, apply everywhere) and project Instructions (this project only). Keep them about behaviour, not facts, "cite every claim", "show a plan first", "never overwrite a file". The standing-instructions block in Topic 1 is exactly this; you can even ask Claude to update them mid-project. Set them in Topic 1 →
SkillsSpecialised abilities Claude reaches for when a task needs them.▸
Some are built in: Cowork ships skills for real .xlsx / .docx / .pptx / .pdf files (including PDF merge, split and form-fill), so it builds a polished spreadsheet or deck directly. You can add more. You don't "run" a skill; Claude picks the right one from what you ask. Think specialised tools on the workbench.
MemoryClaude's running summary of how you work, per project, and separate from chat.▸
Memory is Claude's automatic, lossy summary of past work: your role, what you're building, how you like things. Three things to know:
It's per-project and isolated. Each Project, Chat or Cowork, has its own memory space. Your global chat memory only learns from standalone chats, not inside a project, so a project's context stays in that project.
Chat memory ≠ Cowork memory. They're separate systems that don't share data, and switching surface (browser chat ↔ Cowork) resets context, one more reason to do the whole job in one Cowork project.
Trust files, not memory, for anything that matters. Memory is a loose recap; your saved files and instructions are the source of truth. Keep the plan, the numbers and the decisions in files.
Manage it in Settings → Capabilities (view / edit / delete), or use Incognito for a no-memory chat.
ConnectorsLinks to your other tools so Claude can pull and push there.▸
A reviewed catalogue (Google Drive, Gmail, Slack, Notion, and more) plus custom ones, so a Cowork Project can read a Drive doc or draft an email as part of a job. One catch: connections are per-surface, so authorising one in chat doesn't carry into Cowork. Set them up where you'll actually work.
Rules vs Memory: easy to confuse, opposite things
One you command; the other Claude infers. Rules are the standing orders you write; memory is the notes Claude takes about you.
Rules (Instructions)
Memory
Who writes it
You, explicitly
Claude, automatically
What it is
Commands: how to behave
Observations: what it knows about you
How it's applied
Exactly, on every task
Loosely, when it seems relevant
Reliability
Deterministic, never drifts
Lossy summary, can drift or forget
Use it for
Non-negotiables: cite sources, plan first, never overwrite
Soft context: your role, how you like things
The rule of thumb
If something must happen every time, make it a Rule (or put it in a file). Don't trust Memory to remember it. Memory is a helpful recap; Rules are the law.
Your way: one project, idea → execution
The cleanest workflow: generate the idea, develop the plan, and execute it in the same Cowork project, so when you build the files, the plan is right there in context. No copying between tools, no context reset. When the thinking's done, distil: promote the keepers, the decided ideas, the key facts, the rules, into the project's files and instructions, and let the rest of the chatter go. The project should hold the signal, not the noise. (Same "promote it back" move as the loop in Topic 5.)
The whole method, on one page
Five moves, in order: each builds on the last. Click any stage to jump straight to it.
↻ It loops. Step 1 sets up the project once; then steps 2 to 5 run as a cycle, repeating each pass. See the full circle in Topic 5.
⚙ Running through all five: use the most capable model for the thinking. Small per-step edges compound. see why ↓
The compounding edge: use the most capable model
The highest-leverage habit that isn't a "step": on judgment-heavy work, reach for the most capable model. Not because any single answer is dramatically better, because a small edge compounds. If each step is ~2% better and a real project runs 20-plus steps (research, drafts, decisions, checks), you don't end up 2% better. You end up roughly +49% by step 20, with fewer errors carried forward into everything downstream.
Illustrative: a ~2% per-step edge compounded across the many steps of a real project (1.02ⁿ). The point is the shape, not the exact number.The nuance: where to spend it, and where not to ▸
Compounding only helps where there's reasoning to get right. Mechanical steps don't need the top model, so don't waste it there, and don't let this become "always max everything".
Use the most capable model for: shaping the research questions, weighing sources, synthesis, the financial logic, and red-teaming, anywhere being wrong is expensive and carries forward.
A faster / cheaper model is fine for: reformatting, renaming, extracting, boilerplate, mechanical work with no real judgement to get wrong.
Picking the model: on a paid plan you can choose Claude's most capable model in the model selector, usually with tighter usage limits on the lower tiers. So spend the top model on the judgment-heavy steps and drop to a faster one for the mechanical bits. If you keep hitting limits, that's the signal to move up a tier.
The same logic runs in reverse: starve the judgement-heavy steps and the errors compound instead.
1
The spine
Start the Project
📁 Set up a home base so your context sticks, and Claude can work on real files.
First principle
The model forgets by default. Start a brand-new chat and it knows nothing, which is the whole reason Projects exist: to load your context back in on purpose. You already feel this with Chat Projects (a knowledge base that persists). A Cowork Project takes the same idea further. It persists and gives Claude a real folder to work in. Nothing carries over unless you store it.
◆ Why this matters for you
You've already taken the first step, your Chat Projects keep a knowledge base, so you're not re-pasting context every session. Good. The principle underneath is the same one Cowork takes further: nothing carries over unless it lives in a file or an instruction. Chat Projects store your knowledge; a Cowork Project stores knowledge and is a place Claude can actually work, on your real files. Every later discipline (sourcing, the numbers rule, the audience split) is just something you set once in that project.
⇄ The value, concretely
● Chat Project (now)
Your knowledge base remembers your context and instructions: the win you already have. But Claude only talks about the work: it reads the copies you uploaded, answers in chat, and you copy results out by hand. It can't touch your real files.
● Cowork Project
Same persistence, but now Claude works in a real folder: reads, writes and updates the actual files, runs the whole multi-step job, and shows a plan first. The project gets better the more you use it.
Three tiers. You are on Chat Projects (knowledge that persists). Cowork adds the missing half: Claude works on your real files.
▸ Do it: your first Project
Open Claude Desktop → click the Cowork tab at the top.
In the left panel, find Projects → click + New project.
Choose "Use an existing folder" and point it at a real work folder (e.g. Client X, Business Plan). Starting from a real folder gives you Memory and persistence from day one. (Other options: start from scratch, or import an existing claude.ai project.)
Paste your standing instructions into the Instructions box (asset below): rules about behaviour, not facts.
Click Create, then approve the one-time folder-access prompt. Use Always Allow only for folders you'll reuse.
Leave the permission mode on "Ask before acting" (more on this in Topic 5).
Run one low-stakes task to feel it: "Read the files in this folder and summarise them into a new file. Don't overwrite anything."
Standing instructionspaste into Project → Instructions
You are my business-plan co-author and analyst. Apply these rules to every task:
CONTEXT
- Use ONLY the files in this project's folder as your source of facts. Do not use general knowledge for any figure, market size, or claim.
- US conventions: US date format and US dollars unless a file says otherwise.
SOURCING
- Put a source behind every factual claim, drawn only from this project's files. Never invent a citation, statistic, or source.
- Label each claim [SOURCED] (traceable to a file/citation) or [INFERENCE] (your reasoning). If you can't source it, say so and mark it [INFERENCE].
NUMBERS
- Treat every number as a draft to be verified. Do arithmetic in a spreadsheet file with visible formulas. Never in your head. Flag anything you're unsure about.
WAY OF WORKING
- For any multi-step task, outline your plan and wait for my approval before editing or moving files.
- Never overwrite a file. Always save a new copy.
- Be conservative and concise. If something is uncertain, say "I'm not sure" rather than guessing.
The four things a Project holds ▸
Keep these straight: they do different jobs:
Instructions: the rules applied to every task (behaviour, not facts).
Context: the local folder(s), linked projects, or reference URLs it can see.
Scheduled tasks: recurring jobs (e.g. a month-end pull).
Memory: what Claude retains between tasks. It's ON inside Projects and scoped to that project: what it learns in "Client X" never bleeds into "Client Y".
Golden rule from the guides: one Project per client / topic / workflow. A single catch-all project for everything makes every output worse. Projects are desktop-only and don't sync to the cloud.
2
Gather before you compose
Research first, split by audience
🔍 Gather the facts before you write a word, shaped for who's reading.
First principle
Separate gathering from composing, and shape the gather around the reader's silent question. The facts of a venture are constant; what changes per audience is which facts lead and how much weight each gets. Front-load grounded research so the draft is assembled from a vetted base, not improvised to fill narrative gaps.
◆ Why this matters for you
A business plan is the classic case where one fact-base must serve three readers who reward opposite things. "Write for everyone" persuades no one. A lender and an investor are underwriting different risks, so the same "$2M revenue" fact gets re-cut as stability & coverage for one and trajectory & ceiling for the other. The research split isn't stylistic fluff. It's structural.
★ The capability you haven't used yet: deep research
Ask Cowork to research something and it switches into a research mode: it browses the web, spins up parallel sub-agents (helpers each taking a sub-question), then synthesises: it raises confidence on facts several sources agree on and flags lone or thin claims. You get a structured, cited report, and you can see which parts are well-sourced vs shaky. It runs for minutes, not seconds. This is the single biggest jump from the chat you know today.
⇄ The value, concretely
● Plain chat
"Write me a business plan." It improvises a generic, audience-blind document from memory, confident, plausible, unsourced, and aimed at no one in particular.
● Research-first
You run a bounded research pass per audience, save each cited report into the project, then draft, so the right facts lead for the right reader, every claim has a trail, and you never started from a blank guess.
One fact base, re-weighted for each reader's silent question.
The three readers, and the question each is silently asking
Silent question: "Do I understand it, and do I believe it?" Rewards clarity. They may never reach the financial model, so the front of the document carries the whole argument. Top reason a lay reader bounces: they simply didn't understand it. Jargon and unexplained acronyms read as a weak idea even when the idea is strong.
research-lay-reader promptrun in your Project
Research how to make this plan land with a NON-EXPERT reader (someone outside the industry). Bounded: answer only these:
1. The 3-5 plainest ways to explain what this business does and why it matters, with zero jargon.
2. What a strong, skimmable executive summary contains for a lay reader (give a structure).
3. The 5 most common reasons non-expert readers stop reading or don't "get" a plan.
4. 3 visuals or analogies that make the business model instantly understandable.
Cite a source for every claim. Save as research-lay-reader.md in this project. Stop after these four questions.
Silent question: "Can this return 10× my money?" Rewards evidence-backed ambition. They evaluate in a rough order: team → market → traction → unit economics → defensibility → why-now → use of funds → return. A defensible SOM beats a fuzzy huge TAM. Roughly 85-90% of rejections are "too early / no traction".
research-investors promptrun in your Project
Research what INVESTORS (angels/VCs) look for. Bounded: answer only these:
1. The order investors evaluate a plan (team, market, traction, unit economics, defensibility, why-now, use of funds, return) and what "good" looks like for each.
2. How market size is presented credibly, TAM/SAM/SOM, and why a defensible SOM beats a big fuzzy TAM.
3. Unit-economics benchmarks that signal health (LTV:CAC, CAC payback, gross margin). Use US benchmarks.
4. The top reasons investors reject a plan, and how to pre-empt each.
Cite a source for every claim. Save as research-investors.md in this project. Stop after these four questions.
Silent question: "Will I be repaid, on schedule?" Rewards conservatism. Over-optimism actively hurts you here. Cash flow is primary; they apply the 5 C's (Capacity, Capital, Character, Conditions, Collateral). Show repayment ability through the slow season, not just an annual average. Top decline cause: cash flow that can't service the debt.
research-lenders promptrun in your Project
Research what LENDERS / BANKS (incl. SBA-backed) look for. Bounded: answer only these:
1. How the 5 C's (Capacity, Capital, Character, Conditions, Collateral) translate into sections of a plan.
2. The DSCR lenders expect (and the SBA minimum), and how to show cash flow proves repayment through a slow season.
3. Why over-optimism hurts with lenders, and what a conservative projection looks like.
4. The top reasons lenders decline, and how to address each up front.
Cite a source for every claim, US framing. Save as research-lenders.md in this project. Stop after these four questions.
Deep research: parallel helpers gather, then synthesise into one cited report.
▸ Do it: run a bounded research pass
Decide the reader first. You can't research well until you know whose silent question you're answering.
Pre-commit the questions. A fixed list (like the prompts above). This is what keeps "deep research" from becoming a bottomless rabbit hole.
Run it inside the Project so the project's instructions shape it, and always end with a save instruction ("save as research-investors.md in this project"). Continuity comes from saved files, not chat memory.
Tag each saved item by type (guidance vs fact) and date, so a how-to article never gets cited as a market figure later.
Open the citations and skim what's flagged thin before you trust any of it (Topic 3).
Reusable deep-research templatefill the brackets
Research [TOPIC], bounded to these questions only: [list 3-6 questions].
Scope: [geography / time period, e.g. US, 2025 to 26]. Do not expand beyond this.
For every claim, give an inline source I can click. Flag any claim that is thinly sourced.
Format: [a one-page memo / a comparison table].
When done, save the cited report as [name].md in this project folder, then give me a 5-line summary of what's well-sourced vs uncertain.
3
Provenance & the verify discipline
A source behind every claim
🔗 Make every claim traceable, and actually open the source to check it.
First principle
A citation is a claim, not a verification, and the absence of a source is itself information. Defensible work means every fact is traceable to a primary source that actually says it, unsourced statements are visibly labelled as estimates, and the model is never asked to vouch for itself.
◆ Why this matters for you
This is your audit instinct in its native form: every figure ties to a supporting document, and a reviewer can follow the trail. It matters double here because business-plan claims get diligenced, every figure independently checked, and one fabricated or unsourceable claim contaminates trust in the whole document. You're staking your name on a client's raise; "I can show you the source for that" isn't bureaucracy, it's the whole game.
⚠ The trap: a citation that looks perfect and is wrong
A free-text "cite your sources" prompt does not guarantee a real, supporting source. The nasty failure mode is citation hallucination: a real, resolving link that doesn't actually contain the claim (or says the opposite). And asking the model to check its own citations is worthless: in the Mata v. Avianca case the model confidently confirmed cases it had invented, and the lawyers were sanctioned. Verification needs an external signal: you, opening the page.
A citation that resolves is not proof - open it and confirm it states the claim.
▸ Do it: inspect a source properly
Click the inline citation: Cowork places a numbered/bracketed link right next to the claim and links to the exact source.
Read the cited passage, not the page. Land on the specific sentence (or PDF page) used. Don't skim the homepage.
Confirm it supports the specific number/date/rule. Red flags it's real-but-irrelevant: it points to a homepage or category page, it's on-topic but omits the exact figure, or you can't find the quoted text. Treat those as unsupported.
Cross-reference anything consequential against a primary source (the regulation, the official table, the filing). One citation is a lead, not a conclusion.
Relabel what you can't source as an estimate/[INFERENCE], never leave it looking like a fact.
"Ground in quotes" promptforces real grounding
Before you answer, quote the exact passages from the files in this project that support each point, then reason ONLY from those quotes. For every claim in your answer, add the source and mark it [SOURCED] or [INFERENCE]. If a claim isn't supported by a quote, say so and mark it [INFERENCE]. Do not fill the gap with general knowledge.
The Claims Register: provenance as an artifact
One row per material claim. It inverts the burden of proof for a diligence reader: every "fact" carries a link you've opened; every "estimate/assumption" honestly says so. Edit it below, it saves in your browser. (In your real project, keep this as a tab in the plan.)
📋 Claims Register
Claim
Source
Date
Link (opened & checked)
Type
✓ Verify-the-sources checklist
4
The one thing sourcing doesn't fix
Distrust the numbers
🧮 Rebuild the model's maths in a spreadsheet; you sign off.
First principle
An LLM predicts plausible tokens. It does not calculate. Sourcing proves provenance, not arithmetic or applicability. Treat the model as a reasoning partner on structure and assumptions, and treat every number it emits as a draft an accountant must rebuild in a deterministic tool before it ships.
◆ Why this is your job
This is the caveat that matters most, and the one you're uniquely equipped to own. The model is confidently wrong on math, no working memory for intermediate steps, no internal error-check, accuracy degrades as numbers grow, and it will invent a plausible market figure out of thin air. Sourcing a number proves only that it came from somewhere, not that it's the right base year, segment, or currency, nor that the arithmetic is right. You are the human sign-off. The spreadsheet you control is the system of record.
⚠ Two distinct failure modes
1. It can't do arithmetic. It emits a token sequence that looks like the result of a calculation, "with the same confidence in a wrong answer as a correct one." Push every actual calculation into a spreadsheet/file where it's deterministic and auditable. 2. Sourced ≠ correct-in-context. Even a real number can be placed wrong: wrong base year, wrong segment, double-counted. Rebuild and sign off; don't transcribe.
Model the three statements as one linked system, not a lone P&L.
⇄ The right division of labour
✓ Let the model do
Lay out the 3-statement structure; draft the assumptions tab; propose sensitivity variables and bull/base/bear scenarios; catch logic errors (e.g. LTV computed off revenue instead of gross margin); explain the drivers.
✕ Never let it own
The arithmetic; the market figure stated as fact; the final numbers. It computes in a spreadsheet with visible formulas, and you verify and ship.
You don't re-derive what you already know
The distrust is for numbers the model calculates, projects, or pulls from memory, those get rebuilt in your spreadsheet and checked. Your own known figures (real costs, signed contracts, actual revenue) are the source of truth: put them in the assumptions tab, sanity-check them, and move on. You're verifying the model's maths, not re-proving your own.
"Numbers, without inventing them" promptkeeps the model in its lane
Help me with the financial model WITHOUT inventing numbers:
- Lay out a 3-statement structure (P&L, cash flow, balance sheet) and the assumptions tab that drives it.
- List the assumptions you'd need from me, each with a sensible range, but mark them as MY inputs to confirm, not facts.
- Propose bull / base / bear scenarios and which assumptions to flex.
- Do every calculation in a spreadsheet file with visible formulas; never compute in your head. Flag anything you're unsure about.
- Do NOT state any market size or benchmark unless it's sourced from a file in this project.
The credibility floor for the numbers ▸
Three statements, linked: model P&L, cash flow and balance sheet as one system so a single assumption ripples through all three (and inconsistencies surface). A P&L hockey-stick alone misses the question that kills companies: when does cash run out?
Unit economics are primary evidence: use gross-margin-based LTV (revenue-based "tells you nothing about cash"); read LTV:CAC (≥3:1) together with CAC payback (12-18 months), because a 4:1 ratio on a 30-month payback still runs you out of cash.
Bottom-up market sizing beats top-down: "1% of a $50B market" collapses under scrutiny. Triangulate both; a >3-5× divergence means the assumptions need work.
Investors spend <2 minutes on a first pass. The red flags surface fast: unsupported hockey-stick, TAM hand-waving, buried CAC, "no competitors". Sensitivity + scenario analysis pre-empt the diligence question.
A defensible SOM beats a fuzzy, huge TAM.
✓ Verify-the-numbers checklist
5
Make it generalise
The co-working loop
🔁 Research → verify → refine, on repeat, until it's instinct.
First principle
The unit of work is a loop, not a prompt. Research → draft → red-team → verify → refine, with a non-negotiable human verify step. Internalise the loop, not a business-plan recipe, and the mentality transfers to anything: a proposal, an email, an analysis, a contract review.
Run it clockwise. Verify is the step you can't hand off, and each pass promotes the verified work back in.
◆ Why this is the whole point
The goal was never "how to write a business plan with AI": it's "how to do any defensible work with AI." You're an expert reasoner who's only new to the tool, so drive the loop yourself fast and narrate the why at each step ("I'm grounding here because…"). The tell that it clicked: you start asking Claude to red-team things no one told you to, and you apply the loop to work that has nothing to do with business plans.
Red-team promptturn the model against the draft
Switch to critic. Attack this draft as a skeptical investor and a cautious lender would:
1. List every factual claim that lacks a clickable source.
2. Name the 5 weakest assumptions and the evidence that would strengthen each.
3. Find any number that doesn't tie out or looks too optimistic.
4. Argue the strongest case AGAINST funding this, in 5 bullets.
Don't be agreeable. Find what's wrong before the investor does. List the issues; don't rewrite yet.
Two rules that keep the loop honest
Verify can't be delegated. The model's self-critique is useful, but only with your external review. It can't reliably grade itself (Topic 3). You open the sources, you rebuild the numbers. Promote-back closes the loop. Save the approved, sourced, verified sections (and the Claims Register) into the project, so the project compounds in quality instead of restarting each chat. That's the statelessness lesson from Topic 1, completed.
How to build the habit ▸
You don't need to memorise five steps: you need to run the loop a few times until it's instinct. A simple way in:
Run one full cycle end-to-end on a real task, out loud, say why at each step ("I'm grounding here because…").
Next time, push yourself to drive more of each step yourself: write the research prompt, run the verify.
You've got it when you're running research → draft → red-team → verify → refine solo, and you catch yourself red-teaming things nobody told you to.
Tip: paste the standing instructions once into the project, and keep the rest in a prompts.md file inside the folder so they're always to hand.
The one-line synthesis
The tool guesses confidently and never flags its own doubt, so first principles means you supply the doubt: ground it, make it cite, open the citations, rebuild the numbers, make it argue against itself. That same loop works on everything, not just a business plan.
Sources & honest caveats
Authoritative getting-started reading, and the things that are version-dependent: Cowork is moving fast, so verify these in the actual app rather than taking any guide as gospel.
Further reading ▸
Get started with Claude Cowork: Anthropic Help Center (the authoritative how-to: the tab, folder access, permission modes).
Claude Cowork Tutorial: DataCamp (hands-on: dedicated folder, plan-first, verify via the Artifacts pane & end-of-run summary).
Claude Projects Tutorial: AI Productivity Coach (one project per client/topic; keep instructions behavioural; prefer CSV for tabular data).
What's version-dependent (verify in-app) ▸
Availability & specifics: Cowork runs in the Claude Desktop app (Mac and Windows) on paid plans. Plan names, model versions, prices and limits change often, check Anthropic's current docs rather than any fixed figure here.
"Plan mode" wording/toggle: official docs frame it as permission modes ("Ask before acting" / "Act without asking"), not a single labelled toggle. Exact UI may differ by build.
Deep-research invocation: there's no confirmed dedicated button or slash-command in Cowork; research is triggered by the request itself. (/deep is a Claude Code thing.)
Scheduled-task command: the feature exists; the exact syntax (community-reported /schedule) is version-dependent. Use the Projects GUI route.
Memory: an old preview said Memory didn't work in Cowork; that predates Projects. Newer docs confirm it's on for Projects. If it's missing, update the app.
Hooks & custom slash-commands: no confirmed Cowork equivalent of Claude Code's hooks; don't assume your CC automation transfers.
The first principles in this guide don't change with the version: only the buttons do.
Your reference for co-working with Claude · the five topics are a dependency chain: statelessness → research-first → sourcing → numbers → the loop. Your progress and the Claims Register are saved only in this browser. Use ⎙ Print / save PDF for a paper takeaway.
A free guide to co-working with Claude, by Vasso Vassiliades at VASEO. Work with VASEO → Share freely.
