Persist the preferences; name the outcomes
Two scopes of memory worth distinguishing
An assistant can remember things at two scopes that are worth keeping separate. A project scope, often anchored in a file inside a working folder, holds the conventions, vocabulary, and constraints that apply to one piece of work. A user scope, often anchored in a settings file or an internal memory layer, holds the preferences that apply across all of the worker's projects. Keeping the two distinct prevents the common failure of project-specific assumptions leaking into other work and a personal preference being lost the moment a new folder is opened. Both layers are simple text files. The discipline is in what goes in each.
What belongs in each scope
The project file is the right home for anything specific to the work itself: the audience, the tone, the project glossary, the deliverable format, the conventions of the team or organisation, the things the assistant tends to get wrong on this particular work. The user file is the right home for anything that travels across projects: spelling preferences, the preferred level of explanation, the working hours, the saved corrections that recur regardless of context. A test for which file something belongs in is whether it would still be true on the next project. If yes, it is user-level; if no, it is project-level.
Slash commands as parameterised prompts
A slash command — typically a short word preceded by a forward slash — is the lightest mechanism for turning a recurring move into a single action. Under the surface, the command is usually a saved prompt template with a small amount of context wired in. A worker who writes a slash command for their daily briefing, their weekly report draft, their meeting-note tidy-up, and the half-dozen other moves they perform routinely has converted the friction of starting each task into the friction of typing one short word. The reduction in friction is what makes recurring tasks actually happen, rather than being skipped on the days they would have been most useful.
Name after the outcome, not the mechanism
The most consequential decision in a slash-command library is rarely technical. It is what each command is called. A command named after the mechanism that produces the outcome — improve-skill, refactor-context, parse-document — describes the machine's view of the work and reads as machinery on the day it is most needed. A command named after the outcome the worker actually wants — improve-system, prepare-meeting, tidy-notes — describes the worker's view and is the name they will reach for when tired. The shift from mechanism-naming to outcome-naming is a small change that makes the whole arrangement legible months later, when the person reading the command names is the same person who wrote them but no longer remembers why.
Of the corrections you have made to an assistant in the last month, how many would you have to make again if you started a new session right now?