Choose upload, Project, Connector, Cowork, or MCP

Complete Create a handoff packet from files first.

Different file jobs need different access paths. Uploads, Projects, Connectors, Cowork, and MCP do different work. This lesson asks you to make a file-access path decision, 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.

Here is the before and after: Before, every file task is treated like the same desktop workflow. After, the path matches the job: upload a one-off file, use a Project for a knowledge base, use Connectors for app data, use Cowork for desktop work, or use MCP when a local server is the right bridge. 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: Describe the job and ask Claude which file path fits with the least access. 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.

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

Help me choose a file access path for this task: [paste]. Compare upload, Claude Project, Connector, Cowork desktop workflow, and local MCP. Return Recommended Path, Why, Access Needed, Privacy Risk, Setup Cost, and When To Move Up.

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 file-access path decision
- 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

• One access path is recommended.
• Access needed is named.
• Privacy risk is included.
• Move-up trigger is included.

Without rereading the lesson, explain why a file-access path decision 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 file-access path decision 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.