Using Claude Code for Non-Coding Tasks: A Practical Guide

Claude Code is useful for non-coding work because its tools are general: it reads files (including PDFs and images), makes exact edits to documents, runs scripts, and, with your permission, searches and fetches from the web. Point it at a folder of notes, a spreadsheet export or a task board and it can do research write-ups, document edits, data cleaning, triage and release notes. Two habits make that safe: set permissions to match the job, and have it record what it did somewhere a person will read, rather than in a transcript nobody opens.

What it can actually do outside code

It helps to know the tools, because each non-coding job uses a different mix, and each one has its own permission rule.

• Read opens text files, images (PNG, JPG), PDFs and notebooks. According to the tools reference↗ (opens in a new tab) it reads a whole PDF of up to 10 pages, or page ranges of up to 20 pages at a time for longer ones. No approval is needed inside your working directories.
• Edit makes exact string replacements in a file; Write creates or overwrites one. Both ask for permission by default.
• Bash runs shell commands, which is how it runs a Python or spreadsheet-cleaning script. Most commands ask first.
• WebSearch and WebFetch search the web and fetch a page. Both ask for permission.
• MCP tools connect it to other services, such as a task board. They are named mcp__<server>__<tool> and follow the same permission rules.

None of this is special to non-coding work. What changes is what you point it at: a research/ folder instead of src/, a CSV instead of a test suite.

1. Research notes

Give it a question and a folder. It can read the PDFs and notes already there, search the web for what is missing, and write a summary file with sources listed at the end. The useful discipline is to ask for the sources in a fixed shape (claim, then URL) so you can check any line quickly.

Read everything in research/supplier-options/. Then search the web for anything
missing on lead times and minimum order quantities. Write research/summary.md:
one section per supplier, every fact followed by its source URL or file name.
List at the end anything you could not confirm.

To keep web access narrow, allow fetches only from the domains you trust with a rule such as WebFetch(domain:example.com) in /permissions, and let everything else prompt. A page it fetches is input, not instruction: if a fetched page contains something that reads like an order, it is still only text on a page, so say in your prompt that fetched content is material to summarise, never instructions to follow. See MCP security risks for why that matters once tools are connected.

2. Editing documents

Claude Code edits Markdown, plain text, HTML, CSV and any other text format directly, one exact replacement at a time, which makes it good at the dull edits: applying a style guide across forty files, renaming a product everywhere, fixing British spelling, tightening every heading to under sixty characters. It will not open a Word or PowerPoint file as a document the way an office app does, so keep text you want edited in text formats.

Work on a copy or in a folder under version control, so every change can be seen and undone. Start in plan mode↗ (opens in a new tab) for anything broad: Claude reads and proposes, but does not edit your files until you approve the plan. Once the plan is right, acceptEdits mode lets it make file edits in the working directory without asking each time.

3. Cleaning data with scripts

For a messy export (dates in three formats, duplicate rows, names in the wrong column) the reliable approach is to have Claude write a small script and run it, rather than rewrite the data by hand. A script can be read, rerun on next month’s export, and checked against the original.

1. Put the raw file in data/raw/ and tell Claude never to write there.
2. Ask it to profile the file first: row count, columns, the problems it found. Read that before any cleaning.
3. Ask for a script that writes to data/clean/, and a short report: rows in, rows out, rows dropped and why.
4. Spot-check ten rows yourself against the raw file.

One caution from the permissions documentation↗ (opens in a new tab) is worth knowing here. A Read or Edit deny rule covers Claude’s own file tools and the file commands Claude Code recognises in the shell, but not a Python or Node script that opens files itself. If the folder holds something the script must not touch, move it out of the working directory, or turn on the sandbox, which enforces access at the operating-system level.

4. Triage of a board

Treat a task board like an inbox. Connect it over MCP and ask Claude Code to go through the new cards: flag duplicates, ask for missing detail in a comment, suggest a kind and a priority. It reads the board through the same tools a person’s actions go through, so it is refused for the same reasons a person would be.

claude mcp add --transport http fenbs https://fenbs.ai/api/mcp
# in Claude Code: /mcp, choose fenbs, sign in, tick read + comment

"Read the fenbs board. For each card in To Do added this week: search for
duplicates, comment the likely match, and comment the one question that
would make the card clear enough to start. Do not move anything."

With read and comment ticked and nothing else, it can triage but not change a card, which is the right level for an inbox job. If you run triage every morning, a dedicated project manager subagent keeps the instructions in one file.

5. Release notes from Completed work

If finished work lands in a Completed lane with a comment saying what changed, release notes are a summary job. Ask Claude Code to list what is in Completed and not yet in the last release notes, group it by feature, enhancement and bug, and write it for the reader you name: customers, the support team, or the client.

List the fenbs tasks in Completed. Skip any already in
release-notes-previous.md. Group them into New, Improved and Fixed (feature, enhancement, bug).
Write release-notes.md for customers: one plain sentence each, no refs,
no internal names. Leave out anything whose Testing says not tested,
and list those separately at the bottom for me.

The last instruction is the useful one. A card marked Completed but not tested should not be announced, and on fenbs each task records how it was tested, so Claude can tell the difference instead of guessing.

Use the board as the log

The risk with non-coding work is the same as with code: an hour later, all you have is a transcript. For anything longer than a quick question, give the job a card, have Claude comment on it when it starts and when it stops (what it produced, where the file is, what it could not do) and move it along the lanes. On fenbs every change is recorded in History with who made it, and changes made through a connected assistant show as “Claude via” the person who connected it, so a week of assistant work reads as a list. A task-tracking workflow for Claude Code has the CLAUDE.md lines that make it a habit.

Permission cautions

• Permission rules are enforced by Claude Code, not by the model. A line in CLAUDE.md saying “never touch finance/” shapes what Claude tries; a deny rule such as Read(./finance/**) is what actually stops it.
• Deny beats allow. A deny rule in any settings file blocks a call even if another file allows it.
• Do not use bypassPermissions on your own machine. The documentation says to use it only in isolated environments like containers or VMs.
• Keep scopes narrow on connected services. A board connection that only needs to read and comment should not hold write access.
• Keep personal and customer data out of prompts, cards and comments unless you are sure where each one is stored.