bro-give-me-spec

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Bro Give Me Spec

生成结果规范

Твоя задача — создать спецификацию результата: зафиксировать, что и зачем должно измениться и как подтвердить готовность, не определяя способ реализации. НЕ ПИШИ код и НЕ СОСТАВЛЯЙ шаги реализации.

你的任务是创建结果规范：明确需要改变什么以及为什么改变，并确认如何验证完成状态，但不定义实现方式。 请勿编写代码，也请勿制定实现步骤。

ОБЩИЕ ПРАВИЛА

通用规则

ОБЯЗАТЕЛЬНО соблюдай правила диалога!
ОБЯЗАТЕЛЬНО соблюдай и НЕ нарушай порядок работы!
Спецификация ДОЛЖНА быть однозначной, без вариаций и открытых вопросов. Продуктовые неоднозначности НУЖНО решить с человеком.
При создании спецификации ОБЯЗАТЕЛЬНО соблюдай шаблон.
Критерии приемки ДОЛЖНЫ покрывать желаемый результат и содержать способ подтверждения.
Автоматизированные тесты и проверки ДОЛЖНЫ подтверждать изменяемое поведение, когда это разумно для проекта. Спецификация не задаёт порядок написания тестов и реализации и не требует TDD.
После записи
```
spec.md
```
ОБЯЗАТЕЛЬНО проведи ревью спецификации, если человек явно не попросил обойтись без ревью.

必须遵守对话规则！
必须遵守且不得违反工作流程！
规范必须明确无误，无歧义及未解决问题。产品相关的歧义必须与用户沟通解决。
创建规范时必须遵循模板。
验收标准必须覆盖预期结果，并包含验证方式。
在项目合理范围内，自动化测试与校验必须验证变更后的行为。规范不规定测试编写与实现的顺序，也不要求TDD（测试驱动开发）。
生成
```
spec.md
```
后必须进行规范评审，除非用户明确要求跳过评审。

ОГРАНИЧЕНИЯ / STOP

限制/禁止事项

ЗАПРЕЩЕНО добавлять в спецификацию шаги, этапы, задачи исполнителя, пути к файлам, выбранную архитектуру, код, diff, патчи или псевдокод.
ЗАПРЕЩЕНО добавлять разделы сверх структуры шаблона. Раздел
```
Принятые решения
```
допустим только при наличии зафиксированных договорённостей.
ЗАПРЕЩЕНО придумывать факты или критерии. Неоднозначность результата, рамок или приемки ДОЛЖНА быть решена до готовности спецификации; при такой неоднозначности на этапе ревью вердикт
```
BLOCKED
```
и вопрос человеку.
ЗАПРЕЩЕНО записывать
```
spec.md
```
до подтверждения пути человеком. Если файл уже существует — ЗАПРЕЩЕНО обновлять его без явного одобрения на обновление.
ЗАПРЕЩЕНО пропускать ревью, кроме явной просьбы человека в текущем запуске.
ЗАПРЕЩЕНО передавать субагенту-ревьюеру ссылки на внутренние файлы скилла вместо полного текста промпта и контекста в
```
Task
```
.

禁止在规范中添加步骤、阶段、执行者任务、文件路径、选定架构、代码、diff、补丁或伪代码。
禁止添加超出模板结构的章节。
```
已接受的决策
```
章节仅在存在已确认的协议时允许添加。
禁止编造事实或标准。结果、范围或验收标准的歧义必须在规范完成前解决；若评审阶段出现此类歧义，判定为
```
BLOCKED
```
（受阻）并向用户询问。
禁止在未获得用户确认路径前生成
```
spec.md
```
。若文件已存在，禁止在未获得明确更新许可的情况下修改它。
禁止跳过评审，除非用户在当前任务中明确要求。
禁止向评审子Agent传递技能内部文件的链接，替代方案是在
```
Task
```
中传递完整的提示文本和上下文。

ПОРЯДОК РАБОТЫ

工作流程

ПРОЧИТАЙ шаблон спецификации.
СОБЕРИ из кода и контекста сведения, необходимые для однозначного описания текущего состояния, желаемого результата, рамок и проверок.
ЗАПРОСИ недостающую информацию у человека. ОБЯЗАТЕЛЬНО соблюдай правила диалога. Закрытые развилки при необходимости готовь для раздела
```
Принятые решения
```
.
ПРОВЕРЬ, что каждый изменяемый сценарий из желаемого результата покрыт критерием приемки, а для каждого критерия указан подходящий способ подтверждения.
ПРОВЕРЬ наличие memory bank и выбери путь артефакта по правилам размещения. ПОДТВЕРДИ путь у человека (и одобрение на обновление, если файл уже есть).
СОЗДАЙ или ОБНОВИ
```
spec.md
```
по шаблону и согласованному пути. Не жди отдельного апрува содержания перед записью.
Если человек явно не просил пропустить ревью — ВЫПОЛНИ цикл по правилам ревью: выбери тиры по subagent-model-tiers, запусти общего ревьюера с полным текстом spec-reviewer-prompt и при необходимости узкого critical-ревьюера с spec-critical-reviewer-prompt, обработай итоговый
```
PASS
```
/
```
NEEDS_WORK
```
/
```
BLOCKED
```
.
После завершения ревью (или после явного пропуска) СООБЩИ итог в чате. Отдельный апрув содержания не запрашивай: актуальный файл уже на диске.
Предложи
```
/bro-do-it
```
только при
```
PASS
```
ревью или при явном пропуске ревью по просьбе человека.

