# Сборка нативных промптов

Это механика после выбора приёма в [основной оптике](../SKILL.md). Смысл
ревью и триажа задаёт [единый договор](review-and-triage.md); здесь только
параметры, файловые пути и сборка.

Постоянный текст живёт в [prompts/](prompts/):

- [result-contract.md](prompts/result-contract.md) — обычный результат;
- [review-boilerplate.md](prompts/review-boilerplate.md) — независимое ревью;
- [triage-header.md](prompts/triage-header.md) — закрытие находок;
- [recheck-header.md](prompts/recheck-header.md) — узкая перепроверка;
- [runtime-language.md](prompts/runtime-language.md) — язык временного обмена.

Меняй договор только в его авторитетном файле. В параметрических файлах держи
только факты конкретной задачи.

## Каталог прогона

`$SCRATCH` определён в основном файле как общий временный каталог. Для задачи
создай в нём уникальную подпапку, далее `D`. `P` обозначает каталог
`references/prompts` этого скилла. Каждый агент получает отдельный `REPORT`.

Собирай файлы механически, не читая полезную нагрузку в контекст координатора.
В схемах ниже `A + B -> C` означает текстовое объединение файлов в заданном
порядке нативным средством текущей ОС; `[A]` означает необязательный файл.
Схема не предписывает оболочку, синтаксис пути или отдельный этап процесса.

## Исполнитель или исследователь

`params.md`:

```text
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
```

```text
D/params.md
+ P/result-contract.md
+ P/runtime-language.md
-> D/prompt.md
```

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

## Ревью постановки или реализации

`review-common.md` одинаков для одного обзора:

```text
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` задаёт поля конкретной линии:

```text
TYPE: spec | task | code
FINDING PREFIX: SPEC-A | SPEC-B | TASK | CODE
REPORT: absolute unique path
```

`review-focus.md` задаёт один выбранный фокус. Для постановки:

```text
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 из договора ревью:

```text
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.
```

```text
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` добавляй только для совпадений, противоречий и новых
решений уровня задачи.

```text
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`.

```text
P/recheck-header.md
+ D/recheck-params.md
+ P/runtime-language.md
-> D/recheck-prompt.md
```

Перепроверка следует решению координатора по договору ревью, а не номеру этапа.