AB discuss-before-begin
Действуйте как «строгий, но доброжелательный критик», чтобы тщательно обсудить реальные потребности пользователя, шаблоны проектирования и проблемы, которые могли быть упущены. Сохраняйте интенсивность допроса: без лести, без упущения двусмысленности или конфликта — всякий раз, когда требования неясны или противоречивы, спрашивайте снова, пока обе стороны не достигнут консенсуса. Используйте, когда пользователь говорит «давайте обсудим», «помогите мне изучить», «разберем требования», «спроектируем решение», «рассмотрим этот план», «я хочу сделать X», «я что-то упускаю», «что я упускаю» или просит уточнить план, идею, предложение, статью или концепцию стартапа. Не приступайте к реализации самостоятельно, пока обсуждение не получит явного подтверждения консенсуса от пользователя.
машинный переводПоказать оригиналСкрыть оригинал«Act as a "strict but benevolent critic" to thoroughly discuss the user…»
Act as a "strict but benevolent critic" to thoroughly discuss the user's real needs, design patterns, and issues that may not have been considered. Keep the intensity of an interrogation: no flattery, no letting ambiguity or conflict slide — whenever requirements are unclear or contradictory, ask again until both sides reach consensus. Use when the user says "let's discuss", "help me explore", "sort out the requirements", "design a solution", "review this plan", "I want to do X", "am I missing anything", "what am I overlooking", or asks to refine a plan, idea, proposal, article, or startup concept. Do not enter implementation on your own before the discussion has received the user's explicit confirmation of consensus.
Действуйте как «строгий, но доброжелательный критик», чтобы тщательно обсудить реальные потребности пользователя, шаблоны проектирования и проблемы, которые…
Как процесс B 65/100 · Почти готов — слабые места: результат и критерий готовности, входы и предусловия, повторный запуск
Как улучшить
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 0
✓ Критических и высоких находок нет
Просканировано файлов: 2. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
- предупреждение
frontmatter-yamlSKILL.md: фронтматтер не разбирается как YAML (YAML parse error: Nested mappings are not allowed in compact mappings at line 2, column 14: description: Act as a "strict but benevolent critic" to thoroughly discuss the … ^ ); поля прочитаны построчно. Обычная причина — двоеточие в незакавыченном значении
Процессный рейтинг: все десять параметров 65/100
- 0Входы и предусловия. Не сказано, что нужно иметь на входе
- 0Отчётность по ходу. Скилл ничего не сообщает по ходу работы
- 30Повторный запуск. Изменяющих операций: 1, без проверки текущего состояния
- 40Результат и критерий готовности. Не сказано, что считать результатом
- 60Инструменты и файлы. Используются инструменты (node), но во frontmatter они не объявлены
- 70Когда включается. Сказано, когда применять, но не сказано, когда не стоит
- 100Шаги. Шагов: 33
- 100Ошибки и развилки. Развилок: 1, есть раздел про ошибки
- 100Согласованность. Имя и обязательные поля на месте
- 100Стоимость исполнения. Тело инструкции 1740 токенов
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +4Описание не говорит, когда скилл НЕ применять (ложные срабатывания)
- +3Формат ответа не описан: модель каждый раз решает сама
- +1Лицензия не указана
- +2Инструкции на одном языке
- +5В description 9 примера фраз-триггеров в кавычках
- +3Длина description 727 символов: достаточно сигнала, не съедает бюджет
- +4Структура: 11 заголовков
- +3Пошаговые инструкции: 33 пунктов
- +4Есть примеры (0 блоков кода)
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 79.