Cursor

После нескольких недель использования cursor на ежедневной основе, на нескольких проектах сложился небольшой алгоритм.

1. Обязательно создаю файл .cursorrules. Сейчас у меня в нем:
   • “включение эксперта”
   • требования по формату ответа: язык, отсутствие извинений, краткость и так далее
   • “заклинания” для улучшения качества ответов: “Your answer is critical for my career” и так далее
   • ссылка на README.md и инструкции по работе с ним:
     • If I write a new requirement or change an existing one, you must add it to the Requirements section in README.md.
     • If I write about changes in the project’s algorithm, you must add these changes to the Algorithm section.
     • The contents of README.md and tests are more important than the code!
     • If I change the code, you must check that it meets the requirements.
   • ссылки на другую документацию в проекте, если она есть
   • требования к коду (clean, KISS, best practice, etc.)
2. Пишу тесты отдельно от кода и перед кодом, на основе требований README.md и промпта, без добавления кода в контекст. Возможно, это паранойя, но пока мне не нравится, насколько точно он генерирует тесты по коду, включая все спорные моменты.
3. В режиме composer указываю в контексте все файлы, которые потребуется менять. Даже в режиме “agent” он может не найти все файлы, которые нужно, и создать рядом новый. Проще всего их указывать, открывая все нужные файлы и делая “Reference Open Editors” через “/” в composer.
4. Сбрасываю контекст каждый раз, когда перехожу к следующей задаче.
5. Использую claude-3-5-sonnet, т.к. он более управляемый и по качеству, в целом удовлетворяет. Для “архитектурных” вопросов использую o1, отдельно.
6. Использую “@”, особенно для документации на штуки, про которые модель не знает. Через @Web можно временно добавить страницу в контекст, через @Doc можно добавить на постоянной основе. Я загоняю туда документацию по всем связанным сервисам.

Не хватает:

• Из-за того, что у меня параллельно несколько проектов, мне приходится переключать окружение терминала (ssh-ключи, авторизации aws/gcp/terraform/etc, переменные окружения). И пока не понятно, как это сделать для агента, чтобы он мог, например, вызвать ansible-playbook или terraform plan и “увидеть” результат.
• Хотелось бы более тесной интеграции с git, чтобы агент умел коммитить самостоятельно, предварительно запуская тесты, линтеры, анализаторы кода и так далее.
• Большей интерактивности, чтобы агент больше спрашивал, что я имею в виду, какой вариант выбрать и так далее.

After several weeks of using the cursor on a daily basis, a small algorithm has developed across several projects.

1. I always create a .cursorrules file. Currently, it contains:
   • “enable expert”
   • response format requirements: language, no apologies, brevity, etc.
   • “spells” to improve response quality: “Your answer is critical for my career,” etc.
   • link to README.md and instructions for working with it:
     • If I write a new requirement or change an existing one, you must add it to the Requirements section in README.md.
     • If I write about changes in the project’s algorithm, you must add these changes to the Algorithm section.
     • The contents of README.md and tests are more important than the code!
     • If I change the code, you must check that it meets the requirements.
   • links to other documentation in the project, if available
   • code requirements (clean, KISS, best practice, etc.)
2. I write tests separately from the code and before the code, based on the requirements of README.md and the prompt, without adding code to the context. Maybe it’s paranoia, but so far I don’t like how accurately it generates tests based on the code, including all controversial points.
3. In composer mode, I specify all the files that need to be changed in the context. Even in “agent” mode, it may not find all the necessary files and create a new one nearby. It’s easiest to specify them by opening all the necessary files and doing “Reference Open Editors” through “/” in composer.
4. I reset the context every time I move on to the next task.
5. I use claude-3-5-sonnet because it is more manageable and generally satisfactory in quality. For “architectural” questions, I use o1 separately.
6. I use “@”, especially for documentation on things the model doesn’t know about. Through @Web, you can temporarily add a page to the context, and through @Doc, you can add it on a permanent basis. I load documentation on all related services there.

Missing:

• Because I have several projects in parallel, I have to switch the terminal environment (ssh keys, aws/gcp/terraform/etc authorizations, environment variables). And it’s still unclear how to do this for the agent so that it can, for example, call ansible-playbook or terraform plan and “see” the result.
• I would like closer integration with git so that the agent can commit independently, running tests, linters, code analyzers, etc., beforehand.
• More interactivity, so the agent asks more about what I mean, which option to choose, and so on.