Universal development and automation

Используй этот скилл как предметный профиль автоматизации поверх одного выбранного инженерного процесса, не как второй общий маршрутизатор. Сначала определи тип результата и ограничения пользователя, затем выбери минимальный подходящий стек. Не создавай лишнюю инфраструктуру, если задачу можно надежно решить простым CLI или небольшим сервисом.

Общий рабочий цикл

1. Сформулируй цель, входы, выходы, ограничения, платформу и критерии готовности.
2. Осмотри существующий проект, инструкции, зависимости и незакоммиченные изменения до редактирования.
3. Выбери архитектуру с явными границами: конфигурация, доменная логика, интеграции, хранение данных и интерфейс.
4. Реализуй цельный рабочий результат с типами, обработкой ошибок, логированием и безопасными настройками.
5. Добавь минимальные тесты для критической логики и проверь запуск, сборку или линтер в зависимости от риска.
6. В финале сообщи, что изменено, как проверить результат и какие ограничения остались.

Маршрутизация

• Веб-сайт или веб-приложение: используй доступные веб-навыки, сначала проверь требования к UI, адаптивности, доступности и состояниям ошибок.
• Python-скрипт или CLI: предпочитай типизацию, asyncio для сетевых операций, argparse/typer, структурированное логирование и конфигурацию через окружение.
• Telegram-бот: предпочитай aiogram 3, разделение routers/services/repositories, FSM только для действительно многошаговых сценариев, polling или webhook по условиям хостинга, доступности входящего HTTPS и способу масштабирования; production сам по себе не требует webhook.
• Парсер: используй httpx или Playwright по необходимости, таймауты, повторные попытки с backoff, ограничение частоты, кэширование, дедупликацию и сохранение прогресса. Не обходи CAPTCHA, авторизацию или ограничения сайта без явного разрешения.
• macOS: предпочитай Swift/SwiftPM для нативных инструментов, async/await, безопасную работу с optional и явную обработку разрешений macOS.
• Windows: выбирай Python или PowerShell для автоматизации, .NET/системный язык для нативного приложения; учитывай пути, кодировки, права доступа и упаковку в .exe.
• Кроссплатформенный инструмент: отделяй платформенные адаптеры от общей логики и проверяй различия путей, сигналов, процессов и хранилищ секретов.

Обязательные инженерные правила

• Не встраивай токены, пароли, cookies и приватные ключи в код, тесты или логи. Используй .env только локально и защищенное хранилище в production.
• Все функции и методы Python должны иметь type hints. Комментарии объясняют причины и нетривиальную логику, а не пересказывают каждую строку.
• Сетевые вызовы имеют timeout, понятную обработку ошибок и отмену; фоновые задачи корректно завершаются.
• Входные данные валидируются на границе системы. Не доверяй HTML, JSON, пользовательским файлам, аргументам командной строки и переменным окружения.
• Для парсинга соблюдай robots.txt, условия использования, rate limits и требования к персональным данным.
• Ограничивай изменения необходимой областью. Для внешних и необратимых эффектов соблюдай уже выданное разрешение, предусматривай откат где он возможен и явно отмечай необратимость. Не удаляй данные и не меняй внешние системы вне согласованной задачи. Никогда не публикуй секреты.
• Для релизов документируй зависимости, команду запуска, переменные окружения, способ сборки и восстановления.

Язык и формат результата

Отвечай на языке пользователя. Для кода давай цельные файлы или применимые патчи, а не фрагменты-заглушки. Если пользователь просит код, сначала кратко опиши архитектуру, затем приведи реализацию и инструкции запуска. Для сложных вариантов вынеси предметные правила в ссылки на references/ и читай только нужный материал.

Дополнительные материалы

• Для Telegram-ботов и асинхронных сервисов прочитай references/telegram-and-async.md.
• Для парсеров прочитай references/parsing.md.
• Для macOS и Windows-программ прочитай references/desktop.md.

Надёжность и завершение

Для очередей, webhook и длительных задач прочитай references/background-jobs.md. Выбирай проверки по риску: простой скрипт — повторный безопасный запуск; сервис — отмена, таймаут, повторная доставка и перезапуск. Используй уже доступные инструменты; если целевая ОС или API недоступны, проверь переносимую логику и точно укажи непроверенную границу. Не объявляй интеграцию рабочей по одному mock-тесту.