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 ask Claude to tighten the paragraph under "Success metrics." It obliges. It also "reorganizes the section for clarity," rephrases the three bullets above it, and promotes one sub-heading to a heading. Congratulations — you now have two specs that claim to be the same thing, and the diff is longer than your PR.
The question most people are asking is whether Projects or attachments handle this better. The honest answer is: neither. They solve a different problem.
Claude Projects solves persistence — the document is available across turns without re-pasting. Attachments solve freshness — the doc is in active context for one message, with tight quote matching. Neither solves scoping — the thing you actually want, which is "edit only the passages I named." Scoping is a format problem, not a context problem. Quote the exact passage alongside your note, separate blocks with ---, and Claude stops regenerating the neighborhood. The tool that does this automatically is OMGfixMD; the full explanation 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. |
| Edit scoping (the thing you want) | Unimproved. Projects does not address scoping. | Unimproved. Attachments do not address scoping. |
| 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 scopes edits
Claude's scoping problem is not a lack of context. It is the absence of a primitive for saying "the region of bytes from character 4,127 to character 4,298 — that one — is what I want you to edit." The chat box does not have that primitive. The closest thing you have is prose: "the paragraph under Success metrics." Prose under-specifies. Claude has to guess. On a long document, it guesses the neighborhood and regenerates for consistency.
Projects does not change this because Projects does not change what the chat box accepts as input. Attachments do not change it because they do not either. What does change it is giving Claude a verbatim quote, which is a precise coordinate the model can match exactly.
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 announcement post is a useful primary-source companion.
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; OMGfixMD is what we built so the second part takes one click instead of ten minutes of scratch-buffer formatting.
OMG.