阅读规范模板。
从代码和上下文中收集明确描述当前状态、预期结果、范围和验证所需的信息。
向用户请求缺失的信息。必须遵守对话规则。必要时为
```
已接受的决策
```
章节准备已确定的分支方案。
检查预期结果中的每个变更场景是否都有对应的验收标准覆盖，且每个标准都指定了合适的验证方式。
检查memory bank的存在，并根据存储规则选择工件路径。向用户确认路径（若文件已存在，还需确认更新许可）。
按照模板和已确认的路径创建或更新
```
spec.md
```
。无需等待单独的内容批准即可生成。
若用户未明确要求跳过评审——按照评审规则执行评审流程：根据子Agent模型层级选择层级，使用完整的规范评审提示文本启动通用评审Agent，必要时使用规范关键评审提示启动专项关键评审Agent，处理最终的
```
PASS
```
（通过）/
```
NEEDS_WORK
```
（需要修改）/
```
BLOCKED
```
（受阻）结果。
评审完成后（或明确跳过评审后）在聊天中告知结果。无需单独请求内容批准：最新文件已存储在磁盘上。
仅在评审
```
PASS
```
或用户明确要求跳过评审时，才推荐使用
```
/bro-do-it
```
指令。

Артефакт spec.md

工件spec.md

spec.md

ДОЛЖЕН содержать обязательные разделы:

```
Контекст и задача
```

Зачем делается правка

Желаемый итоговый результат

```
Критерии приемки
```
```
Рамки задачи
```

Раздел

Принятые решения

МОЖЕТ присутствовать только если есть зафиксированные договорённости: ответы человека на развилки и существенные уточнения смысла после ревью. Иначе раздел НЕ создавай.

Раздел

Критерии приемки

ДОЛЖЕН:

использовать идентификаторы
```
AC-N
```
;
содержать только наблюдаемые и проверяемые условия завершения;
покрывать все изменяемые сценарии и существенные инварианты из желаемого результата;
указывать для каждого критерия автоматизированный тест или проверку, а при неразумности автоматизации — конкретное ручное свидетельство;
не требовать TDD и не задавать последовательность реализации.

Раздел

Рамки задачи

ДОЛЖЕН быть разделён только на подразделы:

```
Входит
```
```
Не входит
```

spec.md

必须包含以下必填章节：

```
任务背景与目标
```
```
修改原因
```
```
预期最终结果
```
```
验收标准
```
```
任务范围
```

已接受的决策

章节仅可在存在已确认协议时添加：即用户对分支方案的答复，以及评审后对核心内容的重大澄清。否则请勿创建该章节。

验收标准

章节必须：

使用
```
AC-N
```
格式的标识符；
仅包含可观察、可验证的完成条件；
覆盖预期结果中的所有变更场景及核心不变项；
为每个标准指定自动化测试或校验方式，若自动化不合理则指定具体的人工验证依据；
不要求TDD，也不规定实现顺序。

任务范围

章节必须仅分为以下子章节：

```
包含内容
```
```
排除内容
```

Субагенты

子Agent

Для ревью спецификации используй:

общий ревьюер — spec-reviewer-prompt на тире
```
middle
```
или
```
senior
```
;
узкий critical-ревьюер — spec-critical-reviewer-prompt на тире
```
critical
```
, только если затронута безопасность.

Тиры и семейства моделей выбери до запуска по spec-review и subagent-model-tiers. В

Task

передай полный текст промпта с подставленным путём к

spec.md

и контекстом запуска; не ссылайся на файлы скилла внутри промпта субагента.

规范评审需使用以下子Agent：

通用评审Agent——使用spec-reviewer-prompt，层级为
```
middle
```
或
```
senior
```
；
专项关键评审Agent——仅在涉及安全问题时使用spec-critical-reviewer-prompt，层级为
```
critical
```
。

需在启动前根据规范评审和子Agent模型层级选择层级及模型系列。在

Task

中传递完整的提示文本，需替换为

spec.md

的路径并包含启动上下文；请勿在子Agent的提示中引用技能内部文件。

Quality Control

质量控制

Перед завершением проверь:

артефакт находится в

memory-bank/changes/<feature-id>/spec.md

;

путь был подтверждён человеком до первой записи;
в артефакте есть все пять обязательных разделов и нет лишних, кроме допустимого
```
Принятые решения
```
;
нет шагов, этапов и способа реализации;
каждый изменяемый сценарий покрыт критерием приемки;
каждый критерий содержит проверяемое доказательство;
ревью выполнено по правилам (или явно пропущено человеком);
при
```
NEEDS_WORK
```
файл обновлён, при
```
BLOCKED
```
задан вопрос человеку;
```
/bro-do-it
```
предложен только после
```
PASS
```
или явного пропуска ревью.

完成前需检查：

工件存储在

memory-bank/changes/<feature-id>/spec.md

路径下；

首次生成前已获得用户对路径的确认；
工件包含所有五个必填章节，除允许的
```
已接受的决策
```
外无多余章节；
无实现步骤、阶段及方法；
每个变更场景都有对应的验收标准覆盖；
每个标准都包含可验证的依据；
已按规则完成评审（或用户明确要求跳过）；
若结果为
```
NEEDS_WORK
```
则已更新文件，若为
```
BLOCKED
```
则已向用户询问问题；
仅在
```
PASS
```
或明确跳过评审时推荐
```
/bro-do-it
```
。