Specify the context

Context makes the difference

The quality of responses from grok-build-0.1 depends directly on the quality of the context you provide. A vague prompt yields a generic response. A prompt with the right context yields a response you can apply to your code immediately.

The problem with context-free prompts

Here’s a concrete example. You ask:

“Improve error handling”

The model doesn’t know:

• Which file to work in
• What type of errors you’re handling
• What your existing error codes are
• What your project structure looks like
• What dependencies you’re using

It will produce a generic response with standard try/catch blocks that probably won’t match your architecture.

How to specify context effectively

Mention relevant files

Editors like Cline and Cursor let you reference files using @. Use this feature consistently:

“My error codes are defined in @errors.ts. Use them as a reference to add appropriate error handling in @sql.ts, where I’m making queries”

The model now sees the actual files, understands your conventions, and produces code that’s consistent with your codebase.

Describe project structure

When you’re working on a new project or a part of the code the model doesn’t know yet, briefly describe the structure:

“The project uses Express with TypeScript. Routes are in src/routes/, services in src/services/, and types in src/types/. I’m working on the authentication service.”

Specify dependencies

If your code uses specific libraries, mention them:

“I’m using Zod for validation, Drizzle for the ORM, and Pino for logging. Add validation to the input schema in @api/users.ts”

Exclude what’s irrelevant

Excluding what isn’t relevant is just as important as including the right context. If you reference 15 files for a simple change, the model may get lost. Focus on the files directly involved.

Before/after examples

Test generation

Without context: “Write tests for my validation function”

With context: “Write Vitest tests for the validateUser function in @src/validators/user.ts. Test fixtures are in @tests/fixtures/users.json. Use the same pattern as @tests/validators/product.test.ts”

Refactoring

Without context: “Refactor this code to make it cleaner”

With context: “Extract the retry logic in @src/api/client.ts (lines 45-78) into a reusable helper in @src/utils/retry.ts. The other API clients in @src/api/ should be able to use it too”

Key takeaways

• Always reference relevant files with @
• Describe the project structure when necessary
• Mention the dependencies and conventions you use
• Exclude irrelevant information to avoid noise
• The more precise the context, the more directly you can apply the response