Writing, summarizing, studying, planning

You open Claude because you need something done before lunch: a cleaner draft of a status email, a short brief from a 12-page PDF, a study plan for a certification, or a two-week plan for a messy project. You type one vague sentence, get something polite and long, then spend ten minutes rewriting the thing yourself. That loop is common, and it is fixable once you see what Claude actually needs from you.

This post continues a series that teaches Claude from the ground up. Earlier posts covered what Claude is, how to choose a plan, your first sessions, and how chats and Projects hold context between them. Here we stay practical: four jobs Claude handles well for almost anyone, a prompt pattern you can reuse without any special jargon, and worked examples you can paste and adapt today. Privacy and memory get their own chapter later in the series, along with workplace connectors. For broader AI habits at work, keep the Practical AI series open next to this one, and use Learn when you want the full path map.

Four jobs Claude handles well

Claude is a general model, so people use it for code, research, and dozens of other tasks. For building a habit on day one, four jobs pay off quickly because they show up in almost every role:

• Writing: drafts, rewrites, tone shifts, and structure for emails, docs, and posts.
• Summarizing: long notes, PDFs, transcripts, and threads turned into something you can act on.
• Studying: explanations, quizzes, spaced review plans, and gap checks before a test or interview.
• Planning: timelines, checklists, risk lists, meeting agendas, and “what should I do next” sequences.

These jobs share one thing: the hard part is rarely getting words to appear. The hard part is stating the audience, the goal, and the format clearly enough that the draft is usable on the first or second try. Claude is strong once those pieces are clear, and weak when you ask for “something good about Q3” with no audience and no definition of done.

None of this means you stop thinking. For analytics and SQL, you still verify the numbers and the logic yourself (see How to check AI-written SQL). For writing that will ship under your name, you still read every line before it goes out. The model speeds up drafting and structuring; you keep ownership of truth and tone.

The prompt pattern that actually sticks

You do not need a library of secret templates. One pattern covers most of the four jobs:

• Role: who Claude should act as, such as an editor, a tutor, or a project coordinator.
• Goal: what success looks like, in one sentence.
• Constraints: length, tone, what to avoid, and any tools or facts it must not invent.
• Example: a short sample of good output, or a bad sentence to fix.
• Output format: bullets, a table, an email body, numbered steps, or a quiz with answers.

Anthropic’s own prompting guidance for Claude stresses clear, direct instructions and useful examples rather than clever wording. You can go deeper in their docs later, but for everyday chat use, this five-part pattern is enough to beat a bare “write me a summary.”

Here is the same request, thin versus usable:

You can skip a piece when the job is tiny, such as “shorten this to 40 words.” For anything that will leave your screen, put all five in, because constraints and output format remove the most rework later.

Job 1: writing

Writing with Claude is not typing a title and accepting the blog post it hands back. It is draft generation under constraints: audience, length, voice, and the facts that must appear. Strong uses include status updates, difficult replies, first-pass docs, and tone shifts, such as friendly to formal or long to short.

Worked example: rewrite a status email

Suppose your rough notes look like this:

Rough notes:
- dashboard delayed, still waiting on finance definition of "active customer"
- reviewer out on PTO Fri
- we can ship partial view without cohort filter
- need decision by Wed noon or we miss the release train

Prompt:

Role: You are my calm internal editor for a data team.

Goal: Turn my rough notes into a status email for my manager and the product owner.

Constraints:
- Under 160 words
- Neutral tone, no blame
- Do not invent dates, metrics, or owners I did not give
- Keep every concrete fact from the notes

Example of the tone I want:
"We are blocked on one definition. Everything else can ship behind a flag."

Output format:
1) Subject line (max 8 words)
2) Email body with short paragraphs
3) Closing line that states the decision needed and the deadline

A solid first draft might look like this. Yours will vary, so treat it as a shape rather than a script:

Subject: Dashboard timing and one definition block

Hi both,

We are still waiting on finance’s definition of “active customer,” which is blocking the full dashboard. Our reviewer is out Friday, so review capacity is thinner this week.

We can ship a partial view without the cohort filter if that is useful for the release train. To stay on that train, we need a decision by Wednesday noon on whether partial is acceptable and who owns the final definition.

Thanks,
[Your name]

Notice what the prompt protected: no fake metrics, no invented owner for the definition, and a clear ask at the end. If the model invents a “92% confidence” line anyway, delete it. That is a constraint failure on the model’s part, not a reason to read the next paragraph any less carefully.

Writing tips that save rounds

• Paste the facts you care about as a bullet list first, then ask for prose. Models invent less when the facts are already sitting in front of them.
• Ask for two tones only when you will actually choose between them, because “make it better” is not a tone.
• For public writing, ban marketing fluff in your constraints: no empty superlatives, no invented customer quotes.
• When rewriting your own draft, say plainly what must not change, such as names, numbers, or legal phrasing.

