EugineKosenko/majordom

create-project

Навичка для створення нового проєкту у стандартній структурі користувача. Усе робиться за глобальними правилами з ~/.claude/rules/ (насамперед project-meta.md, spcfctn-code.md, org-babel.md, file-editing.md); тут лише порядок дій.

Явний виклик цієї навички є дозволом створити spcfctn/ (глобальне правило «попроси користувача створити spcfctn/» тут не діє — користувач уже попросив).

Крок 0 — підготовка

• Корінь проєкту — поточний робочий каталог (чи каталог, який назвав користувач). Подивись, що вже там є: ls -la, find -L (symlink-и враховуємо).
• Якщо .claude-root, .claude/CLAUDE.md тощо вже існують — це не новий проєкт: нічого не перезаписуй, лише доповнюй відсутнє й повідом, що було наявним.
• Якщо spcfctn/ уже є частиною спільного репозиторію (монорепо) — нічого не розбивай. У звіті скажи про це й запропонуй розбивку по підкаталогах зі збереженням історії при найближчому коміті (spcfctn-code.md).
• Перед кожним запитом дозволу давай коротке резюме українською (file-editing.md).

Крок 1 — мова проєкту

• Якщо користувач не назвав мову в запиті — запитай через AskUserQuestion («Якою мовою вести проєкт?»: українська, англійська, інше). Не пиши жодного прозового тексту, поки мови не знаєш.
• Мова проєкту стосується файлів репозиторію (код, коментарі, коміти, org/md) і зовнішніх артефактів проєкту (задачі Jira, сторінки Confluence). Мова чату з користувачем — окрема, завжди українська.

Крок 1а — код проєкту

Кожен проєкт має власний короткий код з двох літер. Три літери — лише в крайньому разі, коли прийнятних дволітерних варіантів немає. Регістр не фіксований: він залежить від контексту вживання (напр. ключ задачі Jira — великими, KB-1676; префікс у коді чи назві — за конвенцією місця, зазвичай малими). Тому в пропозиціях показуй код без прив'язки до регістру, а в CLAUDE.md записуй у формі основного вжитку й зазначай, де яка форма застосовується.

