L3Lesson 9Free

Make the file work repeatable

Same source, output, and check

After this, you'll be able to create a repeatable file-work rule and use it to make Claude's work with local files safer and easier to verify.

Before you start

Complete Ask for source-backed questions first.

The idea

The first file task proves the pattern. The rule makes it repeatable. This lesson asks you to make a repeatable file-work rule, not a broad promise that Claude can use files. The output should be specific enough that you can inspect what Claude read, what it produced, and what still needs review.

File work happens as one-off paths that must be remembered every time.

Here is the before and after: Before, every run starts by re-explaining folders, files, and output. After, the rule names source folder, exclusions, output type, output location, naming pattern, review check, and when Claude must ask first. For example, a client folder might include notes, drafts, exports, and old versions. The lesson output should say which files are in scope, which are out, what Claude is making, and how you will prove the result came from the right source.

Now try it: Ask Claude to write a reusable rule from the file task you completed. Make one choice before asking Claude to work: folder, file set, output shape, source check, access path, or maintenance rule. That choice keeps desktop file work from becoming vague local search.

Make the file work repeatableRepeatable file work follows the same source, output, review, and save path each time.

Messy inputThe raw desktop files material before the lesson shapes it.
a repeatable file-work ruleThe thing you can inspect, edit, and reuse.
Review checkThe source check that catches a weak assumption.
Next stepThe output moves into the next lesson instead of sitting alone.

The lesson is done when you can show the source boundary, the output, and the check that proves the output is safe to use.

Try it (16 min)

Watch out for

Saving outputs back into the source folder without a naming rule.
Forgetting excluded files.
Letting the repeatable rule bypass review.

Paste this into Claude

Turn this completed file task into a reusable rule. Include Source Folder, Included Files, Excluded Files, Output Type, Output Location, Naming Pattern, Review Check, When To Ask First, and When To Stop.

If any input is missing, ask me up to three questions before producing the artifact. Then return five sections: Finished Artifact, Realistic File Example, Assumptions To Check, What I Should Use In The Next Lesson, and One Risk If I Trust This Without Fixing It. Keep the answer practical enough that I can paste it into my folder workflow notes.

What a good response looks like

Finished Artifact:
- a repeatable file-work rule
- Why it matters: it gives the folder workflow a concrete thing to inspect instead of a vague intention.
- Use it next: paste this artifact into the next lesson before asking Claude to write, build, import, publish, or review anything.

Reality Check:
- The artifact names the user, input, decision, owner, or proof it depends on.
- The weakest assumption is visible.
- The next step can be completed in one sitting.

What good looks like

Included and excluded files are named.
Output location and naming pattern are clear.
Review check happens before final use.
Ask-first and stop rules are included.

Go deeper (8 min)

Paste this into Claude

Without rereading the lesson, explain why a repeatable file-work rule matters in three bullets. Then apply it to a second file example: [describe a different folder or document set]. Return What Changed, What Stayed The Same, What To Check Before Trusting The Output, and the exact next action.

What a good response looks like

Transfer Check:
- What changed: the second example has a different audience, input, or delivery context.
- What stayed the same: a repeatable file-work rule still needs a source, a review check, and a next step.
- Before trusting it: inspect the source check that would catch a wrong assumption.
- Next action: run the check once, then carry the revised artifact into the next lesson.

What good looks like

You explained the lesson idea from memory before applying it again.
The second example changes the artifact instead of copying the first answer.
The trust check names a real risk.
The next action can be done in one sitting.

When this breaks

Breaks when source and output folders are mixed because the next run may read its own previous output.
Fails when review is optional because repeated work can repeat the same mistake.

AI can help with this

Paste the exercise prompt into Claude with your real folder or file context. Ask Claude to interview you one question at a time, produce a repeatable file-work rule, challenge the weakest assumption, and rewrite the artifact once so it is ready for the next file step.

A repeatable file-work rule turns source, output, check, and archive into a loop.

You can now

You can point to a repeatable file-work rule.

You can explain which files are in scope.
You can name the assumption that still needs checking.
You can use the output in the next lesson.

Key takeaways

A repeatable rule turns useful local file work into a workflow you can trust again.

Repeatable file work needs source and output rules.
Excluded files matter.
Naming patterns prevent confusion.
Review checks stay in the loop.

Was this helpful?

Up nextCreate a handoff packet from files

Ask for source-backed questions Create a handoff packet from files

← Back to Claude Cowork

Turn this completed file task into a reusable rule. Include Source Folder, Included Files, Excluded Files, Output Type, Output Location, Naming Pattern, Review Check, When To Ask First, and When To Stop. If any input is missing, ask me up to three questions before producing the artifact. Then return five sections: Finished Artifact, Realistic File Example, Assumptions To Check, What I Should Use In The Next Lesson, and One Risk If I Trust This Without Fixing It. Keep the answer practical enough that I can paste it into my folder workflow notes.

Finished Artifact: - a repeatable file-work rule - Why it matters: it gives the folder workflow a concrete thing to inspect instead of a vague intention. - Use it next: paste this artifact into the next lesson before asking Claude to write, build, import, publish, or review anything. Reality Check: - The artifact names the user, input, decision, owner, or proof it depends on. - The weakest assumption is visible. - The next step can be completed in one sitting.

Without rereading the lesson, explain why a repeatable file-work rule matters in three bullets. Then apply it to a second file example: [describe a different folder or document set]. Return What Changed, What Stayed The Same, What To Check Before Trusting The Output, and the exact next action.

Transfer Check: - What changed: the second example has a different audience, input, or delivery context. - What stayed the same: a repeatable file-work rule still needs a source, a review check, and a next step. - Before trusting it: inspect the source check that would catch a wrong assumption. - Next action: run the check once, then carry the revised artifact into the next lesson.