BC mastery-assessment
Протокол закрытого тестирования, который оценивает, насколько хорошо учащийся усвоил утверждения модуля — спрашивает перед тем, как сообщить, исследует пробел, выявляет заблуждения, затем подтверждает. Помечает каждый вопрос уровнем Блума, помещает учащегося в группу мастерства Дрейфуса (незнакомый/осведомленный/функциональный/компетентный/беглый), оценивает сессию и планирует следующее повторение с интервалами (1 день, 3 дня, 7 дней, 16 дней, 35 дней) — сокращая дату следующего повторения при ошибке. Пишет заметку о сессии оценки в assessments/log/ и предлагает обновление review-due для каждой затронутой вечной заметки. Используйте при проверке мастерства модуля, проведении повторения с интервалами или при ограничении перехода между фазами. Ключевые слова для запуска — оценка мастерства, review-due, интервальное повторение, проверка Блума, группа мастерства, готов ли я двигаться дальше.
машинный переводПоказать оригиналСкрыть оригинал«A closed-book-first probing protocol that assesses how well the learne…»
A closed-book-first probing protocol that assesses how well the learner actually holds a module's claims — asking before telling, probing the gap, detecting misconceptions, then confirming. Tags each probe with a Bloom level, places the learner in a Dreyfus mastery band (unfamiliar/aware/functional/proficient/fluent), scores the session, and schedules the next spaced-repetition surfacing on expanding intervals (1d, 3d, 7d, 16d, 35d) — pulling the next date earlier on a miss. Writes an assessment-session note to assessments/log/ and proposes a review-due update on each evergreen note touched. Use when checking mastery of a module, running a spaced-repetition review, or gating phase progression. Trigger keywords — assess mastery, review-due, spaced repetition, Bloom check, mastery band, am I ready to move on.
Протокол закрытого тестирования, который оценивает, насколько хорошо учащийся усвоил утверждения модуля — спрашивает перед тем, как сообщить, исследует…
Как процесс C 60/100 · Есть пробелы — слабые места: результат и критерий готовности, когда включается, ошибки и развилки
Как улучшить
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 0
✓ Критических и высоких находок нет
Просканировано файлов: 1. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
✓ По спецификации Agent Skills замечаний нет
Процессный рейтинг: все десять параметров 60/100
- 0Результат и критерий готовности. Не сказано, что считать результатом
- 0Ошибки и развилки. Линейный процесс без обработки сбоев
- 20Когда включается. Не сказано, при каком запросе скилл включается
- 30Повторный запуск. Изменяющих операций: 5, без проверки текущего состояния
- 70Входы и предусловия. Входные данные и предусловия перечислены
- 100Инструменты и файлы. Внешние инструменты не нужны
- 100Шаги. Шагов: 23
- 100Согласованность. Имя и обязательные поля на месте
- 100Стоимость исполнения. Тело инструкции 2476 токенов
- 100Отчётность по ходу. Скилл сообщает о ходе работы
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +5В description нет примеров фраз, по которым скилл должен срабатывать
- +4Описание не говорит, когда скилл НЕ применять (ложные срабатывания)
- +3Длина description 818: рекомендуется 120–800 символов
- +3Формат ответа не описан: модель каждый раз решает сама
- +1Лицензия не указана
- +2Инструкции на одном языке
- +4Структура: 9 заголовков
- +3Пошаговые инструкции: 23 пунктов
- +4Есть примеры (1 блоков кода)
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 81.