Ihor Gevorkyan

Да, но, если говорить о терминологии, то PSD to HTML - будет наиболее подходящим термином, чтобы это понял англоязычный мир.

С натяжкой, но, также, можно назвать эту специализацию HTML coder, но, на самом деле, в мире нет разделения четкого, как в странах СНГ, на Front End develop и HTML coder

вполне, просто у gulp для нотификации установлен какой-то notifier, который просто выводит сообщения.
По npm start вы, вероятнее всего, запускаете задачи, которые описаны, именно, в gulpfile.js. Короче, с вероятностью 99% - так и должно быть, это, наоборот, сделано для лучшего понимания в процессе работы.

Не сказать, что было бы, прям, проблематично, но это, совершенно, другая экспертиза.

Для переключения в другую экспертизу, опытным разработчикам, по моему опыту, к нормальному качеству работы, потребуется, минимум, 3 месяца.

Пару советов, которые могут быть полезны:
- если ребята, по ходу, будут предлагать более прямые решения, то подходите к этому очень внимательно и, желательно, идите на встречу, если это решение будет решать ту же логику

- если есть возможность подключить, хотя бы удаленно, одного специалиста с экспертизой в game dev-е, который будет помогать советами и вам, и ребятам, то это значительно упростит вашу и разработчиков жизнь. Он нужен, в большей степени, как консультант, у него уже должны быть "протоптанные дорожки". Идеальный вариант - если он сможет тим-лидить

- разделите весь объем работ на маленькие части и разрабатывайте от общих к частным

- в процессе выполнения задач "урезайте углы" и первичной целью ставьте MVP. После этого, все эти углы, можно уже "вылизывать". Если у вас нет, даже, MVP, то у вас нет ничего, будет MVP - будет от чего отталкиваться и делать следующие шаги

1. Если ты обычный пользователь, то поставь себе какой-то RSS feed клиент. Если ты про программирование, то - да, делать запрос, парсить результат.
   
2. Про подписку - скинь скрин. Может то обычная подписка на рассылку email?
   

возможно. Slim - это микрофрэймворк, популярные соц. сети, вообще, когда-то, без фрэймворков писали :)

Если "свои файлы" у всех сайтов одинаковые - git submodules. Если разница большая - то разделяйте ветками, где все наследуются от мастера с общими исходниками, но каждая имеет какую-то особенность. Общие изменения вносите в мастере и разливаете по веткам, вручную или автоматически через git hooks, например.

Не знаю об особенностях работы с azure, но обычно, по флоу:
1. В репо лежит config.sample.js с тестовыми (не реальными credentials)
2. Сервис, который забирает исходники из репозитория и делает билд на сервере, должен иметь возможность запускать кастомные скрипты (вероятно, shell-скрипты), внутри скрипта прописано, что:
- файл (перед запуском процесса билда (какой-то pre-build, вероятно)), переименовывается в config.js
- чтение файла из скрипта, замена тестовых credentials на реальные, с помощью поиска по регулярным выражениям
- сервис делает билд, уже с готовым файлом конфигурации

И еще:
Не знаю, что у тебя в файле config.js, но для credentials лучше использовать env