• Не вигадуй код мовчки й не бери перший-ліпший: явно запропонуй 3–4 цікаві варіанти, які тобі самому подобаються (від назви проєкту, його суті чи гри слів — з коротким поясненням, чому саме цей), і дай користувачу вибрати один із них або назвати свій. Зручно зробити це через AskUserQuestion (перший варіант — найкращий за твоєю оцінкою, з позначкою «(Recommended)»; «Other» додається автоматично для власного коду користувача).
• Перевір, що обраний код не збігається з кодами наявних проєктів користувача (пошук у ~/.claude/projects/*/memory, .claude/CLAUDE.md сусідніх проєктів, за потреби locate), а якщо збігається — скажи про це й запропонуй інші.
• Код запиши в .claude/CLAUDE.md (крок 3) і згадай у фінальному звіті.

Крок 2 — структура

Створи в корені:

Що	Вміст
.claude-root	порожній файл (позначає корінь спільного робочого каталогу)
.dir-locals.el	форма нижче, обов'язково з кінцевим переносом рядка
code/	порожній каталог (сюди підуть під-репозиторії/код)
spcfctn/code/	каталог, якщо ще нема (spcfctn/ створюй сам, див. вище), і в ньому окремий git init (рутинна дія, дозволу питати не треба) та .gitignore з єдиним рядком *~; коміт не роби, доки користувач не попросить. Сам spcfctn/ не репозиторій
.mcp.json	порожній: {"mcpServers": {}} (project-meta.md — лише project-scope MCP, ніколи user-scope)
env.org	літературне джерело .env.example — див. нижче
.claude/	див. крок 3

env.org — по розділу на кожен MCP-сервер проєкту (* Назва MCP), що описує прозою, які змінні йому потрібні й навіщо; кожен розділ тангліться (:noweb-ref) у спільний .env.example (публічний, показує лише ІМЕНА змінних із заглушками, без реальних значень — org-babel.md, шаблон "мультитаргет" тут не потрібен, ціль одна). Реальний .env (з правами 600, project-meta.md) користувач заводить сам — не створюй і не редагуй його; .gitignore для нього в корені проєкту не потрібен, бо корінь ніколи не git-репозиторій (project-meta.md). Якщо на момент створення проєкту MCP-серверів ще нема — env.org можна лишити з одним реченням-заготовкою ("Поки жодного MCP не підключено") замість розділів, і повернутись, коли з'явиться перший сервер.

.dir-locals.el (абревіатура root: для org-посилань, портативно, без хардкоджених шляхів):

#+begin_example ((org-mode . ((eval . (add-to-list 'org-link-abbrev-alist (cons "root" (locate-dominating-file default-directory ".dir-locals.el"))))))) #+end_example

(У самому файлі це чистий elisp — рядки #+begin_example/#+end_example туди не потрапляють.)

Якщо spcfctn/ui/ знадобиться (аналіз макетів) — його створюють пізніше, за потреби; порожні каталоги наперед не плоди. Кожен підкаталог spcfctn/, що з'являється потім (ui/, deploy/ тощо), одразу отримує власний git init і .gitignore з *~ — сам spcfctn/ не є репозиторієм. Каталоги draft/, raw/, data/ не створюй, доки в них немає що класти, і не додавай їхні патерни в .gitignore наперед (project-meta.md).

Крок 3 — .claude/

1. mkdir .claude і окремий git init саме в .claude/ (навіть якщо корінь сам git-репозиторій чи лежить усередині чужого). Це рутинна дія, дозволу питати не треба. Коміт не роби, доки користувач не попросить.

2. .claude/.gitignore:

   #+begin_example settings.local.json *~ #+end_example

   (*~ — узагальнений патерн backup-файлів Emacs, включно з *.~undo-tree~; кінцевий перенос рядка.)

3. .claude/CLAUDE.md — мовою проєкту. Мінімум:

   • розділ про мову: уся проза проєкту (документація, коментарі коду, повідомлення комітів, заголовки org тощо) — мовою проєкту; сюди ж артефакти Jira/Confluence; чат із користувачем лишається українською;
   • код проєкту (крок 1а) — окремим рядком, напр. «Код проєкту: kb (у ключах задач Jira — KB)»;
   • короткий опис структури: .claude-root позначає корінь; code/ — код; spcfctn/code/ — документація існуючої практики коду (власний git); .claude/ — наміри й конвенції проєкту (власний git).

   Додатково (Jira-ключ, assignee тощо) нічого не вигадуй — це з'явиться за ходом роботи.

4. Нічого не пиши в settings.local.json — це особисте й поза git.

Крок 4 — корінь не в git

Корінь проєкту ніколи не є git-репозиторієм (project-meta.md): не роби git init у корені й не створюй кореневий .gitignore. Якщо в корені вже є .git — не чіпай і повідом користувача у звіті. Якщо є кореневий .mcp.json — нічого з ним не роби.

Крок 5 — переклад уже наявних файлів

Усе, що було в проєкті до створення (крім *~-файлів, .git, бінарників і самих щойно створених службових файлів), приведи до мови проєкту, якщо вони написані іншою:

• Текст пиши повним перекладом, зберігаючи структуру, таблиці, код-блоки, ідентифікатори й цитати (повідомлення про помилки лишай в оригіналі).
• Українська: «перелік», а не «список» (для list); «зачіпка» для hook; ідентифікатори й CSS-класи не перекладай (org-babel.md).
• .md править лише агент; .org — незрозумілі правки користувача не видаляй, а питай. Для org-файлів із :tangle правь org-джерело й тангли через emacsclient (org-babel.md).
• Після редагування абзаців (проза, не код-блоки й не таблиці) вирівняй переноси реальним fill-paragraph через emacsclient --eval (для org — спершу (font-lock-ensure)); абзац у new_string/Write пиши одним рядком. Якщо emacsclient не підключається — попроси користувача запустити сервер, не імітуй.
• Для org/md-прози після цього запусти навичку org-lint.
• Якщо частина змісту посилається на файли/проєкти, яких тут немає, — не «виправляй» посилання, лише переклади текст навколо.

Крок 6 — звіт

Коротко перелічи, який код проєкту обрано, що створено, що вже було, що перекладено, і нагадай: коміти в .claude/ і в підкаталогах spcfctn/ не зроблено (роблять на прохання).

Чого не робити

• Не редагуй .env/.env.* (project-meta.md) і не створюй .mcp.json із секретами.
• Не пиши нічого у файли CLAUDE.md/.claude/ під-репозиторіїв компонентів у code/* — лише в кореневий .claude/.
• Не вигадуй мовних правил за користувача — лише запитана мова.
• Не призначай код проєкту сам без пропозиції варіантів і вибору користувача.
• Не роби git init у корені проєкту й у корені spcfctn/: репозиторії лише в .claude/, у code/* і в підкаталогах spcfctn/*.