BB omem
Искать в локальной рабочей памяти пользователя (Office Memory / OMem) — унифицированной, локально индексируемой вики, созданной из писем, событий календаря, документов и заметок для совместной работы пользователя. OMem получает данные из любых источников, настроенных пользователем: почта (например, macOS Mail.app, Outlook Classic, Outlook в Интернете, почтовые ящики, управляемые AppleScript), календарь (Calendar.app, календари Outlook, файлы .ics), файлы (любая локальная папка — OneDrive, Dropbox, iCloud Drive, ~/Documents, обычные каталоги) и заметки Loop (заметки Microsoft Teams Loop). Будущие версии добавят Slack / Jira / Notion. Вики абстрагируется от всего этого — вам не нужно знать, из какого источника получен результат. ИСПОЛЬЗУЙТЕ ЭТОТ НАВЫК, когда вопрос пользователя касается его рабочего контекста, даже косвенно — прошлые встречи, имена коллег, кодовые названия проектов, детали поставщиков/контрактов, «тот документ, который я видел на прошлой неделе», «что X сказал о Y», предстоящие/прошедшие события календаря, внутренние аббревиатуры, RFP, обзоры производительности, OKR, все, что может храниться в его рабочей истории (любой почтовый ящик, календарь, локальная папка или инструмент для совместной работы, который он использует для работы). Если сомневаетесь, СНАЧАЛА ВЫПОЛНИТЕ omem query и решите позже, помогут ли результаты. НЕ используйте этот навык для: погоды, общих вопросов по программированию, перевода, математики, поиска общедоступной информации или чего-либо, где пользователь явно НЕ спрашивает о своей рабочей истории. Основной инструмент: `omem query "<question>" --format json --limit 20`. Затем постепенно углубляйтесь через `omem page get <page_id>`, `omem raw get <page_id> --parsed`, `omem raw get <page_id>`. Обычно одного запроса и одной страницы достаточно для ответа на вопрос — прочитайте, процитируйте, готово. Только когда ответ на странице зависит от конкретного термина, человека или документа, которые вы не разрешили, снова выполните запрос для этой конкретной вещи — следуйте за нитью, не ползайте по графу. Никогда не вызывайте `omem setup / install / ingest / lint / index rebuild` — это действия пользователя; вместо этого сообщите пользователю на естественном языке.
машинный переводПоказать оригиналСкрыть оригинал«Search the user's local work memory (Office Memory / OMem) — a unified…»
Search the user's local work memory (Office Memory / OMem) — a unified, locally-indexed wiki built from the user's emails, calendar events, documents, and collaboration notes. OMem ingests from whatever sources the user has configured: mail kind (e.g. macOS Mail.app, Outlook Classic, Outlook on the Web, AppleScript-driven mailboxes), calendar kind (Calendar.app, Outlook calendars, .ics files), file kind (any local folder — OneDrive, Dropbox, iCloud Drive, ~/Documents, plain directories), and loop kind (Microsoft Teams Loop notes). Future versions add Slack / Jira / Notion. The wiki abstracts over all of these — you don't need to know which source a hit came from. USE THIS SKILL whenever the user's question touches their work context, even implicitly — past meetings, colleagues' names, project codenames, vendor/contract details, "that document I saw last week", "what did X say about Y", upcoming/past calendar items, internal acronyms, RFPs, performance reviews, OKRs, anything that sounds like it could live in their work history (any inbox, calendar, local folder, or collaboration tool they use for work). When in doubt, CALL omem query FIRST and decide afterward whether the results help. DO NOT use this skill for: weather, general programming questions, translation, math, public-knowledge lookups, or anything where the user clearly is NOT asking about their own work history. Primary tool: `omem query "<question>" --format json --limit 20` Then progressively drill down via `omem page get <page_id>`, `omem raw get <page_id> --parsed`, `omem raw get <page_id>`. Usually one query and one page answers the question — read it, cite, done. Only when a page's answer hinges on a specific term, person, or document you haven't resolved, query again for that one thing — follow the thread, don't crawl the graph. Never call `omem setup / install / ingest / lint / index rebuild` — those are user actions; tell the user in natural language instead.
Искать в локальной рабочей памяти пользователя (Office Memory / OMem) — унифицированной, локально индексируемой вики, созданной из писем, событий календаря…
Как процесс B 78/100 · Почти готов — слабые места: результат и критерий готовности, повторный запуск
Чем это грозит
Находки средней серьёзности: скорее всего скилл честный, но прочитайте, что именно насторожило сканер.
Ниже описан худший случай для этой категории. Здесь находка средней серьёзности: guard увидел признак, но не доказательство.
Скилл просит больше прав, чем нужно для задачи: широкий доступ к инструментам, секретные переменные окружения, бинарные файлы. Каждое лишнее право расширяет ущерб при ошибке или взломе.
Сузьте allowed-tools и список переменных до минимума, замените бинарники на исходники или скрипты, которые можно прочитать.
Как улучшить
- Сократите description до 1024 символов.
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 2
✓ Критических и высоких находок нет
Средние и низкие: 2
-
средняя Широкие права
meta-broad-allowed-toolsSKILL.md:1Заранее разрешены широкие инструменты: Bashallowed-tools: Bash Read
-
низкая Опасные команды
cmd-pipe-to-shell-known-hostreferences/troubleshooting.md:14Установщик через pipe в shell с известного хоста (всё равно выполняет удалённый код) (в кавычках — упоминание, а не команда)> `curl -fsSL https://github.com/seacen/omem/releases/latest/download/install.sh | sh`
в кавычках
Просканировано файлов: 5. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
- ошибка
description-longdescription 1966 символов, лимит 1024 - заметка
description-budgetdescription занимает 1966 из общего бюджета ~15000 символов на все скиллы
Процессный рейтинг: все десять параметров 78/100
- 0Результат и критерий готовности. Не сказано, что считать результатом
- 30Повторный запуск. Изменяющих операций: 4, без проверки текущего состояния
- 70Входы и предусловия. Входные данные и предусловия перечислены
- 85Шаги. Шагов: 65, расплывчатых формулировок: 3
- 100Инструменты и файлы. Инструменты объявлены во frontmatter
- 100Когда включается. Сказано, когда применять и когда не применять
- 100Ошибки и развилки. Развилок: 3, есть раздел про ошибки
- 100Согласованность. Имя и обязательные поля на месте
- 100Стоимость исполнения. Тело инструкции 3818 токенов
- 100Отчётность по ходу. Скилл сообщает о ходе работы
- low Разделов верхнего уровня: 10. Похоже на несколько доменов в одном скилле
- low Скилл сам сортирует и ранжирует выдачу: это работа системы на той стороне, а не модели
- low Ответ описан самодельной разметкой (4 тегов): типизированный вызов надёжнее
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +3Длина description 1965: рекомендуется 120–800 символов
- +3Формат ответа не описан: модель каждый раз решает сама
- +1Лицензия не указана
- +2Инструкции на одном языке
- +5В description 3 примера фраз-триггеров в кавычках
- +4Описание говорит, когда скилл НЕ применять
- +4Структура: 16 заголовков
- +3Пошаговые инструкции: 65 пунктов
- +4Есть примеры (1 блоков кода)
- +4Справочные файлы упоминаются в инструкциях (3 из 3)
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 66.