Смол Пенсыл Тиринтила: минимальный CLI для рабочих заметок

11 мая 2026 г. 19K

У Тиринтила был странный критерий для рабочих инструментов: если штуку нельзя объяснить за минуту и починить в обычном терминале, она долго не живёт. Так появился Small Pencil, или по-домашнему смол пенсыл: маленький способ вести заметки, задачи и короткие решения без отдельного сервиса, базы данных и вечной настройки синхронизации.

Идея простая. Каждый день создаётся один markdown-файл, туда падают входящие мысли, ссылки, команды, куски логов и решения по задачам. Вечером файл коммитится в приватный репозиторий. На следующий день можно найти старое решение обычным grep, а не вспоминать, в каком мессенджере или трекере оно осталось.

Такой подход не заменяет нормальную документацию, issue tracker или ADR. Он закрывает другой слой: быстрые рабочие черновики, которые обычно теряются между вкладками браузера и буфером обмена. Ниже схема, которую я использую, когда хочу оставить заметки максимально скучными и надёжными.

Что должен уметь маленький инструмент

Small Pencil не обязан быть приложением. Чем меньше в нём магии, тем дольше он работает. Минимальный набор требований у меня такой:

создать дневной файл, если его ещё нет;
быстро добавить строку из терминала;
открыть файл в редакторе;
найти старую заметку по слову или фразе;
хранить всё в обычных текстовых файлах.

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

Структура каталога

Я обычно держу заметки в одном каталоге внутри домашней директории или рядом с рабочими проектами. Формат даты в имени файла лучше делать ISO-совместимым: тогда сортировка по имени совпадает с сортировкой по времени.

notes/
  2026-05-21.md
  2026-05-22.md
  2026-05-23.md

Внутри дневного файла можно не городить сложную таксономию. Достаточно времени, короткого заголовка и текста. Если запись относится к проекту, я добавляю тег обычным словом: project-api, billing, deploy, postgres. Потом это ищется быстрее, чем вспоминается.

## 10:20 postgres lock на staging

Симптом: миграция висит на ALTER TABLE.
Проверка: pg_stat_activity показал старую транзакцию из воркера.
Решение: остановил воркер, закрыл транзакцию, повторил миграцию.

#postgres #deploy

Минимальный скрипт

Первую версию Small Pencil можно написать как обычный shell-скрипт. Он не красивый, зато понятный. Команда без аргументов открывает дневной файл, команда с текстом добавляет запись в конец.

#!/usr/bin/env bash
set -euo pipefail

DIR='${HOME}/notes'
TODAY=$(date +%F)
FILE=${DIR}/${TODAY}.md

mkdir -p ${DIR}
touch ${FILE}

if [ $# -eq 0 ]; then
  ${EDITOR:-vim} ${FILE}
  exit 0
fi

TIME=$(date +%H:%M)
{
  printf '\n## %s\n\n' ${TIME}
  printf '%s\n' '$*'
} >> ${FILE}

После этого рабочий сценарий становится коротким. Встретил ошибку, проверил гипотезу, нашёл команду, записал одной строкой. Если нужно раскрыть детали, открыл файл и дописал нормальный абзац.

sp 'nginx отдавал старый bundle: забыл purge CDN после релиза #frontend #deploy'
sp

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

Поиск без отдельного приложения

Вся сила текстовых заметок раскрывается через обычные инструменты. Для точного слова хватает ripgrep. Для просмотра контекста можно добавить пару строк вокруг совпадения.

rg -n 'ALTER TABLE|pg_stat_activity|CDN' ~/notes
rg -n -C 2 '#deploy' ~/notes

Когда заметок становится много, полезно договориться с собой о нескольких стабильных тегах. Не нужно размечать каждую строку десятью ярлыками. Достаточно повторяемых слов для основных областей: #postgres, #frontend, #incident, #deploy, #decision. Редкие теги обычно не окупаются, потому что ты сам забываешь, как их называл.

Где граница между заметкой и документацией

Small Pencil хорош как входной буфер. Но если запись начинает повторяться, её пора переносить в место, где её увидит команда: README, runbook, ADR или issue tracker. У меня правило такое: один раз записал в дневник, второй раз нашёл через поиск, третий раз оформил как нормальную документацию.

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

Что добавить позже

Если базовая версия прижилась, можно аккуратно расширять её. Я бы начал с трёх вещей: шаблон дневного файла, команду sync для git commit и push, и отдельную команду find, которая вызывает rg по каталогу заметок. Но каждое расширение должно проходить проверку: без него реально больно или просто хочется сделать инструмент похожим на продукт?

Смол пенсыл Тиринтила держится именно на маленьком размере. Он не пытается стать Notion в терминале, не рисует граф связей и не требует миграций. Это карандаш на краю стола: взял, быстро записал, вернулся к работе. Для инженерных заметок такой скучный инструмент часто оказывается надёжнее красивой системы, которую нужно обслуживать отдельно.

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