BC workflow-refactor
Методология реструктуризации рабочих процессов. Основная способность: реструктуризация сложных рабочих процессов в любой области в упрощенные методы для выполнения одним человеком с помощью ИИ (разложение компенсационных слоев ограничений человека → устранение → реорганизация на основе модели возможностей ИИ). Трехэтапный метод: разложение (определение причины существования каждого звена) → устранение (удаление компенсационных слоев ограничений человека) → реорганизация (переписывание в виде сквозной цепочки базовых элементов IPO на основе модели возможностей ИИ). Охватывает весь процесс от идентификации традиционных рабочих процессов, анализа звеньев, устранения компенсационных слоев, реорганизации цепочки базовых элементов IPO, проверки реструктуризации до выбора формы выполнения. 6 типов задач, список компонентов для каждой задачи и 1 полный практический пример. Универсальный метод, не привязанный к какой-либо конкретной области. Триггерные слова: реструктуризация рабочего процесса, реструктуризация процесса, упрощение процесса, workflow refactor, оптимизация рабочего процесса, реинжиниринг процесса, реорганизация процесса, устранение избыточных звеньев, сквозная реструктуризация.
машинный переводПоказать оригиналСкрыть оригинал«工作流重构方法。核心能力：将任何领域的复杂工作流重构为AI辅助一人简易完成的方法（拆解人的局限补偿层→消除→基于AI能力模型重整）。三步法：…»
工作流重构方法。核心能力：将任何领域的复杂工作流重构为AI辅助一人简易完成的方法（拆解人的局限补偿层→消除→基于AI能力模型重整）。三步法：拆解（识别每个环节的存在理由）→消除（去掉人的局限补偿层）→重整（基于AI能力模型重编为端到端IPO基元链）。覆盖从传统工作流识别、环节分析、补偿层消除、IPO基元链重整、重构验证到执行形态选择的全流程。6种任务类型、每种任务的组件清单与1个完整实战范本。通用方法，不绑定任何特定领域。触发词：工作流重构、流程重构、流程简化、workflow refactor、工作流优化、流程再造、流程重组、消除冗余环节、端到端重构。
Методология реструктуризации рабочих процессов.
Как процесс C 53/100 · Есть пробелы — слабые места: результат и критерий готовности, когда включается, входы и предусловия
Как улучшить
- Скажите в description, КОГДА применять скилл («используй, когда…», примеры запросов): это главный сигнал для агента.
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 0
✓ Критических и высоких находок нет
Просканировано файлов: 2. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
- предупреждение
description-no-whendescription не говорит, КОГДА применять скилл (нет "use when / используй когда")
Процессный рейтинг: все десять параметров 53/100
- 0Результат и критерий готовности. Не сказано, что считать результатом
- 0Входы и предусловия. Не сказано, что нужно иметь на входе
- 0Ошибки и развилки. Линейный процесс без обработки сбоев
- 0Отчётность по ходу. Скилл ничего не сообщает по ходу работы
- 20Когда включается. Не сказано, при каком запросе скилл включается
- 100Инструменты и файлы. Внешние инструменты не нужны
- 100Шаги. Шагов: 46
- 100Согласованность. Имя и обязательные поля на месте
- 100Стоимость исполнения. Тело инструкции 2199 токенов
- 100Повторный запуск. Изменяющих операций нет
- low Разделов верхнего уровня: 12. Похоже на несколько доменов в одном скилле
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +5В description нет примеров фраз, по которым скилл должен срабатывать
- +4Описание не говорит, когда скилл НЕ применять (ложные срабатывания)
- +3Формат ответа не описан: модель каждый раз решает сама
- -239 эмодзи в инструкциях: шум для модели
- +1Лицензия не указана
- +2Инструкции на одном языке
- +3Длина description 280 символов: достаточно сигнала, не съедает бюджет
- +4Структура: 22 заголовков
- +3Пошаговые инструкции: 46 пунктов
- +4Есть примеры (2 блоков кода)
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 70.