1. Analyzing Data & Generating Reports
Claude can take a spreadsheet or CSV directly and produce computed summaries — but language models predicting plausible text (Week 1) are not calculators, so for anything numeric, ask Claude to show its work rather than just state a final number.
"Using the attached sales data, calculate:
1. Total revenue by region
2. Month-over-month growth rate for each region
3. Which region had the most volatile month-to-month performance
Show the calculation for each number, not just the final figures, so I
can spot-check them."
Where your interface supports it, prefer letting Claude write and run actual code against the data rather than reason about numbers in prose — exact computation instead of estimation. Either way, treat any single important figure the way you'd treat a number from a junior analyst's first draft: worth a quick manual spot-check before it goes in front of anyone else.
A pile of correct numbers isn't a report. Ask explicitly for what the numbers imply ("what should I actually do differently given this?") — that's the part of the task where Claude adds the most value, not the arithmetic itself.
2. Building Reusable Prompt Templates
If you've refined a prompt through a few rounds of trial and error and it now reliably does what you want, save it — don't reconstruct it from memory next time. A template with clearly marked placeholders turns a one-off good prompt into a standing tool.
WEEKLY STATUS SUMMARY TEMPLATE:
"Summarize these raw notes into a status update for {{AUDIENCE}}.
Format:
- One-sentence headline: overall status (on track / at risk / blocked)
- 3 bullet points: what shipped this week
- 1-2 bullets: what's blocked, with who's needed to unblock it
- Next week's top priority, one sentence
Raw notes:
{{NOTES}}
Tone: factual, no filler phrases like 'great progress' or 'exciting
update.'"
Store templates somewhere you'll actually reuse them — a Project's custom instructions (Week 4), a personal notes doc, or a snippet manager. When a template stops producing good results because the underlying task changed, revise it and note what changed and why, the same way you'd version any other piece of reusable tooling.
Treating your best prompts as reusable assets, not throwaway messages, is what turns "I use Claude sometimes" into an actual workflow — and it's the same instinct behind system prompts (Week 3) and CLAUDE.md (Week 10), just applied one level up.
3. Where It Helps (and Where It Doesn't)
The biggest efficiency mistake isn't under-using Claude, it's applying it uniformly without noticing which parts of a task it's actually good at.
CLAUDE TENDS TO HELP A LOT WITH:
- First drafts of anything (emails, code, docs) — starting from zero is
the most expensive part of many tasks
- Boilerplate & repetitive transformations (reformatting, translating
between formats, generating variations)
- Summarizing large volumes of text you'd otherwise skim
- Brainstorming breadth — generating options for YOU to judge
CLAUDE HELPS LESS, OR NEEDS EXTRA CARE, WITH:
- Facts that must be current/verified right now (pair with a real source)
- High-stakes numeric or factual claims (verify before trusting)
- Decisions that hinge on judgment only you have the context to make
- Deeply novel creative direction — Claude extends a direction well,
it doesn't reliably originate the ONE direction that's right for you
The practical version of this: use Claude to take the expensive first 80% off your plate — the blank page, the boilerplate, the first pass — and spend your own judgment on the last 20%, the decisions and verification that actually needed a human. Applying that same 80/20 split unevenly (leaning on Claude for the 20% that needed you, or doing the 80% by hand out of habit) is where the time savings leak away.
"If Claude gets this wrong, would I actually notice before it caused a problem?" If yes, verification is cheap and delegate freely. If no — a subtle wrong number in a report, an incorrect legal-sounding claim — that's exactly where your own review needs to stay in the loop.
4. A Practical Efficiency Checklist
A short list to run through before a task, pulling together Weeks 1–5 into habits rather than a pile of separate techniques:
[ ] Is this recurring? → Build/reuse a template, don't freestyle it again
[ ] Does this need standing context? → Use a Project instead of restating it
[ ] Is this multi-part or long? → Structure it with XML tags (Week 2)
[ ] Does correctness really matter here? → Ground it in real sources,
require citations, and plan to verify the output yourself
[ ] Am I about to say "make it better"? → Stop, give targeted feedback
on specific parts instead
[ ] Is this actually a Claude-shaped task at all? → Check Section 3
None of these are new ideas at this point — the checklist's only job is making sure the habits from the last four weeks are the ones you actually reach for under time pressure, when it's tempting to just type a quick vague ask and hope.
Weeks 6 onward move from "using Claude well" to "building software that uses Claude" — the same underlying model, prompting habits and grounding instincts, but now driven entirely by code instead of a chat window.
5. Hands-on Exercise
A shown-work report, a real template, and an honest task audit
Close out the "daily work" module by applying it to your own real workload.
Part 1 — A verifiable data report:
- Find or make a small real dataset (a CSV of expenses, a spreadsheet of anything you track).
- Ask for 3 computed metrics with shown work, plus one sentence on what they imply.
- Manually verify one of the three numbers against the raw data.
Part 2 — Build a template you'll actually reuse:
- Pick a task you do at least monthly (a summary, a message type, a review format).
- Write it as a template with explicit placeholders, refining it over 2-3 test runs on different real inputs.
- Save the final template somewhere you'll find it again.
A good sign your template is ready: running it on a new input requires changing only the placeholder content, not the instructions around it.
Part 3 — An honest task audit:
- List 5 real tasks from your current week.
- For each, decide: strong Claude fit, weak fit, or "fit, but needs verification" — and write one sentence why, using Section 3's framework.
6. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
Why should you ask Claude to show its work for numeric analysis instead of just requesting the final numbers?
Why should you ask Claude to show its work for numeric analysis instead of just requesting the final numbers?
Claude is fundamentally predicting plausible text, not computing with guaranteed precision — shown work lets you spot-check the calculation rather than trusting an opaque final figure, the same grounding instinct from Week 3 applied to numbers.
Q2
What makes a prompt "template-ready" rather than a one-off?
What makes a prompt "template-ready" rather than a one-off?
It's been refined enough that running it on a new input only requires swapping the placeholder content — the instructions and structure around it stay fixed. If you're still rewriting the instructions each time, it isn't a template yet.
Q3
What's the practical test for whether a task needs extra human verification before trusting Claude's output?
What's the practical test for whether a task needs extra human verification before trusting Claude's output?
Ask whether you'd actually notice a wrong answer before it caused a problem. If a mistake would be obvious and cheap to catch, delegate freely. If it could be subtly wrong and costly (a report figure, a factual claim), your own review needs to stay in the loop.
Q4
What's the "80/20" framing this week uses for where Claude actually saves time?
What's the "80/20" framing this week uses for where Claude actually saves time?
Let Claude take the expensive first-pass work off your plate (blank page, boilerplate, first draft) — the roughly 80% — and spend your own judgment and verification on the remaining 20% that actually needs a human. Applying the split unevenly is where the real time savings get lost.