В связи с тотальным обновлением.
требования к оформлению переехали Требования оформления документации v6
Здесь оставлены черновики в качестве памятников опыту. Сейчас Не актуальны.
Черновик инструкции: как озадачить ИИ, чтобы он отформатировал документ в удобном виде.
Требования к оформлению сценариев и документации(бета версия).
1). Сформируй документ по правилам:
1.1. Зафиксировать жесткую структуру разделов по смыслу задачи;
1.2. Ограничить длину каждой строки строго в пределах 80-92 символов,
включая пробелы и знаки препинания;
1.3. Убрать из ответа все вводные слова, вежливые извинения,лишний текст.
Исключить двусмысленные слова, например, «сессия»;
1.4. Убрать обилие двоеточий и круглых скобок;
1.5. Оформить весь ответ в виде единого моноширинного блока plaintext;
1.6. Выдать готовый результат для удобного копирования в буфер обмена:
1.7.
1.8.
1.9. Обязательно разделение путей и доменов через переменные в коде или пробел в документе;
1.10. Специфика исполнения алгоритма проверки:
- Шаг с выводом тестовой строки эффективен для калибровки выходного буфера;
- Исключение лишних встречных вопросов экономит контекстное окно и системное время;
- Контроль длины строк исключает сбои отображения текстовых редакторов типа Pluma.
1.11. Демонстрация работы алгоритма, Тестовая проверка длины первой строки:
Ниже приведен фрагмент, состоящий строго из 87 символов, включая пробелы и точки.
Даная тестовая строка создана для точной проверки заданного лимита символов в Pluma.
;
1.12. Таблицам давать осмысленные названия, соотвествуюшие содержанию;
1.13. Лаконичность:
Запрещено дублировать имя команды в описании;
Исключить вводные слова и лишние пояснения;
Использовать прямолинейные термины;
Исключить двусмысленные слова, например, «сессия»;
Прямая связка действия и команды ;
Заменить конкретным содержанием фразы "Лаконичное обьяснение", "Этап задачи", "Отсылка к оглавлению",
"Имя файла-версия.md", "Назначение кратко." ;
2). Пунктуация и условия:
* Данный документ является образцом оформления по расстановке ";" и ":",
меток и комментариев в документации и в коде ;
* Обязательные условия перечислять через запятую и скобки только для необязательных условий;
* Текстовые комментарии к коду и в оглавлении кода сопровождать `##- ` ;
* Текст и комментарии в поясняющем документе и в его оглавлении НЕ сопровождать символами комментария ;
* Для временно ненужного кода вставлять в начало строки один `##- ` без пробела;
3). Редактирование и структура.
Мониторинг,- указывать запуск от root в отдельном окне.
Программы разделять на продолжение прерванного и новый запуск.
Аргументы,- давать ссылку на man, разделяйте путь и домен.
объяснять флаг, например, -B.
Удаление,- строго два шага, проверка через /dev/null и rm.
*При правке одной строки не надо выводить всю простыню.
Покажите где меняете(пункт и или номер строки), задействованные переменные,
изменения БЫЛО и СТАЛО для согласования.
*Все файлы редактировать путём поиска, вставки, замены, без очистки или перезаписи всего файла,
перед изменением файла сделать резервную копию, .
Всегда использовать безопасное редактирование как это делает sudoedit;
*Предпочтение постоянно отдавать case,for,while вместо if и плосской структуре;
*Используйте простые конструкции с cat, grep, awk;
*Структурные части, выполняющие этап или задачу, делать ввиде модулей функций,
чтобы их потом можно было подключить где угодно;
*Забудьте свои привычки постоянно всё переименовывать, терять куски кода или текста;
*100500 правок меня запутают, делайте за один раз и без отклонении от задания;
*После утверждения сценария создать одноимённый файл документации с подробными объяснениями;
100). Оформление Документов, чтобы был не нужен офисный пакет или сторонее ПО:
* Вывод в окно редактора pluma(xed, FeatherPad), на бумагу при помощи принтера.
* Шрифт JetBrains Mono 10-11;
* Поля Слева - 25мм, Справа/Верх/Низ - 9мм;
* Формат txt, Plaintext;
* Лист А4, ориентация книжная;
* Длина каждой строки по символам, включая пробелы и знаки препинания,
должна быть строго в диапазоне 80–92;
* Перенос строк Linux, кодировка UTF-8;
* При наличии таблиц оформлять приложениями в формате csv, разделитель столбцов символ ";".
Такой шрифт выбран причинам компактности для экономии бумаги, лёгкой читаемости и чёткого различия похожих символов.
110). Принципы оформления документов с обьяснениями или скрипта.
110.1). Принципы при создании документации. И обрацы есть далее в теме.
Версию писать сразу после имени через дефис, пример <Имя>-<версия>.md
Оформлять bash, service, timer, config по принципам далее:
1. Заключать код в теги по образцу ниже;
2. На место
```bash
```
писать соответственно service,timer, config;
------------------------------------------
Имя файла-версия. дата yyyy-mm-dd_чч:мм
Назначение кратко.
Ссылка на пункт документации.
Числовая метка.
------------------------------------------
здесь сам текст с пунктами из оглавления или по смыслу содержимого.
```
```plaintext
110.2). Принцип написания кода.
Оглавление по образцу .
Пример кода ниже;
300. Включать данные указания в сам текст не надо.
Отредактировано Avenir.Sirgun (Ср, 30 Сен 2026 16:36:04)