Coding Assistant Preferences: Resolve Scope Before Adding More Memory

When a coding assistant uses the wrong formatter or test framework, the problem may be conflicting instructions rather than missing storage. A personal preference, a repository rule, and a task-specific request can all be present while the assistant applies the wrong one.

Treat preference handling as a resolution problem. Decide which scope a preference belongs to, where its authority comes from, and when an exception ends. More remembered text can make the conflict worse if those relationships stay implicit.

Separate three kinds of preference

A developer may prefer short comments across projects. A repository may require a particular test runner. A single task may ask for an unusually detailed migration explanation. Store those as different records rather than merging them into “the user likes detailed TypeScript tests.”

Scope	Example	Useful source
Personal	Prefer concise explanations	Explicit user setting
Repository	Use the project's existing test runner	Maintained project instructions and configuration
Current task	Explain every migration step	Active request

This is an application policy, not a universal hierarchy every coding product implements identically. Check the assistant's own instruction behavior. Claude Code documents its memory files and management commands; keep native rules and plugin behavior distinguishable.

Make exceptions expire with the task

“Use detailed logging while investigating this failure” should not silently become a permanent repository convention. Mark the scope and purpose when capturing the request. When the task ends, keep any useful diagnostic conclusion without retaining the temporary instruction as a standing rule.

A correction is different: “We migrated from Jest to Vitest” changes a project fact. Verify the current package configuration and update the source-backed record. An old memory is a lead for investigation, not authority to ignore today's repository.

Test the conflicting case, not only the happy path

Create two disposable projects with different test frameworks. Keep the same personal preference in both. Ask the assistant to add a small test, then introduce a one-task exception and start a fresh conversation afterward.

Inspect which source supplied each instruction. Failure means more than producing the wrong framework: applying one project's conventions to another is also a scope error. A system that remembers everything but cannot distinguish scope is not providing reliable personalization.

Use memory for the context that actually needs it

Stable repository rules often belong in version-controlled instructions. A remembered explanation can help recover why the team rejected an alternative, provided it links to the decision and remains current. Avoid moving every deterministic setting into semantic retrieval.

The Claude Code memory guide compares native and external paths. To try repository-specific continuity, follow the Supermemory Claude Code setup and test one preference conflict before expanding capture.