Build inference integrations in Cursor with focused context

Start with the execution path

Select the files that explain how a request enters the application, reaches the provider and returns to its caller. This often means the route handler, input schema, adapter, output type and relevant tests. Include installed dependency versions when they determine the implementation. Add a representative caller if it relies on behavior that the server code alone does not show.

State a verifiable outcome: for example, reject tensors with inconsistent row lengths while preserving the documented error envelope. Supply a valid example and an invalid example. Ask the assistant to trace the current path when the boundary is unclear. Resolve missing context before a broad edit, and keep unrelated experimental or generated files outside the focused task unless they answer a specific question.

Make recurring conventions easy to inspect

Cursor project rules can preserve repository guidance in .cursor/rules. Use them for durable conventions such as the location of schemas, ownership of authentication and required error formats. Point to maintained examples rather than copying large implementations that may drift.

• Keep public validation in the shared request schema.
• Keep provider credentials and protocol details inside the adapter.
• Preserve the application’s established response types.
• Use existing fixtures to verify transport failures and parsing.
• Explain any public contract change in the handoff.

Rules guide the coding assistant; runtime validation, access controls and repository checks enforce behavior. Keep task-specific notes with the change, and revise a project rule only when the work establishes a convention that future contributors should follow.

Review the change against its original purpose

Read the diff beside the requested outcome. Check the accepted and rejected inputs, the response seen by callers and any new dependencies or side effects. Trace one representative request through the finished code. A plausible explanation should agree with the actual implementation, not substitute for reading it.

Use targeted tests for changed behavior and a build when packaging may be affected. Fixtures should cover normal responses, invalid input and relevant transport failures. A bounded live integration check can verify the actual provider contract when needed, while reviewed evaluation data tests model quality separately. Finish with what changed, why it changed and what was verified. A useful handoff leaves the repository understandable to someone who never saw the coding conversation.