Dmitriy Dementiev
02a98df8c3
- Зачем: - ревью высокоуровневых документов могло требовать преждевременных деталей и постоянно блокировать одобрение. - Что: - находки ограничены дефектами на уровне самого документа. - существенные отложенные риски отделены от блокирующих замечаний. - уточнено, что APPROVED допускает открытые вопросы будущей реализации. - Проверка: - quick_validate.py, git diff --check и проверка локальных Markdown-путей.
7.2 KiB
Сборка нативных промптов
Это механика после выбора приёма в основной оптике. Смысл ревью и триажа задаёт единый договор; здесь только параметры, файловые пути и сборка.
Постоянный текст живёт в prompts/:
- result-contract.md — обычный результат;
- review-boilerplate.md — независимое ревью;
- triage-header.md — закрытие находок;
- recheck-header.md — узкая перепроверка;
- runtime-language.md — язык временного обмена.
Меняй договор только в его авторитетном файле. В параметрических файлах держи только факты конкретной задачи.
Каталог прогона
$SCRATCH определён в основном файле как общий временный каталог. Для задачи
создай в нём уникальную подпапку, далее D. P обозначает каталог
references/prompts этого скилла. Каждый агент получает отдельный REPORT.
Собирай файлы механически, не читая полезную нагрузку в контекст координатора.
В схемах ниже A + B -> C означает текстовое объединение файлов в заданном
порядке нативным средством текущей ОС; [A] означает необязательный файл.
Схема не предписывает оболочку, синтаксис пути или отдельный этап процесса.
Исполнитель или исследователь
params.md:
GOAL: one verifiable goal
BOUNDARIES: allowed and forbidden work
READ FIRST: paths to contracts and examples
CHECKS: commands this agent should run
REPORT: absolute unique path
D/params.md
+ P/result-contract.md
+ P/runtime-language.md
-> D/prompt.md
Самодостаточную постановку и подробное обязательное чтение добавляй только когда они нужны выбранной работе.
Ревью постановки или реализации
review-common.md одинаков для одного обзора:
TITLE: short review title
WORKING DIRECTORY: absolute repo path
STATEMENT: task and parent spec paths
REVIEW INPUT: task sections, exact paths, a prepared diff path, or a diff command
OUT OF SCOPE: what is explicitly outside this review
CHECKS: commands and expected counters
REVIEW INPUT должен позволять отличить проверяемую работу от посторонних
изменений. Выбери достаточную форму для текущего дерева; диапазон коммитов не
обязателен, если точные пути, разделы или подготовленный diff уже задают границу.
review-output.md задаёт поля конкретной линии:
TYPE: spec | task | code
FINDING PREFIX: SPEC-A | SPEC-B | TASK | CODE
REPORT: absolute unique path
review-focus.md задаёт один выбранный фокус. Для постановки:
Review the statement or plan at its own level of abstraction, not as an
implementation. Check facts against code, hidden one-line decisions,
boundaries, checkable acceptance criteria, and ways to satisfy the wording
without the intended result.
A high-level document is not incomplete merely because implementation choices
remain open. Request changes only for a defect the document itself must
resolve: one that changes its goal, boundaries, architectural direction,
acceptance criteria, dependencies, or the ability to decompose work safely.
When a detail can be decided locally by a downstream owner without changing
those properties, do not make it a finding or prescribe the implementation.
If deferring it carries a relevant risk, record that risk as a non-gating
consideration.
APPROVED means that no defect at the document's own level requires revision.
It does not mean that all downstream questions have been answered.
Для реализации выбери task lens или code lens из договора ревью:
TASK LENS: compare the implementation with the statement, acceptance criteria,
boundaries, and intended observable result.
CODE LENS: seek correctness bugs, broken invariants, regressions, security
issues, and tests that can pass without proving the behavior.
D/review-common.md
+ D/review-focus.md
+ D/review-output.md
+ P/review-boilerplate.md
+ P/runtime-language.md
-> D/review-prompt.md
Для двух слепых линий создай review-focus-a.md и review-focus-b.md,
review-output-a.md и review-output-b.md со своими TYPE, уникальными
FINDING PREFIX и разными путями REPORT. review-common.md используй один;
отчёты и финальные сообщения линий не объединяй до их завершения.
Триаж постановки
Координатор читает краткие строки и нужные подробности, принимает решение по
каждому SPEC-* и обновляет постановку. Резолюции сохраняет в
spec-resolutions.md; этот файл и новая постановка идут исходному ревьюеру
на узкую перепроверку.
Триаж реализации
Передай исполнителю актуальные подробные отчёты без пересказа: исходные обзоры
в первом круге, отчёты перепроверки для оставшихся и новых находок в следующих.
triage-params.md содержит путь итогового отчёта и проверки.
coordinator-notes.md добавляй только для совпадений, противоречий и новых
решений уровня задачи.
P/triage-header.md
+ D/triage-params.md
+ <current detailed report 1>
+ [<current detailed report 2>]
+ [D/coordinator-notes.md]
+ P/runtime-language.md
-> D/fix-prompt.md
Узкая перепроверка
Продолжай исходный тред ревьюера. recheck-params.md задаёт пути к его
исходному отчёту и файлу резолюций, нужную проверку и новый уникальный
REPORT.
P/recheck-header.md
+ D/recheck-params.md
+ P/runtime-language.md
-> D/recheck-prompt.md
Перепроверка следует решению координатора по договору ревью, а не номеру этапа.