Write docs for your lib that Cursor can use right away

tl;dr I’m writing a new library in a less popular language and I found a way to get the Cursor docs tool to consistently take a prompt, tag the relevant doc and produce consistently accurate results.

I currently work in a less popular language called Crystal, which I’ve developed a new lib that wraps llama.cpp and lets me write native compiled apps that can use quantized models for inference and I get back structured responses from the model that get turned directly into classes in my app.

This is basically an agent layer that I can now use for local models, but as a binary and I’m hoping to create distributable AI apps that can utilize local compute power vs the cloud.

I was writing documentation on how to use it and I started experimenting with how I can use Cursor’s doc feature to let new users start using my lib super quickly and get productive as quickly as possible.

Here’s some conventions I’ve found that work fairly well and consistently:

  1. Keep the total information short and sweet, 500-1000 tokens in a single file. This is subjective based on which model is doing the tokenization, I used a Llama3 model to check locally.

  2. Group related texts, and include a code sample in every file. Docs without code samples tend to produce weird output

Here’s an example file that I’ve settled on for the concept of grammars:

FYI the screen shot was from a less refined version of the above linked doc example. I’m going to keep this as-is because it’s been working well and consistently, in my opinion.

The only limitation I’ve found so far is that the docs command for this only matters when you can specifically tag the doc you want in the side bar convo, let it generate the code in there and then apply it to the current file. This cumbersome and less fluid, but it’s still a good starting point.

I’m going to continue experimenting to see how I can make my docs as AI-friendly as possible and create workflows for others to use.

1 Like