Job 2: summarizing

Summarizing is where Claude earns its keep on long inputs, such as meeting notes, RFCs, vendor PDFs, and support threads. The usual failure is a vague paragraph that sounds right and quietly drops the actual decision. Force structure so nothing important can hide.

Worked example: brief from messy notes

Source (imagine this was pasted from a transcript or doc):

Notes from vendor call (45 min):
- New API rate limit: 120 req/min per key (was 60)
- Price for add-on analytics pack: $1,200/mo annual, $1,500 month-to-month
- SLA still 99.5% monthly; no change
- They will not sign our data processing addendum until legal review next month
- Integration path they recommend: webhook on order.created, not nightly CSV
- Our open item: confirm whether PII fields can be excluded from webhooks
- Follow-up: they send sample payload by Friday

Prompt:

Role: You are a staff analyst writing a one-page vendor brief for a busy director.

Goal: Summarize the call so we can decide whether to keep evaluating this vendor this quarter.

Constraints:
- Only use facts from the notes
- Separate facts from open questions
- Call out anything that blocks procurement or security
- Max 200 words total for sections 1-3

Example of a good decision line:
"Proceed only if legal clears the DPA path by [date we set]."

Output format:
1) Snapshot (3 bullets max)
2) Numbers and limits (table-friendly bullets)
3) Risks / blockers
4) Suggested next actions (owner-agnostic, 3 items)
5) "Missing from notes" list if anything important is absent

Sample output shape:

If the model “helpfully” adds a competitor comparison you never discussed, that is a hallucination dressed up as diligence. A constraint that says “only use facts from the notes” reduces this, but you still have to check.

Summary formats worth reusing

• Explain then go deeper: one plain paragraph, then a technical paragraph, for a mixed audience.
• Decision brief: context, options, recommendation, and risks, which works well for leadership.
• Action log: who, what, and by when, pulled from a transcript, leaving owners blank when they are unknown.
• Contradiction hunt: ask Claude to list claims that conflict across two documents.

For very long files, upload or paste in chunks and ask Claude to keep a running outline, then merge the pieces at the end. A Project (covered in the earlier post on chats and Projects) helps when the same set of source files comes back every week.

Job 3: studying

Studying with Claude works when you treat it like a tutor at a whiteboard, not a magic download of expertise. Good uses include explaining a concept three ways, generating quizzes, rebuilding a topic from your notes, prepping for interviews, or turning a syllabus into a weekly plan.

Worked example: quiz yourself on a metric definition

Prompt:

Role: You are a strict but friendly analytics tutor.

Goal: Help me learn the difference between conversion rate and conversion rate (eligible), using my notes only for definitions, then test me.

My notes:
- Conversion rate = orders / sessions
- Conversion rate (eligible) = orders / sessions that saw the buy button
- We use eligible for product experiments; marketing still uses the first one in weekly decks

Constraints:
- Do not invent extra company metrics
- If I am wrong, explain the mistake in one short paragraph, then re-ask a similar question
- Keep language concrete (orders, sessions, button)

Example of a good quiz question:
"A user lands, never scrolls to the buy button, leaves. Which denominator includes them?"

Output format:
1) 5-sentence explanation in plain English
2) One analogy (not a sports analogy)
3) 6 quiz questions (mix true/false and short answer)
4) Answer key after the questions, clearly labeled

How to use the reply: answer the quiz yourself before you read the key. Then paste your answers back in and ask Claude to grade only against the notes. That second pass catches soft grading, where the model is too polite about a wrong definition.

Study patterns that transfer

Studying code or SQL? Ask for explanations of your own snippet, then restate the logic in your own words, then run the checks yourself. Claude can invent a plausible but wrong edge case, so your notebook or warehouse stays the referee, not the model.

Job 4: planning

Planning is sequencing work under real constraints: time, people, dependencies, and risk. Claude is good at turning a fuzzy goal into a first-draft plan, and bad at knowing your real office politics or your actual calendar. You have to supply those yourself, as constraints.

Worked example: two-week analytics project plan

Prompt:

Role: You are a project coordinator for a three-person analytics squad.

Goal: Draft a two-week plan to ship a "weekly revenue by channel" dashboard that leadership trusts.

Constraints:
- Team: SQL/dbt owner, BI owner, me (stakeholder + QA)
- Max 6 hours per person per week on this project
- Source of truth is the warehouse; no direct prod DB access
- Definition of revenue is already signed off (attached summary below)
- Do not invent tools we do not have (we have dbt, BigQuery, Looker)
- Flag risks that need a human decision

Definition summary:
- Revenue = recognized order total in USD, excluding tax and shipping
- Channel from last non-direct touch in our marketing attribution table

Example of a good task line:
"SQL/dbt owner: draft dbt model grain = order_id, with tests for null channel (4h)"

