string-reviewer

String Reviewer — официальный skill Gemini CLI для ревью пользовательских строк и текстовых ответов внутри кодовой базы. Он применяется к подписям интерфейса, сообщениям об ошибках и ответам AI, когда нужно проверить ясность, полезность, краткость и единообразие формулировок. Результат этого workflow — список предложений по улучшению, а не скрытая правка файлов: исходник прямо запрещает автоматически менять строки без одобрения пользователя. Поэтому карточка подходит для редакторского прохода перед ручным внесением изменений и не должна трактоваться как команда переписать весь интерфейс. Центральное правило — отделять детерминированное состояние системы от вероятностного анализа Gemini. В тексте нужно различать Cloud Billing, IAM, систему и CLI как источники фактического выполнения или состояния, а Gemini называть участником анализа, который может предлагать интерпретации. Для сообщений о состоянии skill рекомендует техническую прозрачность: вместо общего Loading... показывать короткий конкретный этап, например трассировку stack trace. При этом статусные сообщения должны укладываться в пять слов, чтобы оставаться сканируемыми. Для структуры текста используется принцип Goal + Action: первые слова должны называть цель пользователя и действие, которое следует выполнить. Проверка skip test задаёт практический критерий — первые три слова должны помогать понять намерение. В статусах убираются вежливые заполнители вроде Please wait, Thank you и Certainly; вместо них показываются данные или прогресс. Для операций дольше трёх секунд источник допускает цикл коротких технических состояний, например чтение логов и поиск паттернов, чтобы пользователь видел движение работы, а не неопределённое ожидание. В техническом ревью важен выбор глагола. Для состояния системы используются детерминированные is, will и must, а для вывода AI — probabilistic-формулировки suggests, appears, may и identifies. Skill запрещает приписывать сгенерированному тексту абсолютную уверенность. Вместо расплывчатых слов speed и cost следует называть измеримые признаки — latency, tokens и compute. Каждое предупреждение должно содержать одно конкретное исправляющее действие, например dry-run или проверку указанной строки, иначе предупреждения только увеличивают шум. Для ошибок задано правило agentic recovery: сообщение должно быть точкой перехода к одному ближайшему пути исправления. Сначала даётся понятное человеку объяснение, затем машинный код вроде 404 или 500; к ошибке добавляется ровно один recovery command, link или copyable prompt. Это не означает, что skill сам запускает исправление. Он предлагает проверить, есть ли у пользователя конкретный следующий шаг, и оставляет управление изменением текста или кода человеку. Ревью также сверяется с word list исходного репозитория. Термины, отмеченные как недопустимые или требующие осторожности, нужно заменить на предпочтительные формулировки из этого списка. Для настроек есть отдельная граница: если изменяется packages/cli/src/config/settingsSchema.ts, labels и descriptions проверяются по специальным settings guidelines. Итоговый отчёт должен следовать фиксированному списочному формату: сначала принцип или причина, затем исходная фраза с крестиком и предложенная формулировка с галочкой. Ограничения источника существенны для применения. String Reviewer не является автоматическим редактором, не обещает сохранить продуктовый смысл без контекста и не заменяет согласование изменения с владельцем интерфейса. Его назначение — обнаружить неясность, лишнюю длину, нестыковку терминов, слабую диагностику или отсутствие пути восстановления и оформить проверяемые предложения. После ревью нужно отдельно решить, какие пункты принять, проверить их в реальном UI или CLI и только затем вносить ручные изменения.