Справочник
Каталог промптов
Каждый промпт, который отправляет инструментарий, о чём он просит и как каждый из них деградирует, когда ответ непригоден.
Каждая точка соприкосновения с LLM во всём инструментарии. Все вызовы, производящие JSON,
выполняются при temperature 0 (для моделей рассуждающего типа этот параметр отбрасывается
автоматически). Китайское повествование (--narrate-lang zh) сохраняет ключи JSON,
значения перечислений, идентификаторы и пути к файлам на английском; меняются только
текстовые значения.
| # | Промпт (модуль) | Фаза | Назначение | Контракт вывода |
|---|---|---|---|---|
| 1 | правила кратких карточек (pipeline/cards.ts) | 2a | назначение простыми словами в 1–2 предложениях + enum роли + подсказка о жизненном цикле для каждого файла в пакете | {"purposes":[{file,purpose,role,lifecycle}]} |
| 2 | правила глубоких карточек (pipeline/cards.ts) | 2a | разбор файла целиком (120–300 слов) + назначение / data_flow / relations по каждой функции с ключом по точному qualname; факты графа объявлены авторитетными | добавляет description, functions[] |
| 3 | запасной путь для чанков (pipeline/cards.ts) | 2a | те же глубокие правила для одного чанка функций слишком большого файла | одна запись purposes, покрывающая чанк |
| 4 | синтез скелета (pipeline/skeleton.ts) | 2b | упорядоченный повествовательный костяк из сводок по директориям + точек входа; порядок жизненного цикла обязателен; сквозные — после основного потока | {"metadata":{archetype},"stages":[{id,title,description,parent,crosscut}]} |
| 5 | назначение файлов (pipeline/assign.ts) | 2b | один основной этап на файл из фиксированного меню; also 0–2; unassigned как аварийный выход для вендоренного/мёртвого кода | {"assignments":[{file,stage,also}]} |
| 6 | актёр-доктор (pipeline/doctor.ts) | 2b | ≤3 структурных изменения (add_stage / remove_stage / merge_stages / split_stage), по приоритету: unassigned → перегрузка → голодание → мёртвое | {"changes":[…],"rationale"} |
| 7 | роли критика (llm/critic.ts) | 2b | ролевой разбор (инженер / архитектор / читатель / редактор) предложения на фоне достоверных свидетельств; APPROVE щедро, REJECT только когда починить нельзя | {"decision","concerns","suggested_revision","rationale"} |
| 8 | промпт правки (llm/critic.ts) | 2b | правка актёра, отвечающая на сведённые пункты [role] concern | та же схема, что у исходного предложения |
| 9 | организация этапа (pipeline/organize.ts) | 2c | 2–8 упорядоченных подгрупп на этап; каждый файл ровно один раз; повествовательный порядок с учётом подсказок вызовов | {"groups":[{title,summary,files}]} |
| 10 | классификация членов (pipeline/member.ts) | 2b (member) | распределить отдельные функции/методы по написанным пользователем этапам | {"assignments":[{member,stage}]} |
| 11 | сводка этапа (pipeline/narrate.ts) | 3 | обзор этапа на 100–200 слов для неспециалиста из обзоров потомков + однострочников по файлам | только обычная проза (без JSON, без заголовков) |
| 12 | сводка системы (pipeline/narrate.ts) | 3 | обзор системы на 200–350 слов, нанизывающий этапы верхнего уровня | только обычная проза |
| 13 | извлечение регистров (pipeline/narrate.ts) | 3, раунд 1 | межэтапные регистры состояния (id + однострочная семантика + затронутые этапы) из обзоров этапов + карточек data_model | {"registers":[{id,semantics,stages}]} |
| 14 | проход по пробелам в регистрах (pipeline/narrate.ts) | 3, раунды 2+ | ТОЛЬКО недостающие регистры при данном списке найденных; пустой массив, когда пусто (цикл останавливается после 2 пустых раундов) | та же схема, только новые записи |
| 15 | системный промпт планировщика (planner/prompt.ts) | plan | маршрутизация по руководству → чтение настоящего исходника → выдача байт-точных EDIT-блоков + JSON деклараций; правила «исполнитель верит вслепую» (уникальность, без пересечений, минимальный охват) | markdown-план, оканчивающийся одним блоком {"will_modify","will_add","will_remove"} |
| 16 | протокол инструментов планировщика (planner/prompt.ts) | plan | одно JSON-действие за ход: list_dir / read_file / grep / finish | блок действия {"tool": …} |
| 17 | метка эволюции resync (studio/server.ts) | studio resync | одно предложение длиной ≤40 символов, называющее, КАКИЕ возможности/модули затронуло изменение, из назначений затронутых файлов; догадываться о намерении запрещено (у resync в Studio нет диффа); без клиента откатывается к детерминированному списку файлов | обычная проза, одна строка (рендерится приглушённо + с меткой auto) |
Правила проектирования, общие для всех промптов
- Факты вкладываются, а не запрашиваются. Перечни функций, диапазоны строк и отношения вызовов приходят из графа и помечены как достоверная основа; модель пишет прозу вокруг них, и ей сказано не перечислять их заново.
- Меню закрытые. Промпты назначения и классификации перечисляют допустимые
идентификаторы этапов и предписывают «никогда не выдумывать»; всё, что вне меню, при
разборе приводится к
unassigned, поэтому дрейф промпта не может испортить артефакты. - У каждого JSON-контракта есть механический валидатор на принимающей стороне (zod или проверки, написанные вручную); отброшенные или испорченные записи детерминированно дозаполняются и учитываются в артефактах покрытия, а не латаются молча.
- Окончания «только JSON» / «только проза» сохраняют однозначность разбора; извлекатель JSON терпит блоки в тройных кавычках и сканирование по сбалансированным скобкам, но промпты всё равно просят один блок в тройных кавычках.
- Промпты критика сопротивляются штамповке в обе стороны: одобряют достаточно правильные предложения (никаких пустых REVISE — такие нормализуются в APPROVE), но сорвавшийся вызов критика считается REJECT, поэтому инфраструктурные сбои никогда не одобряют изменения.