Claude Projects vs attaching a doc: which actually keeps your edits scoped?
You put a 34-page product spec in a Claude Project. You've been working inside that Project for a week. Today you sat down with twelve weekly comments and intended to apply all of them. You typed the first three carefully. By the fourth you were paraphrasing. By the fifth you decided "the model will probably catch the rest." You hit send with three of twelve raised. Claude — getting three prose hints instead of twelve anchored quotes — applied the three plus rephrased six paragraphs you didn't ask about. The diff is longer than your PR. The other nine corrections are still in your head.
People ask whether Projects or attachments handle this better. Honest answer: neither, because that's not the layer where the problem lives.
Projects and attachments solve "has Claude seen the doc?" Neither solves what you actually need: raising all twelve weekly edits comfortably without giving up at point four. The thing the chat box can't carry — twelve corrections each anchored to its passage — isn't fixed by storing the doc somewhere warmer. It's fixed by a surface where the twelfth correction costs the same as the first and arrives anchored. Format: each correction is a verbatim quote with the note beneath it, separated by ---, prefixed with "apply these edits; leave everything else unchanged." Twelve anchored corrections in one paste. Use Projects for reading the spec across the week; use the paired-passage block for every edit pass. The tool that builds the block in one click is PassbackAI; the full walkthrough is in the guide.
Projects and attachments are solving two halves of the wrong problem
Claude Projects is a genuinely useful primitive. It gives Claude a document (or several) that sticks around — you can ask questions about the spec across twenty turns and Claude is not starting fresh every time. For reference-heavy work, it earns its existence the first afternoon you use it.
Attaching a file is the simpler move. You paste or upload the doc into a specific message; Claude reads it once for that turn. The file is in active context for one response, then it's gone unless you re-attach.
Both are about availability: has the model seen the document, and is the document in the window right now. Both are useful. Neither has anything to do with whether Claude will edit only the passages you asked about, because that question — "edit only these, leave the rest" — is not a memory problem. It is a target-selection problem.
If you've hit this wall from the ChatGPT side of the fence, the mechanism is the same and we wrote it up in more detail here. The rest of this piece compares Projects and attachments on the specific axis of document editing — and then shows the format that makes both of them work.
Side by side, on the axes that matter for editing
| Claude Projects | Attaching a doc | |
|---|---|---|
| Persistence across turns | Excellent. The doc is with Claude as long as the Project exists. | None. Fresh attach per message, or the doc falls out of context. |
| Quote-matching fidelity | Good. Occasionally the Project's summarization layer smooths over exact wording. | Best-in-class. The doc is verbatim in the turn's context. |
| Raising all twelve corrections this week | Unimproved. Storing the spec warm has no effect on whether you give up at point four. | Unimproved. A fresh attach makes the doc available; it doesn't make point seven worth typing. |
| Risk of "helpful reorganization" | High. Long-running context invites stylistic drift. | Medium. Single-turn scope reduces drift but doesn't eliminate it. |
| Best for | Asking questions about the doc across many turns. | One careful edit pass per turn. |
Two honest takeaways:
- For reading a long document across many turns — "what does this spec say about auth?", "what's the rollout plan?" — Projects is strictly better. The document stays warm.
- For editing, attachments are marginally safer, because the doc is verbatim in the current turn and there's less chance Claude's Project-side summary is subtly different from what you wrote. But marginally safer is not safe. Both still rewrite the neighborhood.
Why neither of them changes the give-up moment
The thing that determined Monday's diff wasn't whether the spec was in a Project or freshly attached. It was the moment around point four when you decided typing the next eight corrections wasn't worth it. Projects didn't make point four cheaper to write. Attaching the doc didn't make point seven worth raising. The cost of getting the twelfth correction out of your head and into the message is the same in both — high enough that you stopped at three.
That's the whole gap. Claude wasn't short on context — Claude was short on corrections. It received three prose hints and produced a finished-looking draft, the way RLHF rewards it for. If it had received twelve verbatim quotes each with a note beneath it, it would have applied twelve targeted edits and left the rest alone. Same Claude, same Project, same Monday afternoon — different document came back because a different number of corrections rode along anchored.
The format that closes the gap
Quote the passage. Write the note. Separate with three dashes. Prefix the whole thing with an instruction to apply the edits and leave the rest untouched. Whether the document lives in a Project, an attachment, or the prior turn's output, the format of your feedback is the piece that determines whether the edits stay scoped.
Apply these edits to the spec. Leave everything else unchanged.
---
"The system measures delight velocity on a weekly cadence."
[Delete] We do not measure delight velocity. Replace with: "We measure time-to-first-value per cohort."
---
"Stakeholders should be aligned before kickoff."
[Off tone] Too corporate. Rewrite as: "Everyone who will be on the hook for this should have read it before kickoff."
---
"moreover,"
[Delete] Third "moreover" in this section. Pick one, delete the rest.
---
This block is the same whether the doc is in a Project or attached freshly. That is the point — the format of your feedback is what scopes the edit; the storage mechanism is secondary.
How to use them together
The combination that works in practice:
- Put the document in a Project if you're going to work with it across multiple sessions. This saves you from re-attaching it every turn and makes it easy for Claude to answer reference questions between edit passes.
- For each edit pass, compose a paired-passage block outside the chat (in a scratch editor, or in a tool built for it). Include the instruction-plus-separator format above.
- Paste the block into the chat. Claude applies every edit. The document in the Project updates if you've wired it that way; otherwise you diff the output against the source and save.
Projects handles memory. Paired passages handle precision. The two stack cleanly, and the combined workflow is what you actually wanted when you first reached for Projects.
The Monday-morning PM walkthrough
Concrete, because the abstract version reads like cleverness without proof. You are a PM. You own a 32-page product spec. The spec lives in a Claude Project called "Onboarding redesign Q3." Every week, you and three reviewers leave comments. Every week, you have to apply maybe twelve targeted edits across the doc.
Without paired-passage feedback, the workflow is roughly:
- Open the Project chat. Type each comment as prose. "In the Success Metrics section, change 'delight velocity' to 'time-to-first-value' and remove the second sub-bullet." Hit send.
- Claude returns the spec. Success Metrics has the change you asked for. The Risks section, two scrolls below, has new bullets you did not ask for. The opening paragraph reads slightly differently. You sigh, paste the new spec into a diff tool, accept some changes, reject others, and move to the next comment.
- Multiply by twelve. Burn 90 minutes. Ship the spec at 11:48 PM.
With paired-passage feedback, the workflow is:
- Open the Project chat. Paste a single block: instruction prefix, twelve paired quote+note pairs separated by
---. - Claude returns the spec with twelve targeted edits applied. The unmentioned passages are byte-identical to the source. You diff, confirm, ship.
- Total elapsed: maybe fifteen minutes. Maybe ten if you've been doing it a while.
The Project is doing the work it's good at — keeping the spec warm so you don't re-attach it and so reference questions across the week stay grounded. The paired-passage block is doing the work the chat box can't do — telling Claude exactly which twelve regions of bytes to touch and which not to. Different layers, different jobs, no conflict.
What about NotebookLM, ChatGPT Canvas, and Gemini Files?
Same axes apply, slightly different verdicts.
NotebookLM is closer to Projects in spirit — a stable corpus you ask questions about. It is built for synthesis and Q&A more than for editing, and its output surface is a chat reply, not an editable doc. For an edit pass, you would still want to compose paired-passage feedback and paste it in. Persistence is excellent; scoping is not addressed.
ChatGPT Canvas is the most interesting case. Canvas has a per-block edit mode — select a paragraph, type an instruction, the block updates in place. For one passage, this is genuinely the best surface in the category. For multiple passages spread across a long document, Canvas still benefits from paired-passage feedback because you'd otherwise be doing the click-select-type dance ten times instead of pasting one block once.
Gemini Files behaves like Claude attachments. Verbatim quote matching is reliable; scoping is not addressed. Pair the file attachment with paired-passage feedback in the same message and the workflow lands the same way.
Across all of them, the format of your feedback is the part doing the scoping work. The storage layer is just storage.
If you want the full walkthrough of the paired-passage pattern — including a manual recipe you can run in any plain-text editor and the mechanism for why structured input beats prose — the piece to read is the guide. If you want every commenting method ranked side by side, the field manual. If the exact prompt phrasing is what you're after, the playbook. Anthropic's own write-up of how Projects work in their Projects support article is the primary source for what Projects persist across turns and what they don't.
The honest forecast
Anthropic, OpenAI, and Google will almost certainly ship native "scoped edit" surfaces inside their document features within the year — a gutter next to each passage, a "leave a comment" affordance, a built-in apply-to-this-region button. The product gap this post describes will close at the platform layer, and that's the right outcome.
Until that ships, the combination above is what works. Projects keeps the spec warm; paired-passage feedback keeps the edits scoped; PassbackAI is what we built so the second part takes one click instead of ten minutes of scratch-buffer formatting.
Projects remembers, attachments refresh — neither helps the reviewer who gave up at point four. That's a different layer entirely.