Pre-Load the Context

Before diving in, complete Read Before Tab so you can immediately evaluate whether your pre-loaded context improved the completion quality.

Inline completion models do not read your whole project. They see the current file and a limited window of related files, usually the ones currently open in your editor tabs. Your architecture, your type definitions in other directories, your utility functions in other modules: none of that exists to the model unless you put it in the window.

Here is the before and after: This has a concrete practical consequence. If you open a call site and start completing a function call without having the interface or type definition visible, the model will invent plausible-looking argument shapes. If you open the interface file first, then switch to the call site, the model has that type definition in its context window and will complete against your actual API, not an invented one.

The pre-load habit: before you complete at a call site, open the file that defines the type, interface, or function you are calling. Before you complete a database query, open the schema file. Before you complete a component's props, open the props type definition. One or two extra file opens, done before you start typing, change the quality of completions dramatically.

Paste this into Claude:

I want to test pre-loading. Pick a real call site in your project where you need to call a function or use a type defined in another file. Do the completion twice: (1) Close all related files and complete from scratch. Note what the model generates. (2) Open the file that defines the function signature or type, then switch back to your call site and complete again. Note what the model generates this time. Paste both completions here and tell me: what changed? What did the model get wrong in the first attempt that it got right in the second?

What good looks like:

• You ran both completions (without and with the pre-loaded file) and compared the outputs
• The pre-loaded completion used your actual types or parameter names rather than invented ones
• You can describe in one sentence what file to open before completing at a specific kind of call site in your project
• You identified at least one case where the model invented a plausible but wrong argument in the no-context version
• You now have a consistent pre-load habit for at least one common completion pattern in your project

What a good response looks like:

Here is the side-by-side comparison for completing a `createUser` call site in your API service:

Without pre-load (no files open except the call site): The model completed with `createUser({ name: data.name, email: data.email, role: 'user' })`. It invented `role: 'user'` as a default, which is not a field on your `CreateUserDto`. It also missed the required `organizationId` field entirely. The completion would have compiled but thrown a runtime validation error.

With `user.dto.ts` and `user.service.ts` open first: The model completed with `createUser({ name: data.name, email: data.email, organizationId: data.organizationId, createdAt: new Date() })`. It used your actual DTO fields, included `organizationId`, and correctly added `createdAt` which it saw in the service definition.

What changed: opening `user.dto.ts` gave the model your exact field names. Opening `user.service.ts` showed it the full method signature including required fields. Two extra tabs open, zero invented fields.

For your project: before completing any DTO call site, open the DTO file first. Before completing any service method call, open the service interface. This is the pre-load rule for your specific stack.