Когда использовать: Вы нашли статью без paywall, страницу документации или пост в блоге и хотите краткое резюме с мнением, без необходимости читать самому.
Поток
-
Загрузьте с выводом Markdown
Загрузьте https://example.com/blog/post и дайте мне первые ~3000 символов чистым Markdown.✓ Скопировано
→ Содержимое приходит с рабочими заголовками и без элементов навигации
-
Резюмируйте и выделите утверждения
Резюмируйте в 5 пунктах. Перечислите все конкретные числа или утверждения автора, с предложением, в котором они появляются.✓ Скопировано
→ Резюме с пунктами плюс цитированные куски, не парафразированные
-
Критика
Какой самый сильный контраргумент к основному тезису автора? Будьте конкретны.✓ Скопировано
→ Реальная критика, не 'с другой стороны...' размытость
Итог: Полезное понимание статьи за 30 секунд, с цитатами, которые можно проверить.
Подводные камни
- Страница рендерится через JS и fetch возвращает почти пустую оболочку — Проверьте первый вывод fetch — если он подозрительно короткий или содержит 'Loading...', переходите на Firecrawl или Chrome DevTools MCP
- Длинная страница усечена параметром max_length — Используйте
start_index для разбиения: второй вызов с start_index: 5000 продолжит с того, где закончился первый
Когда использовать: Библиотека, от которой вы зависите, публикует release notes на статической странице, и вы не проверяли месяц назад.
Поток
-
Загрузьте страницу журнала изменений
Загрузьте https://vendor.com/changelog и перечислите каждый релиз после 2026-03-01 с датой и однострочным резюме того, что изменилось.✓ Скопировано
→ Хронологический список с датами
-
Классифицируйте по влиянию
Категоризируйте каждый на: breaking change, новая функция, исправление ошибки, внутренние. Выделите всё, что помечено как breaking или deprecated.✓ Скопировано
→ Тег по релизу с выделенными breaking элементами
-
Выделите то, что нас касается
Мы используем эту библиотеку в основном для <функция X>. Какие из этих изменений влияют на нашу работу и какие действия (если нужны) мы должны предпринять?✓ Скопировано
→ Практический список, не общие 'посмотрите примечания'
Итог: Узнайте за 2 минуты, нужно ли вам обновлять версию и тестировать, или вообще пропустить релиз.
Подводные камни
- Журналы изменений разбиты на страницы — первая страница содержит только последние 2 месяца — Прокрутитесь через
start_index или явно загрузьте URL архива - Страницы GitHub release теперь рендерятся через JS — Используйте API вместо этого:
https://api.github.com/repos/owner/repo/releases возвращает JSON без необходимости JS
Когда использовать: Вы кодируете против публичной спецификации (OAuth, RFC 9457 problem details, документация REST API) и хотите, чтобы Claude имел авторитетный источник.
Поток
-
Загрузьте страницы спецификации
Загрузьте https://datatracker.ietf.org/doc/html/rfc9457 как Markdown. Возвращайте только разделы 1-4.✓ Скопировано
→ Чистый Markdown нормативных разделов
-
Реализуйте согласно этому
Используя этот RFC как авторитетный источник, напишите мне TypeScript тип плюс валидатор для объекта problem details. Указывайте конкретные номера разделов в комментариях.✓ Скопировано
→ Код с inline // per RFC 9457 §3.1 ссылками
-
Проверка граничных случаев
Из того же RFC, какие граничные случаи или опциональные поля моя реализация не обрабатывает? Решите, обрабатывать их или документировать выбор.✓ Скопировано
→ Честный анализ пробелов согласно спецификации
Итог: Реализация, соответствующая спецификации, с отслеживаемыми цитатами, которые вы можете защитить в code review.
Подводные камни
- Страницы IETF огромны — весь RFC может превысить бюджет контекста — Загрузьте только нужные разделы, используя якорные ссылки или start_index, не весь документ