Технический писатель, направления для развития

Угу.
А можно просто в Confluence написать все требования, проставив ссылки на корпоративный глоссарий, на связанные задачи в Jira, на описание процесса приемки, тестирования и прочие особенности.

Confluence это или иная вики-система не важно, главное, что над текстом может работать несколько участников, видно кто что внес или изменил, прикрепляются макеты и файлы в разных форматах, архивы и т.п. Например, таблица из Excel, сертификат для сервера, архив с картинками, набор необходимых библиотек, которые недоступны никому и прочее. В итоге вся достоверная информация есть в ТЗ и оно доступно всем, кому надо одновременно из разных мест планеты с любого устройства с инетом..  
К нему всегда удобно обратиться программисту и отметить ход работ, что он выполнил (тут же заказчик может контролировать ход работ), тестировщику, писателю и прочим участникам. Есть целый системы планирования, постановки задач, управления проектами. технические задания ставятся там.

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

Он может это делать если его попросят или если это его обязанность.  
Могу привести пример с DITA, просто пример. Есть компания в которой используют диту. Она настроена, стили есть, все хорошо. Есть группа писателей. Им сказано описывать некую систему. Сказано примерно так: Открыл редактор XML - написал абзац - вставил картинку - сохранил, написал абзац - вставил картинку - сохранил.  Писатель пишет, о стилях и стандартах не думает. Картинки принимают размер как надо, стили сами применяются, как выглядит конечный документ - они могут и не знать   .  

Другой писатель в другой компании пишет текст на сайте с движком Битрикс или WordPress, загружает картинки. Также ни о каких стилях и стандартах он не думает. Часть текста попадает в релиз, в описание изменений, остальное в подсказки, страницы помощи и т.п.  

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

Эта деятельность входит в компетенцию аналитика.

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

А ТЗ и пишет аналитик, а не технический писатель.

Вероятное развитие событий:

Все всё выполнили, но заказчик недоволен. Ему не нужен КЛАДР, а нужно чтобы в систему был забит его список адресов с пояснениями "пройти 10 метров от угла дома, свернуть в подворотню, постучать в дверь с красной вывеской 3 раза". Сейчас этот список написан нечитаемым подчерком в нескольких бумажных тетрадях. Те деньги, за которые компания готова за это взяться, заказчик платить не готов. Получили по половине человекодня программиста, тестировщика и техписателя, потраченных впустую, и недовольного заказчика. Этого можно было бы избежать, если бы аналитик не поленился перевести устное пожелание заказчика "хочу выбирать из списка" в требование "У пользователя должна быть возможность выбрать адрес из справочника КЛАДР" и отправить его на утверждение заказчику.  
На самом деле всё зависит от масштаба задач. Пожелание адекватного заказчика, которое может быть реализовано за полчаса, можно выполнить и без бюрократической волокиты. Но это именно выполнение мелкого пожелания, а не "разработка ТЗ без создания печатного или электронного документа".

Думаю, очевидно: недостаточно владеть инструментарием. Да и овладеть им не так сложно. HTML5 и CSS3 не те вещи, которыми имеет смысл хвалиться, т.к. в них чего-то мегасложного нет. Любой может научиться за месяц.

Коллеги! Напоминаю тему: Какие направления для развития технического писателя вы знаете!  

Для написания может и нет, а для сдачи онлайн-документации заказчику очень может быть что да.

Заказчик говорит, что онлайн-документация ему в принципе нравится, но эта кнопочка должна быть с закругленными углами, этот ярлычок вкладки другой высоты, промежуток между панелями должен быть узкий, должны быть такие-то кнопки, которые то-то делают, и т. д. Будете отвечать, что ничего этого делать не умеете?

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

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