# Python Developer

> Разрабатывать Python-код: приложения, сервисы, API, CLI, refactor, tests, performance и production/integration debugging.

- Skill: `maslennikov-anton/python-developer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add maslennikov-anton/python-developer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maslennikov-anton/python-developer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: Maslennikov-Anton (https://skillmd.com/u/maslennikov-anton)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/maslennikov-anton/python-developer

---


# Python-разработчик

## Workflow

1. Уточни задачу и критерии приемки.
2. Изучи текущую архитектуру и соглашения по коду.
3. Реализуй минимальное, корректное и поддерживаемое изменение.
4. Добавь или обнови тесты рядом с измененным поведением.
5. Прогони проверки стиля, типизацию, тесты и граничные случаи.
6. Проведи self-review diff/evidence перед завершением задачи.
7. Подведи итог по изменениям, рискам и дальнейшим шагам.

## Инженерные стандарты

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

## Ожидания по тестированию

- Добавляй unit-тесты для бизнес-логики.
- Добавляй integration-тесты, если изменение затрагивает внешние системы.
- Покрывай граничные и негативные случаи, а не только happy path.
- Fixtures должны быть детерминированными и быстрыми.

## Post-Implementation Checklist

После реализации фичи по умолчанию:

1. Прогони formatter и linter проекта.
2. Прогони type checks, если они есть в проекте.
3. Прогони релевантные тесты.
4. Проведи self-review изменений; формальный `code-review-professional` используй только для high-risk или requested review.
5. Только после этого считай задачу завершенной.

Для мелких безопасных правок без изменения поведения допускается облегченный режим, но для feature, bugfix, refactor, DB change и API change полный checklist является стандартом.

## Типовой выбор стека

- Packaging и зависимости: стандарт проекта (`pip`, `poetry` или `uv`).
- Тестирование: `pytest`.
- Проверки стиля и типов: стандарт проекта (`ruff`, `mypy` или аналоги).
- Web/API: следуй конвенциям фреймворка в репозитории (`FastAPI`, `Django`, `Flask` и т.д.).

## Формат ответа

Когда просят выполнить Python-работу, возвращай:

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

## Связь с локальными стандартами

Если задача касается не только Python-разработки, но и изменения общих инженерных правил, эволюции локальных skills, внедрения нового стека как стандарта команды или пересмотра статуса технологии, дополнительно используй `team-engineering-style`.

Если нужен профессиональный разбор рисков, регрессий, качества изменений и полноты тестов, дополнительно используй `code-review-professional`.