cli-creator

Этот навык предназначен для создания долговечного CLI, которым Codex сможет пользоваться по имени из любого рабочего каталога. Источник прямо отделяет такой инструмент от одноразового скрипта: если небольшая задача решается коротким скриптом внутри текущего проекта, полноценный CLI для неё не нужен. Основой могут быть документация API, OpenAPI-описание, примеры curl, SDK, веб-приложение, административная панель или существующий локальный скрипт. До разработки нужно назвать целевой инструмент, его источник и первые реальные операции, например поиск черновиков, загрузку логов или чтение очереди, а также проверить, не занято ли выбранное имя командой command -v. Рабочий процесс начинается с осмотра доступного toolchain: проверяются cargo, rustc, node, pnpm, npm, python3 и uv. Для переносимого CLI по умолчанию предлагается Rust благодаря одному быстрому бинарнику, аргументам, JSON и простой установке в ~/.local/bin. TypeScript/Node оправдан, когда важны официальный SDK, существующие Node-инструменты или браузерная автоматизация, а Python подходит для анализа данных, локальных преобразований, SQLite, CSV и JSON. Выбор должен учитывать не моду, а уже установленную среду и источник данных; если нужного toolchain нет, инструкция советует не добавлять лишнее трение без явной пользы. Контракт команды должен быть понятен до написания кода. В help должны быть видны основные возможности, а команда doctor --json должна проверять конфигурацию, авторизацию, версию, endpoint и недостающие шаги настройки. Для повторного использования предусмотрен init с сохранением локальной конфигурации, discovery-команды находят проекты, рабочие пространства, команды, очереди или репозитории, а resolve превращает имя, URL, slug или permalink в стабильный идентификатор. Read-команды получают объект или коллекцию и ограничивают пагинацию limit, cursor или offset. Write-команды делают одно названное действие над узким ID и, если сервис позволяет, поддерживают dry-run, draft или preview; широкие команды fix, debug или auto не должны прятать внутри опасные записи. JSON-режим обязан оставаться стабильным и машинно читаемым: в документации фиксируются форма успеха и форма ошибки, а ошибки не содержат учетных данных. Нужен честный raw escape hatch для низкоуровневого запроса, но для него сначала следует поддержать read-only GET/HEAD и не отправлять живой небезопасный write без отдельного запроса. При работе с внутренним веб-приложением сначала составляется обезличенная заметка об endpoint, методе, заголовках, авторизации, CSRF, теле, идентификаторах, пагинации и ошибках. Cookies, bearer-токены, customer secrets и полные production payloads в CLI не переносятся. Скриншот помогает понять поля и точки подтверждения, но сам по себе не является доказательством API-контракта. Авторизация следует простому порядку: стандартная переменная окружения, затем файл конфигурации вроде ~/.tool-name/config.toml, и только для явного одноразового теста флаг ключа. doctor --json сообщает лишь наличие токена, категорию источника и отсутствующий шаг, но никогда не печатает секрет. После реализации инструмент ставится в PATH, а smoke-проверка выполняется из другого репозитория или /tmp: command -v, --help и --json doctor должны работать вне исходной папки. Затем запускаются форматирование, typecheck или build, тесты сборщиков запросов и пагинации, no-auth doctor и хотя бы один fixture, dry-run или read-only вызов. Такой навык задаёт безопасную последовательность проектирования CLI, но не заменяет проверку реального API, прав доступа и бизнес-правил конкретного сервиса.