Five changes that made Claude useful between chat sessions

My first months with Claude followed the same loop: ask a question, get a polished answer, copy part of it somewhere, then lose the useful context before the next conversation. The model was capable. My workflow was disposable.

The improvement did not come from learning clever prompts. It came from giving different kinds of work a durable home and matching each job to the Claude surface that could actually complete it. Quick thinking still belongs in chat. Ongoing research belongs in a Project. Local file work belongs in the desktop app. Repository changes belong in Claude Code. Repeated standards belong in instructions or Skills.

That division sounds obvious after you adopt it. Beforehand, every Claude product looks like another chat box.

Decide where the result should live before choosing the interface

The first question I ask now is not “What prompt should I use?” It is “Where should the result exist when this conversation ends?” That one decision removes a lot of copying and cleanup.

• A temporary explanation or brainstorm: regular web or mobile chat is enough.
• A document that must survive as a file: use the desktop workflow and grant access only to a dedicated folder.
• A recurring body of research: create a Project with the source material and project-specific instructions.
• A code or configuration change: use Claude Code inside the actual repository so it can inspect, edit, and test the work.
• A procedure you repeat: capture it as reusable instructions or a Skill rather than pasting the same checklist again.

This is less glamorous than prompt engineering, but it changes the result from text you read into work you can reopen. A useful answer with no destination becomes another browser tab. A merely good answer saved in the correct project can improve over several sessions.

The distinction also clarifies permissions. A chat does not need access to my Downloads folder. A file-sorting task does. A code-review question may need read access to a repository but should not be allowed to deploy anything. Starting with the destination makes those boundaries easier to set.

Use chat for thinking, not for pretending work is finished

The web interface remains the fastest place to explore a question. I use it for outlining, comparing approaches, explaining an unfamiliar term, and turning rough notes into a structure. It is particularly good when I do not yet know whether the task deserves a project.

What changed is that I stopped treating a chat response as the final artifact. If the output matters, I move it into its real home while the context is fresh. That might mean creating a Markdown file, updating a planning document, or opening the repository where the change belongs.

A small handoff checklist keeps the work from evaporating:

• Name the decision that was made.
• Save the useful output in a file or project.
• Record unresolved questions beside it.
• Link the sources that informed the answer.
• State the next action in plain language.

Without that handoff, the next session starts with archaeology. You search old conversations, reconstruct assumptions, and ask the model to repeat work it already did. The friction is not caused by a weak model. It is caused by using a conversation log as a filing system.

Give continuing work a Project, not a giant opening prompt

A Claude Project is useful when the same source material should inform more than one conversation. I create one for a site, course, client, or research track, then add only the references that belong to that context. Project instructions describe the output standards and the boundaries that stay true across sessions.

The effective part is not stuffing the Project with everything you own. It is curating a small working set. Ten current files with clear names beat a hundred stale exports. I include a short orientation note that explains what each document is, which source is authoritative, and which decisions are already settled.

My baseline Project setup looks like this:

• README.md explains the goal, audience, and current state.
• DECISIONS.md records choices that should not be reopened casually.
• SOURCES.md links evidence and notes when it was checked.
• A deliverables folder holds the current drafts rather than old copies with names like final-v7-really-final.
• Project instructions define tone, formatting, and actions Claude must not take.

This structure gives Claude context without requiring it to infer authority from file dates. It also helps humans. If the Project disappears tomorrow, the folder still explains itself.

Projects are not automatic memory. A model can still miss a document or overvalue an outdated note. Keep instructions concise, remove stale sources, and restate high-risk constraints in the active request. Durable context reduces repetition; it does not eliminate verification.

Let the desktop app touch one safe folder at a time

The desktop app becomes more useful when a task ends in a local file. Instead of asking for a table and copying it into a spreadsheet, I give it a narrow workspace and ask it to create the spreadsheet there. The same pattern works for document cleanup, organizing a batch of notes, or converting source material into a report.

Folder scope matters. I do not grant broad access to my home directory for convenience. I create a task folder, copy in the files needed for the job, and keep unrelated personal or client material outside it. That creates a visible boundary I can inspect before approving an action.

A safe local workflow has four parts:

• Input: a folder containing copies of the source files.
• Instruction: an explicit deliverable name and format.
• Constraint: a rule not to delete or overwrite the inputs.
• Verification: open the resulting file in the application that will actually use it.

The last step is easy to skip. A generated .docx existing on disk does not prove Word renders the headings correctly. A spreadsheet with formulas is not finished until a spreadsheet app recalculates them. File creation is evidence that the tool acted, not evidence that the deliverable works.

I also keep sensitive inputs out of these folders unless the task genuinely requires them. Granting access is not the same as publishing a file, but the least-data rule still applies: if Claude does not need a tax return to reorganize meeting notes, the tax return should not be in reach.

Use Claude Code when the work must survive a diff and a test

Claude Code is the appropriate surface when the answer is supposed to become a repository change. It can inspect related files, follow call paths, edit the implementation, and run the same checks a human contributor would run. The terminal is not valuable because it looks technical. It is valuable because the work happens where version control and tests can evaluate it.

I start code tasks by asking for inspection before editing. The agent should identify the affected function, its callers, the relevant tests, and the command that demonstrates the current behavior. Then it can make the smallest change that solves the stated problem.

My approval checklist is deliberately boring:

• Review the diff, including files I did not expect to change.
• Confirm no secrets or generated caches entered the repository.
• Run the targeted test that exercises the behavior.
• Run the relevant regression suite.
• Exercise the feature at the layer where a user experiences it.

A green unit test can coexist with a broken application. A clean diff can hide a config change that the running process has not loaded. Claude Code accelerates implementation, but it does not change what completion means.

Non-developers can still benefit from this surface for repositories of Markdown, static-site content, or configuration. The useful skill is not memorizing shell commands. It is learning to demand a reviewable change and real verification rather than accepting confident prose about what probably happened.

Put stable preferences in instructions and repeatable procedures in Skills

Custom instructions are appropriate for broad, stable preferences: sentence length, formatting, the kind of explanation you prefer, or a standing ban on destructive actions without confirmation. Project-specific rules belong with the Project. A multi-step procedure that should run the same way each time belongs in a Skill.

I use a simple test:

• If it applies to nearly every conversation, put it in global instructions.
• If it applies to one body of work, put it in project instructions.
• If it describes how to execute and verify a recurring task, make it a Skill.
• If it is true only today, keep it in the current request or task note.

A good Skill includes trigger conditions, exact steps, failure handling, and verification. It also needs maintenance. When a run exposes stale guidance, update the procedure while the evidence is available instead of automating the same known mistake.

Trade-offs

This workflow asks you to maintain more structure. Projects need pruning, instructions need editing, and Skills can become liabilities when nobody verifies them. The setup time is small for one task but noticeable across many projects.

Permissioned tools also increase the blast radius of a bad instruction. A chat response can be wrong; an agent with file access can be wrong in a way that changes your work. Narrow folders, version control, backups, and confirmation boundaries are not optional ceremony. They are what make the extra capability tolerable.

There is a cost difference too. Long Projects and repository sessions consume more context than a quick chat. Use the lightest surface that can produce the required artifact. Do not open a coding agent to rewrite a two-sentence email, and do not force a complex file transformation through a browser chat because it feels familiar.

Finally, none of these products makes output self-verifying. Claude can generate a document, run a test, or report that a command succeeded while still missing the user’s actual need. The person operating the workflow remains responsible for defining success and checking the final layer.

What I would tell past me

The year I thought I was “using Claude wrong” was mostly a year of asking one interface to do every kind of work. The correction was organizational, not mystical.

• Choose the artifact’s home before writing the prompt. The destination tells you which tool and permission scope fit.
• Use Projects as curated workspaces, not memory landfills. Fewer current sources produce better context.
• Grant one local folder, not the whole machine. Convenience is not a reason to erase boundaries.
• Demand diffs and tests for repository work. A narrated change is not an implemented change.
• Promote repeated procedures into maintained Skills. Repetition should improve the workflow, not merely repeat it.

The web chat is still part of my day. It is simply no longer the place where every task begins and ends. Once the work has a durable home, Claude becomes useful between conversations rather than only during them.