База знаний Антона Сидорова
База знаний по аналитике, ИТ архитектуре, API. Документирование. Тесты инструментов.
Project maintained by daemon110282
Hosted on GitHub Pages — Theme by mattgraham
Spec-Kit
Зачем
Spec-Kit реализация фреймворка SDD (Spec-Driven Documentation) для разработки технической документации в репозитории, подход docs-as-code без изменения технологического стека разработки.
Кастомизация Spec-Kit.
TODO
Процесс
0. Init
Init project.
Запускается один раз в проекте, чтобы создать структуру каталогов под LLM и базовые файлы для SDD:
specify init taskify --integration copilot
specify init . --integration copilot
specify init . --integration copilot
0.1 Update
Guide
1. Constitution - Конституция, стандарты, принципы
Для существующих проектов — дайте команду проанализировать существующую кодовую базу:
/speckit.constitution
Проанализируй текущий код и создай constitution на его основе.
Best practices:
- Используйте ChatGPT для генерации первого драфта constitution
- В репозитории SpecKit есть примеры — берите за основу и адаптируйте под свой проект
- Если в компании есть coding standards — превратите их в constitution один раз, используйте во всех проектах
Что включать:
- Архитектурные принципы
Стиль архитектуры (Feature-Sliced Design, Clean Architecture, Microservices)
Паттерны проектирования, которые вы используете
- Технические ограничения
Языки и их версии (TypeScript, PHP 8.2+, строгая типизация)
Обязательные инструменты (ESLint, Prettier, PHPStan)
Запрещённые библиотеки или подходы
Требования к совместимости
- Стандарты качества кода
SOLID принципы, DRY, KISS
Стандарты именования (camelCase, snake_case)
Максимальная длина функций/классов
Требования к комментариям и документации
- Тестирование
Какие тесты обязательны (unit, integration, e2e)
Coverage требования (если есть)
Test-Driven Development подход (если используете)
Стратегия тестирования (AAA pattern, Given-When-Then)
- Git и коммиты
Стратегия коммитов (один коммит на таску, conventional commits)
Формат commit message
Стратегия бранчей
Требования к PR
- UX/Accessibility
Стандарты доступности (WCAG AA/AAA)
Поддержка устройств (mobile-first, responsive)
Производительность (Core Web Vitals)
- Security и Privacy
Требования безопасности
Обработка персональных данных
Compliance (GDPR, и т.д.)
2. Specify - Бизнес требования
specs/001-feature-name/spec.md
Best practices:
- Используйте “ДОЛЖНА/МОЖЕТ/НЕ ДОЛЖНА”
- Разделяйте MVP и будущие фичи
- User Story Mapping
- Используйте ChatGPT для первого драфта
3. Clarify - Уточнение бизнес требований
- Интервью с умным коллегой
- Запускайте clarify после больших изменений spec.md, чтобы убедиться, что требования согласованы и не противоречат друг другу.
4. Checklist - Чек-листы качества
- Аудит по стандартам качества
/speckit.checklist [тема]
Доступные темы:
/speckit.checklist UX
/speckit.checklist Security
/speckit.checklist Performance
/speckit.checklist Accessibility
/speckit.checklist SEO
/speckit.checklist Testing
Любая кастомная тема
/speckit.checklist Mobile-First Design
/speckit.checklist Data Privacy GDPR
/speckit.checklist API Design Best Practices
5. Plan - Технический план
Пример:
/speckit.plan
Backend: Python FastAPI + TypeScript
Frontend: Vue.js 3
UI: Tailwind CSS + shadcn-vue
Редактор: Markdown редактор с live preview
Telegram: python-telegram-bot
База данных: PostgreSQL
Кэш: Redis для очереди публикаций
Деплой: Docker
Best practices:
- Каждое изменение стека/архитектуры → обновление plan.md
- Запросите альтернативы для ключевых решений
- Используйте ChatGPT для review плана
Вот технический план проекта: [вставляете plan.md]
Проанализируй:
1. Есть ли переусложнения?
2. Где могут быть bottleneck'и?
3. Какие риски ты видишь?
4. Что можно упростить для MVP?
6. Tasks - Задачи на разработку
Best practices:
- Если изменили подход — обновите соответствующие задачи
- Добавляйте новые задачи, если появились
- Помечайте выполненные задачи как DONE
- Разбивайте сложные задачи
7. Analyze - Проверка согласованности
- AI-аудит всех созданных документов. Как опытный тимлид, который ревьюит ваш проект перед стартом разработки
- Найдёт проблемы, конфликты и несоответствия во всех созданных спецификациях
- Конфликты между требованиями
- Несоответствия между spec и plan
- Технические невозможности
- Упущенные edge cases
- Нереалистичные оценки
- Противоречия в dependencies
Best practices:
- Запускайте analyze минимум 2 раза
- Ошибка: Исправлять проблемы “на глаз”, не обновляя документы: spec/plan/tasks
?. Trace - Трассировка спецификаций, тестов и кода
[ ] TODO trace
extension
/speckit.tracer.trace
/speckit.tracer.verify
/speckit.tracer.expand
requirements.md # REQ-IDs с критериями приемки в стиле EARS
design.md # ADR-IDs, затронутые файлы, архитектурные решения
tasks.md # TASK-IDs, маппинг на одно или несколько REQ-IDs
tests.md # какие файлы/функции тестов ссылаются на какие REQ-IDs
traceability.md # сгенерированная таблица: REQ -> ADR -> TASK -> файлы -> тесты -> PR
tests.md и traceability.md должны быть сгенерированы, а не поддерживаться вручную
8. Implement - Разработка
Best practices:
- Запускать
- по фазам (рекомендуется): /speckit.implement Phase 1
- Конкретные задачи: /speckit.implement T001, T002, T003
- Одна фаза = одна сессия чата. Workflow:
- Новая сессия чата
- /speckit.implement Phase 1
- Ждёте завершения
- Тестируете результат
- Коммитите
- Закрываете сессию (/clear)
- Новая сессия → /speckit.implement Phase 2
9. Converge - Проверить полноту реализации
/speckit-converge