Claude Code is a terminal agent: it reads files in a folder you point it at, writes and runs a script for the specific job, and puts the result next to the source files. For office work, that's a different mode than a chat assistant you ask for advice — you describe the input, the expected output, and how to check it, and the agent writes the code itself.
In short
- Claude Code works best on jobs where the input and the output can both be described in words: merging spreadsheets, pulling fields out of PDFs, comparing two documents.
- You don't need much technical background — you need to be comfortable opening a terminal and reading a plan before you approve any changes.
- Every task should end with a check: a row count, a reference to the source line, a quote from the document.
- For judgment calls — contract risk, legal wording, which report number is right — it prepares the material for a decision. The decision itself stays with a person.
Set up a working folder first
A common mistake is opening Claude Code straight in the folder with the original files and asking it to "sort these out." It will genuinely try, and not always in the way you expected.
The safer setup is more boring: a dedicated folder for the task, with an input side and an output side.
office-work/
├── inbox/ # copies of the source files
└── output/ # what Claude Code produces
Keep only copies in inbox/, never the originals. If the task is new or the file count is large, it's worth asking for a plan before allowing any execution:
cd /path/to/office-work
claude --permission-mode plan
In this mode, Claude Code reads the folder and describes what it intends to do without touching any files. The same effect works without the flag — just say "describe the plan first, don't change anything until I confirm." Either way, you still have to read the plan. There's no "just do it well" button, and in that sense Claude Code isn't different from any other tool you'd hand a folder of files to without supervision.
Eight tasks where this actually holds up
Spreadsheets and reporting
Combine several Excel files into one table. A familiar situation: branch offices send in reports, the column headers are slightly different, some rows are blank, some totals are written as text instead of numbers. A reasonable way to phrase the task:
The inbox/excel folder has xlsx reports.
First, look at the column headers and tell me how they differ.
After I confirm, combine them into output/combined.xlsx.
Add a source_file column with the name of the original file.
Move blank or broken rows to a separate "Needs review" sheet.
At the end, report: how many files were read, how many rows made
it into the final table, how many rows need review, and whether
there are duplicates.
The check here is arithmetic: the sum of rows across the input files should equal the sum of rows in the final table plus the rows on the "Needs review" sheet. If it doesn't match, don't just ask "is this right?" — ask it to show exactly where a row went missing.
Pull data out of a batch of PDFs and build a report. The source files here rarely match each other: one is plain text, another is laid out as a table, and a third might turn out to be a scan with no text layer at all. It's worth checking three different files by hand before handing over the whole folder — ask it to show how it extracts each field (vendor, period, amount, category) from each one. If Claude Code suggests pdfplumber or OCR, ask why: it can't read a scan without OCR, and a row with no page reference is useless later when you need to trace an error back to the source.
Documents and contract work
Build a registry from a mixed folder of documents. When a folder has DOCX, PDF, and XLSX files jumbled together, "sort out this folder" as a single instruction won't work — different formats need different tools. The right first step is to ask for a map of what formats are present and what each one is expected to be read with. Only after that comes the registry itself, with columns like file_name, title, author, date, subject, needs_review — and any field it can't find should stay blank rather than get guessed.
Compare contract versions. A task that genuinely fits an agent isn't phrased as "assess the risk in this contract" — it's phrased as "find the clauses that changed and show the old and new text side by side." The output is a draft the lawyer still draws their own conclusion from: every difference needs to point back to a specific section, or you end up with a confident-sounding summary that's risky to take on faith.
Management reporting
Roll up weekly reports into one monthly report. People send reports in different shapes — some follow the template, some are three lines in a chat message. A useful request is to group by person and by week, separate finished from unfinished tasks, and flag anything that keeps repeating across weeks or has no owner and no deadline. Claude Code will happily write a smooth-sounding summary; the real value is in the list of gaps — where the facts don't line up, where an owner is missing.
Turn meeting notes into a task list. Meeting notes are close to useless on their own until decisions, tasks, and open questions are pulled out of them. The trap is that it's easy for a model to turn "Ivan was part of the discussion" into "Ivan owns this." One rule fixes most of it: every item needs a short quote from the original notes next to it. The quote keeps both the model and whoever reads the summary later honest.
File hygiene and publishing
Rename photos and documents without doing it by hand. IMG_0001.jpg, final.docx, final2.docx — a familiar mess. Don't approve the rename right away: first have Claude Code produce a plan as a CSV (old name, new name, reason) following a naming pattern you set, and have it check for collisions with the new names up front. Only after you've reviewed that plan does the actual rename run, and it should keep a log of what it did. Without a log, a bulk rename is like reorganizing every folder in a filing cabinet overnight and trying to remember where everything ended up the next morning.
Get an article ready to publish. This one is genuinely multi-step: check the Markdown, images, and links, build a local HTML preview, prepare a cover image at the right size — and only then think about pushing a draft through an API or MCP. The sane order is to get a working local preview first, explicitly forbidding any outbound calls or API-key use at that stage, and treat publishing as a separate, deliberately approved command.
Where this tends to break
The boundary is fairly clear once you've tried a few of these: Claude Code reliably handles work where the input and output can be described as a structure — extracting fields, merging tables, comparing text, grouping by a rule. It breaks down on visually messy source material (scans without OCR, merged Excel cells, documents with no shared template) and on tasks that genuinely require judgment — assessing risk in a contract clause, explaining why a report number is off, deciding which topic matters more for a publication. In those cases, the agent should only be trusted to prepare the material — lay out the facts, link back to the source — while the actual call stays with a person.
There's also a practical limit on how much unrelated work fits in one session: the longer a conversation runs across mixed tasks, the faster the context fills up and the more likely the model is to mix up old instructions with new ones. Once the monthly report is done, start a fresh session for the contract work.
Do you always need Plan mode
Not always. For a simple, repetitive job — folding a hundred structurally identical Excel files together under one rule — an extra round of reviewing a plan slows you down more than it protects you. The case for it is strongest where the inputs are inconsistent or a mistake is expensive to undo: mixed formats, contracts, hundreds of files with inconsistent names. The more expensive a mistake would be, the more a minute spent reading the plan before allowing any changes is worth it.
When a scenario is worth turning into a skill
If the same request keeps coming back month after month, it's worth writing it down as a skill — a file with a fixed instruction set: what to read, what to produce, which checks to run, and where to stop and call in a person. The rule of thumb is simple: run the process by hand a few times first. A bad instruction doesn't improve by being automated — it just fails on a schedule, faster.
FAQ
Do I need to know how to code?
Not for the first tasks — it's enough to open a terminal, move into the folder, and read the plan before confirming. Understanding code helps once something breaks at the level of a library, a file format, or a dependency, and sooner or later that happens.
Can Claude Code read Excel, Word, and PDF files on its own?
No — it uses programs and libraries already installed on the machine: usually Python with the right library for spreadsheets, OCR for scans. It's worth asking up front which tool it plans to use to open a file — that's cheaper than debugging the failure afterward.
Can I hand Claude Code the whole process end to end?
The mechanical part — yes: read, convert, group, rename, assemble a draft. Decisions about money, people, contracts, and publishing should stay with a person, even when the agent prepared the material behind the decision.
Sources
Start with the task you've been putting off purely because it's tedious: merging five spreadsheets, sorting a folder of reports, cleaning up file names. Hand over copies, ask for a plan, and decide up front how you'll check the result — that's when automation actually saves you an evening, instead of producing another final_final_2 folder.