Первый сеанс в новом инструменте задаёт привычки, поэтому начинать его стоит не с задачи, а со среды. После входа выберите рабочую папку и дайте агенту работу, которая ничего не меняет: попросите объяснить точки входа, ключевые модули, команды проверки и риски. Такой запрос одновременно проверяет индексирование, работу агента, терминал и то, что рабочий каталог именно тот, который вы думаете. Каждый из этих четырёх узлов способен подвести молча, и дешевле обнаружить это на задаче, у которой нет последствий.

Наивный старт выглядит иначе: открыть большой репозиторий и сразу попросить что-нибудь починить. Соблазн понятен - хочется увидеть эффект. Но агент, которому сразу разрешили менять плохо понятый код, быстро создаёт много правок и ложную уверенность, что он разобрался. Разбирать такой diff дороже, чем потратить один заход на карту проекта; к тому же по нему невозможно понять, что из происходящего - свойство инструмента, а что - особенность вашего репозитория. Первый заход тем и ценен, что даёт эталон поведения: пока он не снят, любую странность вы будете объяснять наугад.

Полезно один раз увидеть формулировку такого первого запроса. Ниже - исследование без изменений: точки входа и границы модулей, команды установки, линта, типов, тестов и сборки из файлов проекта, действующие правила и AGENTS.md, три риска перед первой правкой - с явным запретом ставить зависимости и ходить в сеть. Эта форма годится для любого нового репозитория, не только при знакомстве с Cursor.

Запрет на установку зависимостей в первом запросе - не перестраховка. Установка меняет состояние машины, тянет сеть и способна занять минуты, а её результат к пониманию проекта ничего не добавляет. Точно так же и сетевые команды: они превращают детерминированное исследование в зависимость от внешнего мира, где ответ зависит от того, что сегодня отдал чужой сервер. Первый заход должен читать, а не менять, - тогда его результат воспроизводим и его можно сравнить с тем, что вы получите завтра.

Ответ на такой запрос проверяют, а не принимают на веру, и проверка здесь дешёвая. Команды, которые агент назвал командами проекта, должны существовать в файлах проекта - откройте манифест и сверьте имена. Названные точки входа должны находиться по указанным путям. Если команда выглядит правдоподобно, но в проекте её нет, вы столкнулись с самым важным свойством инструмента: он умеет уверенно предлагать типичное вместо фактического. Заметить это на безобидном запросе полезнее, чем на правке, где такое же угадывание уходит прямо в код.