Instruction files

Connecting gives your assistant the capability. The instruction file tells it when to reach for it. Without one, a connected assistant often carries on exactly as before — the memory is there, and it never occurs to it to look.

Where yours lives

Those are the project paths. Several clients also have a global file; the editor picker shows both. .cursorrules and .kilocode/ are legacy migration paths, not the current targets.

Why this changes how you work

The managed block teaches the assistant an operating loop: resolve project scope, ground the current request, choose the right evidence, consult durable project knowledge before guessing, and preserve plans, decisions, lessons, or stopping points in the shape that can return later.

That is the initiative layer of the partnership. You can say “finish the next safe step in the billing migration” without first teaching a new chat where plans live, how to find yesterday's failed test, or when to check a lesson. The assistant has standing guidance to orient itself.

Where an editor supports lifecycle hooks, relevant context and warnings can also be surfaced at the moment a turn starts or an action is about to happen. Other supported clients rely on the same generated instructions. Neither path grants execution permission the client did not already provide.

Keep the generated block managed

The setup generates the right file for each editor, matched to the version of the server you're connected to. The normal update refreshes configured editors' managed instructions for you:

contextstream-mcp update

Use the focused command when you are repairing, previewing, or deliberately regenerating only the instructions:

contextstream-mcp update-rules
contextstream-mcp update-rules --scope global    # every project
contextstream-mcp update-rules --dry-run         # see what would change

Hand-written instructions referencing an outdated ContextStream interface are worse than none: the assistant tries to use something that no longer exists and gives up on the whole integration.

Your own rules go in the same file

The generated block is marked. Add your project's conventions around it and they'll be preserved when you regenerate:

<!-- your rules -->
- Errors wrap with context; never return a bare `err`.
- Migrations are additive. Never edit one that has shipped.

<!-- generated block, replaced by update-rules -->

Conventions checked into one of these project files are available to the client that loads the file and, when you share the repository, to collaborators who clone it. Different clients use different filenames, so run setup for every editor you or your collaborators actually use; the wizard writes equivalent managed guidance to each selected target.

Global or per project

--scope project    # this repository
--scope global     # every project on this machine
--scope all        # both (the update-rules default)

Global for how you work. Project for how this codebase works.

This is also where the user contributes to the partnership once instead of correcting every session. Put stable project conventions here; use lessons for mistakes that should match a trigger, decisions for recorded choices, and skills for procedures an assistant can apply.

If it doesn't work

The assistant ignores the rules. Some editors read these files only at startup. Restart it.

It uses the memory inconsistently. The generated block is out of date relative to the server. contextstream-mcp update-rules.

My edits were overwritten. They were inside the generated block. Move them outside it — that region is replaced wholesale.

Next

• What to say once it's connected
• How the agent partnership works
• Keeping it current
• Set it up by hand