Run agentic work on folders of files from the terminal, with Claude Code, without writing code: the same thing done to a hundred documents in one supervised run.
A year of reports to review the same way, three hundred documents to restructure, a monthly report built from the same folder of inputs every time.
Twelve years of procedures, certificates and records that need one consistent, indexed archive before the audit, and nobody to do it.
Two hundred PDFs to rename, classify and summarise into one matrix before the final chapter.
Free knowledge, written for a non-technical reader. If you can explain each of these to a colleague in a sentence, you have the background this level needs.
Not useless, just not yet. Each of these appears at the level where it earns its place, or in a different course.
Print it, pin it next to the screen, and hand it to the colleague who asks how you do it.
| Item | Rule |
|---|---|
| The terminal | A text window: type what to do and where. Claude Code lives there and works on the folder you are in. |
| Working folder | One folder per job. Copy the files in. Never run on the only copy. |
| CLAUDE.md | Plain text, in the folder: what the files are, the rules, the output format, what never to touch. |
| Dry run first | "List what you would change. Change nothing." |
| Permission modes | Ask before every write until you trust the run. Never "allow all" on real files. |
| Hooks | A rule that runs before an action and can block it: no deletes, no writes outside the folder. |
| git routine | Initialise once. Commit before the run, commit after. Three commands, nothing lost. |
| Secrets out | No passwords, tokens or keys in the folder or in CLAUDE.md. |
| Log | Every run writes what it did to a log file. Keep it. |
| Scheduled runs | Same job, same folder, once a month. A person reads the log. |
| Second runner | Someone else runs it from the runbook before it counts. |
| Still engineering | A database, a public interface, other people's credentials, an integration that can fail silently. Send it to an engineer. |
Square brackets are yours to fill. Every example keeps personal data out and keeps the decision with the person.
In this folder are 312 PDF and DOCX reports from 2019 to 2026. Dry run: for each file, propose a new name in the format YYYY-MM_programme_type_title and the sub-folder it belongs in, by programme. Write the proposal to proposal.csv. Change nothing.Why it works: The first run on a real folder changes nothing and produces a list a human can read.
Apply the review checklist in CLAUDE.md to every donor report in reports/. For each, write a one-page review to reviews/ with the checklist items scored and the page reference for each finding. Then write summary.md: the five most common findings across all reports. Do not modify the reports.Why it works: One method, applied identically to every file, with the originals untouched and the output consolidated.
Build the monthly donor report from inputs/2026-10/ using template.md and the rules in CLAUDE.md. Write to output/2026-10_report.md and a log to logs/2026-10.txt listing every input file used and every figure with its source file and cell. Stop and ask if any input file is missing or if a figure has no source.Why it works: Inputs, template, output and log are all named, and the stop condition keeps judgement with you.
Extract the indicator table from each of the 48 quarterly reports in archive/ into one indicators.csv with the columns year, quarter, country, indicator, value, source file, page. Where a value cannot be found, write NA. Do not estimate.Why it works: A folder-level extraction with a reference on every row and no estimation allowed.
Scan every file in this folder for personal-data patterns: names in case stories, phone numbers, ID numbers, email addresses. Do not change any file. Write flagged.csv listing file, page and pattern type. I will review each one.Why it works: The data rule from level 3, applied to a whole archive before any other run touches it.
Set up this folder so that you ask before every write, nothing outside this folder can be modified, and no file is ever deleted, only moved to _trash/. Then show me the settings you created and explain each line in plain language.Why it works: Hooks and permission modes are created and explained, so the person who runs it understands what protects them.
Write RUNBOOK.md for a colleague who has never used a terminal: how to open the terminal in this folder, how to run the monthly report with a dry run first, how to read the log, what to do if it stops, and how to commit before and after. I will ask them to run it while I watch.Why it works: The proof of level 7 written down: a second person runs it from the guide.
Online or in person, in groups of up to nine, on your own tasks and documents. Every day ends with something that did not exist that morning.
What a terminal is; opening it; Claude Code in a copy of one of your real folders. The CLAUDE.md written for that folder. Permission modes and a hook that blocks deletes and writes outside the folder. A dry run on a real batch task (rename, classify or review), then the real run. The git routine before and after.
Building one repeatable pipeline, for example the monthly report from a folder of inputs, with its log and a scheduled run. The secrets sweep. The "still engineering" test applied to your own list of ideas. A colleague runs the pipeline from the runbook while you watch.
Thirty minutes is enough to place you on the ladder and say honestly whether this is the level to book.