diff --git a/labs/screenshots/another-screenshot.png b/labs/screenshots/another-screenshot.png
new file mode 100644
index 00000000..68500bbc
Binary files /dev/null and b/labs/screenshots/another-screenshot.png differ
diff --git a/labs/screenshots/pr-template.png b/labs/screenshots/pr-template.png
new file mode 100644
index 00000000..97a3e871
Binary files /dev/null and b/labs/screenshots/pr-template.png differ
diff --git a/labs/screenshots/verified-commit.png b/labs/screenshots/verified-commit.png
new file mode 100644
index 00000000..3f7af465
Binary files /dev/null and b/labs/screenshots/verified-commit.png differ
diff --git a/labs/submission1.md b/labs/submission1.md
new file mode 100644
index 00000000..8ea5c328
--- /dev/null
+++ b/labs/submission1.md
@@ -0,0 +1,56 @@
+## Task 1 — SSH Commit Signature Verification
+
+### 1. Краткое объяснение преимуществ подписания коммитов
+Так как у многих есть доступ к репозиторию - подписание коммитов позволяет подтвердить подлинность автора изменений и гарантировать целостность данных. Это означает, что коммит действительно был создан конкретным разработчиком и не был изменён после публикации. Что повышает уровень безопасности и доверия при работе с репозиторием.
+
+### 2. Доказательство успешной настройки SSH-ключа и подписанного коммита
+1. SSH-ключ был успешно создан и добавлен в GitHub. 
+2. Git настроен для использования SSH-подписи коммитов. 
+3. Коммит был создан с использованием SSH-подписи и успешно отправлен в удалённый репозиторий.
+
+
+### 3. Почему подписание коммитов важно в DevOps-процессах?
+Над проектом одновременно работают многие разработчики и автоматизированные системы. Подпись коммитов обеспечивает прозрачность, ответственность и безопасность, позволяя однозначно определить автора каждого изменения. Это снижает риск внедрения несанкционированных или вредоносных изменений и упрощает создание нужного кода.
+
+### 4. Подтверждение (verification) подписи коммита на GitHub
+Коммит отображается на GitHub с пометкой **Verified**, что подтверждает успешную подпись коммита и корректную настройку SSH-ключа. Данная пометка видна в истории коммитов и в Pull Request.
+
+
+
+## Task 2 
+
+### Настройка PR-шаблона
+
+Для стандартизации pull request’ов был создан шаблон по пути:
+
+.github/pull_request_template.md
+
+Шаблон содержит следующие разделы:
+- Goal — цель изменений  
+- Changes — описание внесённых изменений  
+- Testing — информация о тестировании  
+- Checklist — чеклист для самопроверки перед отправкой pull request’а  
+
+Файл был добавлен в ветку **main**, так как GitHub применяет PR-шаблоны только из основной ветки репозитория.
+
+### Проверка автозаполнения PR-шаблона
+
+На скриншоте ниже показано, что при создании pull request’а из ветки 'feature/lab1' в ветку 'main'
+описание PR автоматически заполняется содержимым шаблона
+
+![Автозаполнение PR-шаблона](screenshots/pr-template.png)
+
+
+### Как PR-шаблоны улучшают совместную работу
+
+PR-шаблоны улучшают командную работу и DevOps-процессы по следующим причинам:
+- все участники команды предоставляют одинаково структурированную информацию
+- процесс code review становится быстрее и понятнее
+- уменьшается вероятность пропуска важных шагов, таких как тестирование или обновление документации
+
+
+Что повышает качество кода и делает процесс разработки более прозрачным и предсказуемым
+
+### Возникшие сложности
+
+Возникли не большие сложности из-за того что новые PR создавались без шаблона, пришлось заново пересоздавать ветку 'feature/lab1' и все сработало
\ No newline at end of file