Output format:
1) Outcome statement (1 sentence)
2) Day-by-day plan (10 working days), tasks with owner initials and hour estimates
3) Definition of done checklist (8 items max)
4) Risks table: risk | likelihood H/M/L | mitigation
5) Questions for stakeholders (max 5)

What you should do with the plan: fix the hour estimates against reality, move the owner tags around, and delete any task that assumes access you do not actually have. The value is the skeleton and the risk list, not a perfect Gantt chart.

Planning formats that stay honest

• Pre-mortem: tell Claude it is two weeks later and you failed, then ask for the five most likely reasons.
• Meeting agenda: goal, decisions needed, time boxes, and pre-reads.
• Responsibility lite: for each deliverable, who does it, who reviews it, and who is informed, without pretending to more precision than you actually have.
• Personal weekly plan: top 3 outcomes, deep work blocks, and an explicit “won’t do this week” line.

If your plan depends on secret strategy documents or real customer lists, stop before pasting them in; a later post in this series covers what should never leave your screen. Public process notes and made-up examples are enough for most planning drills.

One pattern, four outputs: quick map

How to tighten a weak reply in one turn

When the first answer is soft, do not restart from zero. Reply with a surgical fix instead:

Keep the structure. Cut length by 30%. Remove any claim not in my notes.
Replace adjectives with concrete facts. Add one open question at the end
if a number is missing. Do not add a conclusion paragraph.

Other high-yield follow-ups worth keeping handy:

• “Show your assumptions as a bullet list, then rewrite without the ones I mark false.”
• “Give me version A (skeptical) and version B (optimistic), same facts.”
• “Convert this to a table with columns X, Y, Z.”
• “Mark every sentence that needs a source I must supply.”

Mistakes that make drafts feel generic

• One-word goals. Saying “summarize,” “plan,” or “write” without an audience or a length forces the model to guess.
• Hidden constraints. You wanted formal, short, and no emojis, but you never actually said so.
• No example of voice. One good sentence from you beats three paragraphs of adjectives about what you want.
• Accepting invented numbers. If you did not supply a metric, treat any new metric in the reply as a bug to fix.
• Studying without retrieval practice. Reading a long explanation is not the same as answering questions about it.
• Planning without capacity. A beautiful timeline that ignores hour limits fails by day two.
• Skipping the human pass. Anything customer-facing or executive-facing still needs your own eyes on it.
• Pasting secrets to get a better draft. A better draft is never worth leaked credentials or regulated data, and a later post in this series covers what belongs on screen and what does not.

Where these jobs fit with Projects

Projects and their files, covered in an earlier post, make these four jobs stickier over time. Put brand voice notes, metric definitions, or a syllabus in a project, then reuse the same prompt pattern inside it every time you return. A later post covers what should never land inside that project, along with work integrations and the cases where Claude is the wrong tool, such as live production changes made without review.

If you want the wider habit stack, meaning verification, data caution, and how AI fits into analytics work generally, the Practical AI series is the companion path. LLM vocabulary is covered in What are LLMs, ChatGPT, generative AI, and more.

Practice drill (about 45 minutes)

1. Pick one real task from your week in each job, four tasks total, even tiny ones.
2. Write a five-part prompt for each one before you open Claude.
3. Run all four. Save the prompts that worked in a personal note or a Project file.
4. For the writing and summary tasks, do a red-pen pass and delete every invented fact.
5. For the study task, answer the quiz without looking, then grade yourself honestly.
6. For the plan, cut anything that exceeds your real hours by half and see what still remains.

Quick recap

• Start with four jobs: write, summarize, study, plan.
• Use role, goal, constraints, example, and output format together.
• Force structure in summaries so decisions and numbers do not quietly vanish.
• Study with quizzes and grading, not only explanations you read once.
• Plan with real capacity and explicit risks written down.
• Edit every draft that ships under your name, and verify every number in it.

Series notes

This is Part 5 of Learn Claude from scratch. The next post covers memory, privacy, and what never to paste, including how chat history differs from memory and project files.

Sources

• Anthropic, Prompting best practices: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• Anthropic, Prompt engineering overview: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• Anthropic, Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Claude product overview: https://claude.com/product/overview
• Analytics Made Simple, Practical AI series: https://analyticsmadesimple.com/series/practical-ai/
• Analytics Made Simple, What are LLMs, ChatGPT, generative AI, and more: https://analyticsmadesimple.com/analytics/what-are-llms-chatgpt-generative-ai-and-more/
• Analytics Made Simple, How to check AI-written SQL: https://analyticsmadesimple.com/tutorials/how-to-check-ai-written-sql/
• Analytics Made Simple, Learn: https://analyticsmadesimple.com/learn/

More definitions in Key Terms →

Merch on Etsy

Open store →

You're On Mute Coffee Mug View on Etsy → Apache Iceberg T-Shirt View on Etsy → Git Version Control Shirt View on Etsy → Git Version Control Shirt View on Etsy →