/verify-hypotheses
SkillMonitoring & opsVerifies the hypotheses log (hypotheses-log.md) on request, outside the week-close rhythm. Filters entries with status "pending verification" and a due date, checks the falsification criterion against available facts, proposes a verdict; the pilot confirms, and the verdict is recorded as a new entry
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the /verify-hypotheses skill
What this skill tells your AI
The instructions your AI receives, as published by tserentserenov/fmt-exocortex-template in .claude/skills/verify-hypotheses/SKILL.md and read by ahel’s review.
Scope: прочитать
hypotheses-log.md, найти записи с наступившей датой сверки, сверить с фактурой, предложить вердикт, записать подтверждённый пилотом вердикт новой записью. Not in scope: не создаёт новые гипотезы (это Note-Review), не выполняет сверку на week-close автоматически (это шаг 6a.claude/skills/week-close/SKILL.md— этот скилл дублирует тот же алгоритм для вызова вне недельного ритма), не редактирует исходные записи. Role: нет выделенной роли-носителя — используется тем, кто сейчас ведёт week-close (Стратег, R1). См. открытый АрхГейт-вопрос РП-496 Ф4.
When to use
- Пилот говорит «сверь гипотезы недели» или «сверь гипотезы» вне обычного ритма Week Close.
- Есть подозрение, что конкретная гипотеза уже разрешилась (пилот увидел факт раньше даты сверки) и хочет проверить досрочно.
- Диагностика: сколько гипотез сейчас «на сверке» и когда у них дата.
Preconditions
- WP Gate precondition. Задача привязана к РП-496 (Журнал гипотез, LPF-регламент обратной связи), фаза 3.
- Журнал существует.
{{GOVERNANCE_REPO}}/current/hypotheses-log.md— если файла нет, сообщить пилоту и завершить (журнал ещё не создан или создан в другом месте).
Algorithm
Step 1 — Прочитать журнал и отфильтровать
Input: {{GOVERNANCE_REPO}}/current/hypotheses-log.md
Action: прочитать все записи. Отобрать те, у которых Статус: на сверке И Дата сверки ≤ сегодня. Записи со статусом черновик (не подтверждённые пилотом на Note-Review) пропустить — они вне цикла сверки. Записи, уже имеющие вердикт (подтверждена/опровергнута/частично подтверждена/неприменимо), пропустить.
Output: список ID (H-NNN) с наступившей датой сверки, готовых к проверке. Если список пуст — сообщить «Нет гипотез с наступившей датой сверки» и завершить (не ошибка, штатный результат).
Step 2 — Сверить каждую запись с фактурой
Input: список ID из Step 1
Action: для каждой записи прочитать критерий фальсификации и сверить с доступными источниками — коммиты (git log по затронутым репо), domain_event (если критерий про измеримую метрику платформы), инфраструктурные логи, факты из ближайшего WeekReport/DayPlan. Если критерий требует данных, которых нет в доступных источниках — явно пометить «данных недостаточно для вердикта», не гадать.
Output: для каждой записи — черновик вердикта (подтверждена / опровергнута / частично подтверждена / неприменимо) с обоснованием (какие факты сверены, откуда).
Правило «неприменимо»: если условие критерия физически не выполнено (например, зависимый артефакт, о котором гипотеза, не был доставлен) — вердикт «неприменимо», не «опровергнута». Нельзя отличить провал гипотезы от провала внедрения, если предпосылка критерия не соблюдена.
Step 3 — Предложить пилоту и получить подтверждение
Input: черновики вердиктов из Step 2 Action: показать пилоту таблицу (ID, утверждение кратко, предложенный вердикт, обоснование). Спросить подтверждение или правку на каждую запись. Output: финальный вердикт по каждой записи, согласованный с пилотом.
Step 4 — Записать вердикт и предложить действие
Input: финальные вердикты из Step 3
Action: для каждой записи — добавить новую запись в конец hypotheses-log.md в формате ## Сверка H-NNN со ссылкой на исходную запись, вердиктом и датой сверки. Исходную запись НЕ редактировать (запрет правки задним числом — memory/lpf-hypothesis-log.md). Обновить Статус в исходной записи на итоговый (это единственное поле исходной записи, которое меняется — статус, не содержание). Затем спросить: какое действие следует из этого вердикта — обновить уверенность на будущее / добавить шаг в чек-лист / завести РП / зафиксировать кандидат в паттерн (Capture-to-Pack). Выбранное действие исполняется вне этого скилла (терминальный выход — уходит в WeekPlan/Pack/РП, потребитель за пределами контура verify-hypotheses).
Output: журнал обновлён, каждый вердикт имеет привязанное действие (не «повисший»).
Step 5 — Коммит
Input: обновлённый hypotheses-log.md
Action: закоммитить в governance-репо (тот же процесс, что и другие правки current/).
Output: изменения сохранены, история гипотез не потеряна.
Bundled resources
Нет — алгоритм полностью текстовый, без скриптов/шаблонов.
Anti-patterns
- Не выносить вердикт без сверки с реальной фактурой — «показалось, что подтвердилась» не считается.
- Не редактировать исходную запись гипотезы при вынесении вердикта — только новая запись со ссылкой.
- Не выносить «опровергнута» вместо «неприменимо», когда предпосылка критерия не выполнена.
- Не оставлять вердикт без выбранного действия — «повисший» вердикт не закрывает цикл.
- Не запускать этот скилл автоматически на каждой сессии — только по явному запросу пилота (недельный ритм покрыт шагом 6a week-close).
Verification
bash scripts/verify-skill.sh verify-hypotheses
Ожидаемый результат: PASS. Живая проверка — вызвать скилл вручную после 2026-09-01 (дата сверки первой записи H-001 в hypotheses-log.md), убедиться, что алгоритм находит именно эту запись и не находит других (журнал сейчас содержит только H-001).
Signals
- GitHub stars
- 54
- Forks
- 150
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
verify-hypotheses- Source
- github.com/tserentserenov/fmt-exocortex-template