{"owner":"massCodeIO","repo":"massCode","hasSkills":true,"totalSkillsCount":15,"totalTokensCount":13666,"categories":["anthropic-skill","root-instruction","claude-rule"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/api-and-typing/SKILL.md",".agents/skills/architecture-standards/SKILL.md",".agents/skills/development-workflow/SKILL.md",".agents/skills/documentation-workflow/SKILL.md",".agents/skills/electron-api-and-ipc/SKILL.md",".agents/skills/github-workflow/SKILL.md",".agents/skills/release-notes/SKILL.md",".agents/skills/spaces-architecture/SKILL.md",".agents/skills/ui-foundations/SKILL.md",".agents/skills/ui-primitives/SKILL.md",".agents/skills/vue-renderer-standards/SKILL.md","AGENTS.md","CLAUDE.md","docs/website/documentation/tools/index.md","docs/website/documentation/tools/json-diff.md"],"skills":{".agents/skills/api-and-typing/SKILL.md":"---\nname: api-and-typing\ndescription: Use when defining or reviewing massCode renderer types that come from generated API clients or DTOs, especially when deciding whether to reuse existing API shapes, derive narrower local types, or introduce a UI-only model.\n---\n\n# API And Typing\n\n## Overview\n\nДля massCode API types считаются generated-first. Если данные пришли из `~/renderer/services/api/generated` или соответствуют DTO из `src/main/api/dto`, сначала используй существующие типы и utility typing, а не придумывай новый interface рядом с компонентом.\n\n## Core Rules\n\n- Ручные дубли API response types не пиши.\n- Сначала ищи тип в `~/renderer/services/api/generated`.\n- Если прямого export нет, выводи нужный shape через `Pick`, `Omit`, indexed access, `Parameters`, `ReturnType`, `Awaited`, `NonNullable`.\n- Локальный тип допустим только как UI-only model, form model, derived display model или narrow type после нормального data narrowing.\n\n## Good Uses Of Local Types\n\n- Узкий renderer shape после того, как nullable API data уже очищена в одном месте.\n- View-model для dashboard card, graph node, readonly row или editor-side helper, если он не равен transport shape.\n- Тип аргумента, выводимый из существующего composable или API method через `Parameters` / `ReturnType`.\n\n## Bad Uses Of Local Types\n\n- Полный дубль `SnippetsResponse`, `NotesDashboardResponse`, `TagsResponse` и других generated types.\n- Новый interface “для удобства”, если можно взять одну ветку из existing response type.\n- Копирование DTO shape в renderer file, хотя он уже импортируемый.\n\n## Common Mistakes\n\n- Сначала придумать локальный interface, а потом уже искать generated type.\n- Смешать transport shape и UI view-model без явного adapter step.\n- Тащить глубоко в UI сырые nullable API поля вместо одного нормального normalization place.\n",".agents/skills/architecture-standards/SKILL.md":"---\nname: architecture-standards\ndescription: Use when working in massCode and you need repo-wide architecture rules, naming conventions, decomposition boundaries, or guidance on which massCode skill to load next.\n---\n\n# Architecture Standards\n\n## Overview\n\nБазовый принцип проекта: **YAGNI и простота прежде всего**. Не усложняй код ради гипотетических сценариев, не строй абстракции без повторяющейся потребности и не размывай границы между renderer, API и main.\n\n## Core Rules\n\n- Соблюдай разделение слоёв:\n  - Renderer: только UI, composables, вызовы `api.*` и `ipc.invoke(...)`.\n  - API: маршруты Elysia, DTO, orchestration и доступ к сервисам и данным приложения.\n  - Main: системные интеграции, IPC handlers, lifecycle и слой данных приложения.\n- Data flow по умолчанию: Renderer → API / IPC → service / data layer → response.\n- Vue-компоненты называй в `PascalCase`.\n- TypeScript-файлы называй в `camelCase`.\n- Composables именуй с префиксом `use`, а имя файла должно совпадать с экспортируемой функцией.\n\n## YAGNI Guardrails\n\nПризнаки overengineering:\n\n- функция страхуется от кейса, которого реально не существует;\n- factory или wrapper используется ровно в одном месте и не скрывает состояние;\n- abstraction-for-abstraction без повторяющейся боли;\n- константы, паттерны и конфигурации придуманы заранее, а не из реальной потребности.\n\n## Component Decomposition\n\n- Если компонент становится больше примерно `300` строк или держит `3+` несвязанных обязанности, дели его.\n- Порядок разбиения:\n  1. вынеси константы и статические данные;\n  2. вынеси чистые функции в utils, только если это реально переиспользуется;\n  3. перемести состояние и эффекты в composable;\n  4. разбей шаблон на локальные child components.\n- Не держи в `<template>` логику сложнее тернарного оператора.\n\n## Feature Subdirectories\n\n- Если часть домена выросла в отдельный subsystem, группируй локальные компоненты, helpers, tests и fixtures в поддиректорию.\n- Внутри поддиректории не повторяй полный родительский префикс в именах файлов.\n- Локальные файлы держи рядом с фичей. Shared-код, который нужен нескольким областям, оставляй выше уровнем.\n\n## When to Load Other Skills\n\n- Vue renderer, auto-imports, composables, shared state:\n  `vue-renderer-standards`\n- визуальная база, typography, renderer styling decisions:\n  `ui-foundations`\n- `Ui*`, Shadcn, `cn`, `cva`, notifications:\n  `ui-primitives`\n- API routes, DTO, IPC, Electron boundaries:\n  `electron-api-and-ipc`\n- generated API types, utility typing, локальные view-model:\n  `api-and-typing`\n- `code` / `notes` / `math` / `tools`, состояние spaces и их синхронизация:\n  `spaces-architecture`\n- i18n, locale keys, `i18n.t(...)`:\n  `i18n`\n- docs website, docs sidebar, скриншоты, README-упоминания фич:\n  `documentation-workflow`\n- scoped lint/test и follow-up commands:\n  `development-workflow`\n\n## Common Mistakes\n\n- Тянуть DB или filesystem knowledge в renderer.\n- Раздувать один компонент до “оркестратора всего”.\n- Выносить абстракцию до появления второй реальной точки использования.\n- Размазывать одну фичу по плоской структуре файлов, когда ей уже нужен локальный subdirectory.\n- Придумывать локальные typing-паттерны, хотя для них уже пора иметь отдельный skill.\n",".agents/skills/development-workflow/SKILL.md":"---\nname: development-workflow\ndescription: Use when following massCode repo workflow rules, especially for scoped lint and test commands, or when changes require required follow-up commands like code generation or locale sync.\n---\n\n# Development Workflow\n\n## Overview\n\nВ massCode workflow rules считаются частью качества изменений. Для локальной задачи команды должны быть точечными, а изменения source-of-truth файлов должны сопровождаться обязательными follow-up шагами.\n\n## Linting Rules\n\n- Всегда запускай lint только по затронутым файлам или директориям.\n- Никогда не запускай lint по всему проекту во время локальной задачи.\n- Используй scoped commands вроде:\n  - `pnpm lint <path>`\n  - `pnpm lint:fix <path>`\n\n## Testing Rules\n\n- Всегда запускай тесты только по затронутым файлам или директориям.\n- Никогда не запускай весь test suite без явной необходимости.\n- Используй scoped commands вроде:\n  - `pnpm test <path>`\n  - `pnpm test:watch <path>`\n\n## Required Follow-Up Commands\n\n- Изменил API DTO/routes → `pnpm api:generate`\n- Изменил locale-файлы → `pnpm i18n:copy`\n\n## Common Mistakes\n\n- Прогонять весь lint/test suite для маленькой точечной правки.\n- Менять source-of-truth файлы и забывать generation/sync шаг.\n- Запускать “на всякий случай” широкие команды вместо минимального релевантного набора.\n",".agents/skills/documentation-workflow/SKILL.md":"---\nname: documentation-workflow\ndescription: Use when adding or updating massCode documentation, documenting a new feature, changing docs website pages, adding docs assets, updating the VitePress sidebar, or adding README feature mentions.\n---\n\n# Documentation Workflow\n\n## Overview\n\nДокументация massCode живёт в VitePress сайте в `docs/website/documentation`. README — это общий обзор проекта, а не источник детального описания фич.\n\n## Documentation Surfaces\n\n- Документация фич: `docs/website/documentation/**`\n- Sidebar документации: `docs/website/.vitepress/config.mts`\n- Assets документации: `docs/website/public/**`\n- Overview документации: `docs/website/documentation/index.md`\n- Overview проекта: `README.md`\n\n## Core Rules\n\n- Проверяй поведение фичи в коде или существующей документации; не документируй по памяти.\n- Используй `rg`, чтобы найти связанные страницы, скриншоты, shortcuts, labels и существующие формулировки.\n- Если целевая версия известна, используй именно её. Если версия неизвестна, не придумывай её.\n- Пользовательская документация сайта пишется на английском, в стиле существующих docs pages.\n- Добавляй или обновляй наиболее конкретную страницу в `docs/website/documentation`.\n- Для новых страниц используй frontmatter с `title` и `description`.\n- Добавляй страницу в `docs/website/.vitepress/config.mts` только если она должна появиться в навигации.\n- Ссылайся из `docs/website/documentation/index.md` только на широкие, cross-cutting фичи.\n- Пиши короткими task-oriented секциями. Предпочитай пользовательские флоу, а не детали реализации.\n- Shortcuts документируй через `<kbd>...</kbd>` и указывай macOS плюс Windows/Linux варианты, если они отличаются.\n\n## Version Availability\n\n- Перед добавлением или изменением `<AppVersion>` проверяй историю фичи в коде, документации или предыдущем релизном теге.\n- Считай `<AppVersion text=\">=x.y\" />` минимальной версией, где появилась ровно описываемая возможность, а не версией её последнего улучшения.\n- Ставь marker на уровне страницы или общего раздела только когда вся описываемая сущность впервые появилась в этой версии.\n- Если новый релиз расширяет существующую фичу, сохраняй её исходный marker или отсутствие marker, а новую версию указывай только у отдельного подпункта или предложения про улучшение.\n- Разделяй смешанное описание на базовую возможность и versioned enhancement, если общий marker создаёт впечатление, что старая возможность раньше была недоступна.\n- Не добавляй version marker для bugfix или внутренней переработки без нового пользовательского сценария. Локально отмечай изменение формата хранения, если оно влияет на совместимость.\n\nПример: если custom folder icons существуют с 3.7, а Emoji и Upload добавлены в 5.9, оставляй `>=3.7` у базовой возможности и ставь `>=5.9` только у подпункта про Emoji и Upload.\n\n## Documentation Weight\n\n- Перед созданием страницы или раздела оцени самостоятельность пользовательского сценария, количество шагов, настроек и ограничений.\n- Описывай мелкое одношаговое действие одной строкой или буллетом внутри существующего релевантного раздела.\n- Создавай отдельный раздел для самостоятельного workflow с несколькими шагами, вариантами, настройками или важными ограничениями.\n- Выбирай одно основное место для подробного описания cross-cutting фичи. В других страницах оставляй короткое упоминание или ссылку вместо повторения полного объяснения.\n- Оставляй bugfix, внутреннюю оптимизацию и implementation detail только в release notes, если они не меняют пользовательский сценарий или требования совместимости.\n\n## Callouts\n\n- Используй `warning` для риска потери данных, несовместимости, необратимого действия или существенного security-ограничения.\n- Используй `info` для автоматической миграции и неочевидного поведения, которое помогает правильно понять основной workflow.\n- Оставляй основные инструкции обычным текстом; callout должен выделять контекст или исключение, а не содержать весь сценарий.\n- Объединяй связанные риски в один callout и избегай нескольких соседних блоков, если их можно прочитать как одно сообщение.\n- Добавляй короткий предметный заголовок, например `::: warning Compatibility` или `::: info Automatic migration`.\n\n## VitePress Markdown Gotchas\n\n- VitePress компилирует markdown как Vue-компонент, поэтому `{{ ... }}` трактуется как Vue-интерполяция и **исчезает** из вывода.\n- Fenced-блоки (` ``` `) защищены автоматически — внутри них `{{var}}` рендерится буквально.\n- **Инлайн-код в backticks НЕ защищён**: `` `{{variables}}` `` отрендерится пустым. Чтобы вывести литеральные двойные фигурные скобки в тексте или таблице, оборачивай в `v-pre`:\n  `<code v-pre>{{variables}}</code>`\n- Это же касается любых других Vue-конструкций (`{{ }}`, директивы) в произвольном тексте страницы.\n\n## Images And Assets Rules\n\n- Картинки для docs клади в `docs/website/public`.\n- Ссылайся на картинки через `withBase`, например:\n  `<img :src=\"withBase('/feature.png')\">`\n- Если страница использует `withBase`, добавь соответствующий script block:\n  `import { withBase } from 'vitepress'`\n- Используй скриншоты только когда они реально объясняют фичу. Не добавляй декоративные изображения.\n\n## README Rules\n\n- Добавляй README-упоминания только для user-facing фич, которые важны на уровне общего обзора проекта.\n- Держи README copy коротким и product-level; подробное использование должно быть в `docs/website/documentation`.\n- Не пиши в README, когда фича была добавлена. Version availability должна жить в docs pages или release notes.\n- Не ставь новую фичу первой автоматически. Сохраняй текущую информационную архитектуру: сначала основные spaces/features, затем широкие workflow helpers, если пользователь не попросил иначе.\n\n## Validation\n\n- Запускай `git diff --check`.\n- Для изменений docs website запускай `pnpm -C docs/website build`.\n- Если нужно форматирование, ограничивай его изменёнными файлами и избегай широкого churn в config-файлах.\n- Не коммить без явной просьбы пользователя. Для commit или PR загружай `github-workflow`.\n\n## Common Mistakes\n\n- Добавлять README-only документацию для фичи, которой нужна настоящая docs page.\n- Забывать VitePress sidebar для новой страницы, которая должна быть в навигации.\n- Добавлять version availability в README.\n- Переносить `<AppVersion>` всего существующего раздела на версию, в которой фича лишь получила улучшение.\n- Создавать отдельный раздел для одношаговой мелкой фичи, которую достаточно упомянуть в существующем разделе.\n- Повторять полное описание cross-cutting фичи на нескольких страницах вместо одного основного места и коротких упоминаний.\n- Использовать callout для обычной инструкции без риска, совместимости или неочевидного поведения.\n- Документировать shortcuts или поведение без проверки реализации.\n- Запускать широкие formatters, которые переписывают существующий стиль docs config.\n- Писать литеральные `{{ ... }}` в инлайн-коде без `v-pre` — VitePress съест их как Vue-интерполяцию.\n",".agents/skills/electron-api-and-ipc/SKILL.md":"---\nname: electron-api-and-ipc\ndescription: Use when changing massCode API routes, DTOs, IPC handlers, Electron bridges, or any renderer-to-main communication and storage-access boundaries.\n---\n\n# Electron API And IPC\n\n## Overview\n\nВсе backend-возможности massCode живут в main process. Renderer получает доступ к данным и системным операциям только через Elysia API или IPC channels.\n\n## Renderer Access Rules\n\n- В renderer для данных используй `import { api } from '~/renderer/services/api'`.\n- В renderer для системных операций используй `ipc.invoke('channel:action', payload)`.\n- Electron API из renderer доступен только через `src/renderer/electron.ts`.\n- Никогда не импортируй storage internals или backend-модули напрямую в renderer.\n\n## New API Endpoints\n\nПри добавлении нового endpoint:\n\n1. создай DTO в `src/main/api/dto/`;\n2. добавь route в `src/main/api/routes/`;\n3. запусти `pnpm api:generate`, чтобы обновить клиент.\n\nНе оставляй API-клиент рассинхронизированным с route/DTO изменениями.\n\n## IPC Conventions\n\n- Для filesystem и system ops используй `ipc.invoke(...)`.\n- Каналы должны укладываться в семейства:\n  - `fs:*`\n  - `system:*`\n  - `db:*` — legacy или migration flows, не основной путь для новой функциональности\n  - `main-menu:*`\n  - `prettier:*`\n  - `spaces:*`\n  - `theme:*`\n\n## Good Boundaries\n\n- Renderer формирует intent и payload.\n- Main/API работает с данными приложения, файловой системой и system APIs.\n- Ответ возвращается обратно в renderer в виде DTO или IPC result, а не через shared mutable backend module.\n\n## Common Mistakes\n\n- Тянуть backend-модуль напрямую в renderer ради “удобства”.\n- Менять DTO/route без `pnpm api:generate`.\n- Добавлять system/file behavior в renderer вместо IPC handler.\n- Добавлять новые `db:*` flows там, где задача должна идти через текущую API/IPC модель приложения.\n- Создавать ad-hoc каналы, которые не укладываются в существующие channel families.\n",".agents/skills/github-workflow/SKILL.md":"---\nname: github-workflow\ndescription: Use when working with massCode issues, branches, commits, pull requests, or merge preparation in GitHub.\n---\n\n# github-workflow\n\n## Issue\n\nЕсли работа идёт по issue, читать его через `gh`:\n\n```bash\ngh issue view <number> -R massCodeIO/massCode\n```\n\nЕсли issue описывает bug, не считай его автоматически подтверждённым.\n\nСначала:\n\n1. понять ожидаемое поведение;\n2. проверить текущее поведение в коде или воспроизвести проблему;\n3. подтвердить bug или явно зафиксировать, что он не подтверждается;\n4. только после этого переходить к ветке, фиксу и PR.\n\nЕсли bug не воспроизводится или issue описан неясно:\n\n- не начинать слепую реализацию;\n- сначала сообщить, что проблема не подтверждена, и уточнить условия или шаги воспроизведения.\n\n## Branch\n\nСоздавай ветку от `main` с префиксом по типу изменения (`feat/`, `fix/`, `chore/`, `refactor/`) и коротким описанием. Если работа идёт по issue — уместно добавить номер в конец.\n\n```bash\ngit checkout main && git pull\ngit checkout -b feat/<short-description> main\n```\n\n## PR\n\nЗаголовок PR — conventional commits:\n\n```text\ntype: description\n```\n\nПеред созданием PR предложи заголовок пользователю на подтверждение.\n\nЕсли PR закрывает существующий issue, в описании добавляй:\n\n```text\ncloses #123\n```\n\nПеред PR убедись, что релевантные проверки и тесты для затронутой области действительно прогнаны.\n\nСоздание:\n\n```bash\ngh pr create \\\n  --base main \\\n  --head <branch-name> \\\n  --title \"type: description\" \\\n  --body \"closes #<issue_number>\" \\\n  --assignee @me\n```\n\nЕсли issue нет — в `--body` кратко опиши суть изменений без служебного AI-хвоста.\n\nПосле создания PR предложи пользователю смерджить его в `main`:\n\n```bash\ngh pr merge <pr_number> -R massCodeIO/massCode --squash --delete-branch\n```\n\nПосле merge синхронизируй локальную ветку:\n\n```bash\ngit checkout main && git pull\ngit branch -d <branch-name>\n```\n\n## Commit\n\n- Только однострочный заголовок conventional commit.\n- Используй подходящий scope для коммитов и PR (`feat(notes):`, 'fix(math):).\n- Без тела, без `Co-Authored-By`.\n",".agents/skills/release-notes/SKILL.md":"---\nname: release-notes\ndescription: Use when generating massCode release notes for a GitHub release. Writes the notes to a gitignored file `docs/releases/<tag>.md` for the user to paste into the GitHub release. Use when summarizing merged PRs of a version into a consistent release notes structure.\n---\n\n# Release Notes\n\n## Overview\n\nЭтот skill генерирует release notes одного релиза `vX.Y.Z` для вставки в GitHub release. Цель — единая повторяемая структура от релиза к релизу.\n\nНе трогай `docs/website/download/latest-release.md` — это отдельная repo-страница со своим форматом.\n\n## Source Of Truth\n\n- Содержимое выводи из merged PR между предыдущим и новым тегом, не из памяти.\n- Список изменений бери так:\n  `git log --first-parent --oneline <prev-tag>..<new-tag>` (например `v5.5.0..v5.6.0`).\n- Если новый тег ещё не создан, используй `<prev-tag>..HEAD` и спроси/подтверди номер новой версии.\n- Поведение значимых фич проверяй в коде или в `docs/website/documentation`, прежде чем формулировать, если оно неочевидно из заголовка PR.\n\n## Output\n\n- Записывай результат в файл `docs/releases/<new-tag>.md` (например `docs/releases/v5.6.0.md`). Папка `docs/releases` в `.gitignore`, это рабочий буфер, а не часть репозитория.\n- Пиши именно в файл, а не выводом в терминал: так пользователь копирует чистый markdown без переносов строк, которые добавляет терминал.\n- После записи коротко сообщи путь к файлу и при необходимости покажи итог. Не коммить файл.\n\n## Format\n\nФайл содержит один markdown-блок в этой структуре и порядке:\n\n```\n## <Feature Name>\n\n<1-2 абзаца: что это и что даёт пользователю.>\n\n## <Another Feature Name>\n\n<1-2 абзаца.>\n\n## Workflow Improvements\n\n- <мелкое улучшение>\n- <мелкое улучшение>\n\n## Fixes\n\n- <исправление>\n- <исправление>\n\n**Full Changelog**: https://github.com/massCodeIO/massCode/compare/<prev-tag>...<new-tag>\n```\n\nПравила структуры:\n\n- Начинай прямо с тематических `##`-разделов. Не добавляй заголовок версии `# vX.Y.Z` (его даёт сам GitHub release), frontmatter или `<AssetsDownload />` — это артефакты repo-страницы.\n- Один `##`-раздел на каждую значимую фичу или связную группу фич.\n- `## Workflow Improvements` и `## Fixes` включай только если для них есть содержимое.\n- Compare-ссылка всегда последней строкой, с актуальными предыдущим и новым тегами.\n\n## What To Include\n\n- User-facing изменения: новые spaces и фичи, заметные улучшения workflow, видимые исправления.\n- Крупную фичу выноси в отдельный `##`-раздел с 1-2 абзацами о пользе для пользователя.\n- Мелкие улучшения собирай в `## Workflow Improvements` буллетами.\n- Исправления собирай в `## Fixes` буллетами, по одному на исправление.\n\n## What To Omit\n\n- Чисто внутренние коммиты: `ci`, `build`, `chore`, рефакторинг, bump зависимостей, релизные служебные коммиты (`build: release vX.Y.Z`).\n- Исключение: выноси платформенные изменения, заметные пользователю (например code signing и notarization на macOS), в `## Workflow Improvements`.\n- Не описывай детали реализации; пиши о результате для пользователя.\n\n## Writing Style\n\n- Английский, спокойный фактический тон. Что делает фича и зачем она пользователю, без маркетинговых превосходных степеней.\n- Никаких em dash. Это общее правило репозитория.\n- Имена spaces пиши консистентно: `Code`, `Notes`, `Math Notebook`, `Drawings`, `HTTP`, `Tools`. Не смешивай `Code` и `Snippets` как имя пространства.\n- `snippet` — единица контента внутри пространства Code, а не имя пространства. В Fixes допустимо «snippet fences», «snippet sync», но пространство всё равно называется Code.\n- Code identifiers, расширения файлов и токены оборачивай в backticks (`` `.excalidraw` ``, `` `@` ``, `` `Esc` ``).\n- Shortcuts указывай как в интерфейсе; macOS и Windows/Linux варианты различай, если они отличаются.\n\n## Common Mistakes\n\n- Перечислять коммиты дословно вместо группировки в user-facing разделы.\n- Включать `ci` / `build` / `chore` шум, который не виден пользователю.\n- Добавлять `# vX.Y.Z`, frontmatter или `<AssetsDownload />` (это формат repo-страницы, а не GitHub release).\n- Выводить нотис простыней в терминал вместо файла `docs/releases/<new-tag>.md` (терминал ломает переносы строк при копировании).\n- Коммитить файл из `docs/releases` — это игнорируемый рабочий буфер.\n- Смешивать имена пространств (`Code` против `Snippets`) внутри одного документа.\n- Описывать детали реализации вместо пользы для пользователя.\n- Забыть обновить compare-ссылку на актуальные теги.\n- Использовать em dash вопреки правилу репозитория.\n",".agents/skills/spaces-architecture/SKILL.md":"---\nname: spaces-architecture\ndescription: Use when working on massCode spaces such as code, notes, math, or tools, especially when changing their state, behavior, synchronization, or spaces IPC channels.\n---\n\n# Spaces Architecture\n\n## Overview\n\nmassCode использует систему Spaces для разделения функциональных областей. Это не просто UI tabs: у каждого space есть собственное состояние, свои правила обновления и свой способ синхронизации с данными в vault.\n\n## Space Model\n\n- `code` — snippets, folders, tags\n- `notes` — notes, folders, tags, markdown-based flows\n- `math` — calculation sheets и состояние math notebook\n- `tools` — developer utilities\n\nОсновные определения живут в `src/renderer/spaceDefinitions.ts`.\n\n## Space State Storage\n\n- Состояние каждого space хранится в `__spaces__/{spaceId}/.state.yaml` внутри vault.\n- Runtime helpers:\n  - `src/main/storage/providers/markdown/runtime/spaces.ts`\n  - `src/main/storage/providers/markdown/runtime/spaceState.ts`\n- Директория `__spaces__/` — служебная часть vault для состояния spaces.\n\n## Persistence Rules\n\n- Запись состояния spaces использует ту же debounce/flush инфраструктуру, что и `state.json`.\n- Не ломай совместимость с `pendingStateWriteByPath` и flush-on-exit поведением.\n- Если меняешь способ записи, учитывай сценарий завершения приложения до явного ручного flush.\n\n## IPC Rules\n\n- Space-specific IPC handlers живут в `src/main/ipc/handlers/spaces.ts`.\n- Текущие math handlers:\n  - `spaces:math:read`\n  - `spaces:math:write`\n- Если добавляется новый `spaces:*` flow, он должен работать через общую модель состояния spaces, а не в обход неё.\n\n## Space-Aware Sync\n\n- `system:storage-synced` обновляет активное пространство через `getActiveSpaceId()`.\n- Ожидаемое поведение:\n  - `code` → refresh folders + snippets\n  - `notes` → refresh notes + note folders\n  - `math` → `reloadFromDisk()` через `useMathNotebook()`\n  - `tools` → no-op\n- Изменения, которые уже сохранены в vault, должны вызывать `markPersistedStorageMutation()`, чтобы не создавать sync loops.\n\n## Common Mistakes\n\n- Считать spaces только UI-концепцией и забывать, что у них есть собственное состояние и правила синхронизации.\n- Писать состояние space в обход общих markdown runtime helpers.\n- Добавлять mutation без `markPersistedStorageMutation()`.\n- Ломать согласованность между состоянием space, helpers и sync behavior.\n",".agents/skills/ui-foundations/SKILL.md":"---\nname: ui-foundations\ndescription: Use when defining or reviewing massCode UI foundation rules such as typography, renderer styling consistency, TailwindCSS v4 usage, and when raw markup starts competing with established UI text patterns.\n---\n\n# UI Foundations\n\n## Overview\n\nUI в massCode должен оставаться визуально консистентным. Этот skill отвечает за базовые styling decisions: как относиться к typography, когда использовать established text patterns и как не скатываться в разрозненный renderer styling.\n\n## Core Rules\n\n- Базовая styling system в renderer строится на TailwindCSS v4.\n- Новые UI-экраны и состояния должны продолжать существующий visual language, а не вводить локальные правила “для одного места”.\n- Для стандартного app UI предпочитай семантические токены вроде `bg-background`, `text-muted-foreground`, `border-border`, `border-destructive/*` вместо raw palette-классов вроде `bg-white`, `text-black`, `text-green-500`, `bg-slate-900`.\n- Typography по умолчанию строится через `UiText`.\n- Не заменяй `UiText` на произвольный набор `text-*`, `font-*`, `text-muted-foreground`, если подходящий variant уже существует.\n- Если `UiText` почти подходит, лучше добавить точечные классы поверх него, чем уходить в raw typography markup.\n\n## Typography\n\n- `UiText` — базовый источник правды для текстовых размеров и muted-state.\n- `caption` и `xs` — подписи, helper text, secondary labels.\n- `sm` и `base` — основной интерфейсный текст.\n- `lg` и `xl` — усиленные title/value cases, когда это действительно нужно по hierarchy.\n- `font-mono` — только для code-like content, IDs, counts with alignment needs, readonly generated output и подобных случаев.\n- Для uppercase labels используй существующий pattern через `UiText` или согласованный tracking/uppercase стиль, а не случайную смесь utility classes в каждом месте.\n\n## Spacing And Layout Rhythm\n\n- Корневые screen/container wrappers обычно живут в ритме `space-y-4` или `space-y-6`.\n- Внутри компактных секций чаще всего `space-y-2` или `space-y-3`.\n- Grid gaps по умолчанию: `gap-2`, `gap-3`, `gap-4` в зависимости от плотности.\n- Не придумывай локальный spacing-scale для одного экрана, если существующие интервалы уже покрывают задачу.\n- Повторяющиеся content blocks должны иметь одинаковый padding и vertical rhythm.\n\n## Radius And Shadows\n\n- `rounded-md` — controls, inline boxes, compact containers.\n- `rounded-lg` — card-like blocks, dialogs, overlays, dashboard sections.\n- `rounded-xl` — preview-heavy surfaces и крупные visual blocks.\n- `rounded-full` — pills, badges, circular handles.\n- `shadow-xs` — inputs, buttons, small controls.\n- `shadow-md` и `shadow-lg` — overlays, popovers, previews, где elevation реально нужна.\n- Не вводи произвольные `rounded-[...]` и `shadow-[...]`, если стандартные токены уже подходят.\n\n## Exceptions\n\n- Raw colors допустимы, если цвет является частью самих данных или preview:\n  color pickers, contrast previews, code/image export backgrounds, diagram or visualizer nodes.\n- Если цвет вычисляется из контента или нужен для корректного контраста на пользовательском фоне, raw class или inline style допустимы.\n- Исключения не должны становиться поводом тащить raw palette в обычный application chrome.\n\n## When To Prefer This Skill\n\n- Нужно понять, как оформлять текст и подписи в новом UI.\n- Есть соблазн писать raw Tailwind typography вместо существующего text pattern.\n- В экране начинают появляться локальные styling rules, которые расходятся с остальным renderer UI.\n- Нужно принять решение на уровне визуальной базы, а не конкретного button/input/dialog.\n\n## Common Mistakes\n\n- Размазывать локальные визуальные исключения по фичам.\n- Тащить raw palette в обычный app UI без реальной причины.\n- Писать текст напрямую через произвольные utility classes там, где подходит `UiText`.\n- Делать новый экран со своим spacing rhythm вместо существующего scale.\n- Случайно смешивать small-control radii и preview-surface radii в одном и том же UI слое.\n- Считать Tailwind поводом делать каждый экран визуально “с нуля”.\n",".agents/skills/ui-primitives/SKILL.md":"---\nname: ui-primitives\ndescription: Use when building or refactoring massCode UI components with local Ui primitives or Shadcn, especially for cn, cva, notifications, and rules against reimplementing basic controls.\n---\n\n# UI Primitives\n\n## Overview\n\nБазовые UI-элементы в massCode должны собираться из существующих `Ui*` компонентов и Shadcn-паттернов. Этот skill отвечает за component-level usage rules, а не за общую визуальную базу.\n\n## Component Usage\n\n- Локальные UI-компоненты доступны через auto-import с префиксом `Ui`.\n- Базовые элементы вроде button, input, checkbox, action button не переизобретай на сыром HTML, если есть готовый `Ui*` вариант.\n- Если нужного элемента нет, сначала создай его в `src/renderer/components/ui/`, потом используй в фиче.\n\n## Buttons\n\n- Primary action должен быть явным и не конкурировать с несколькими равноправными CTA в одном контейнере.\n- Icon-only actions должны быть понятны по контексту и иметь tooltip или другой доступный label path.\n- Loading и pending actions должны использовать существующий button pattern, а не ad-hoc “disabled text swap”.\n- Destructive actions не должны выглядеть как обычные secondary controls.\n\n## Cards And Containers\n\n- Для автономных panel-like блоков используй существующий `Card` / `Ui*` container pattern, если он уже есть в области.\n- Внутренние muted blocks не нужно пересобирать разными `div`-паттернами в каждой фиче.\n- Repeated panel structure должна переезжать в shared primitive или local feature primitive, а не копироваться markup-в-маркап.\n\n## Readonly And Copyable Content\n\n- Длинный readonly output, generated text, URLs и similar content не показывай как “обычный disabled input”, если это ухудшает чтение.\n- Для copy flows используй существующий copy pattern и уведомления через `useSonner()`.\n- Readonly content должен оставаться визуально читаемым и удобно копируемым.\n\n## Styling Helpers\n\n- Для variants используй `cva`.\n- Для склейки классов используй `cn()`.\n- Не делай variants вручную строковыми `if`-цепочками там, где нужен нормальный variant API.\n\n## Shadcn Rules\n\n- Shadcn-компоненты импортируй вручную из `@/components/ui/shadcn/*`.\n- Для namespace-based компонентов используй паттерн вроде `import * as Dialog from '@/components/ui/shadcn/dialog'`.\n\n## Notifications\n\n- Для уведомлений используй `useSonner()`.\n- Не добавляй локальную, параллельную систему toast/notification внутри фичи.\n\n## Tooltip, Popover, Overlay\n\n- Tooltip — для короткого пояснения.\n- Popover — для richer inline content, picker-like content или contextual controls.\n- Не заменяй их ad-hoc overlay-разметкой без необходимости.\n- Validation и inline guidance должны использовать существующие tooltip/popover primitives, если проект уже их применяет в аналогичных местах.\n\n## Dialog Focus\n\n- Во всех диалогах явно управляй фокусом при открытии и закрытии. Не допускай автоматического фокуса на крестике закрытия и появления tooltip на кнопке открытия из-за возврата фокуса после закрытия.\n- По умолчанию отменяй стандартный autofocus на `DialogContent`:\n\n  ```vue\n  @open-auto-focus=\"(e) => e.preventDefault()\"\n  @close-auto-focus=\"(e) => e.preventDefault()\"\n  ```\n\n- Исключение — намеренный фокус на конкретном поле или действии, нужном для сценария диалога. Задавай такую цель явно; при закрытии выбирай цель возврата фокуса без побочного показа tooltip.\n- Сохраняй focus trap и клавиатурную навигацию. Проверяй открытие и закрытие мышью и клавиатурой, включая Escape.\n\n## Common Mistakes\n\n- Писать ещё одну кнопку или input с нуля “потому что быстрее”.\n- Склеивать сложные conditional classes без `cn()`.\n- Дублировать существующий primitive внутри feature directory вместо общего `src/renderer/components/ui/`.\n- Использовать disabled input как универсальный readonly display surface.\n- Делать overlay pattern вручную там, где уже есть Shadcn primitive.\n- Смешивать правила primitives с вопросами визуальной базы, которые должны идти в `ui-foundations`.\n",".agents/skills/vue-renderer-standards/SKILL.md":"---\nname: vue-renderer-standards\ndescription: Use when editing massCode renderer code in Vue 3, especially for script setup patterns, import rules, composables, shared state, and renderer-side conventions.\n---\n\n# Vue Renderer Standards\n\n## Overview\n\nRenderer в massCode строится на Vue 3 Composition API с `<script setup lang=\"ts\">`. Здесь важны строгие import rules, composable-first state sharing и запрет на прямой доступ к backend-возможностям.\n\n## Component Pattern\n\n- Используй Vue 3 Composition API и `<script setup lang=\"ts\">`.\n- Vue core (`ref`, `computed`, `watch`, `onMounted` и подобные) не импортируй вручную: они auto-imported.\n- Проектные компоненты из `src/renderer/components/` тоже не импортируй вручную: они auto-imported.\n- Локальную логику компонента держи в script, а не в template.\n\n## Manual Imports Only Where Required\n\nВсегда импортируй вручную:\n\n- composables из `@/composables`;\n- utils из `@/utils`;\n- `@vueuse/core`;\n- Electron bridge из `@/electron`;\n- Shadcn UI из `@/components/ui/shadcn/*`.\n\n## Shared State\n\n- Глобальное shared state реализуется composables без Pinia/Vuex.\n- Reactive state, который должен шариться между компонентами, объявляй на module level, вне экспортируемой функции composable.\n- Persistent UI/settings state храни через `store` из `@/electron`:\n  - `store.app` для UI state;\n  - `store.preferences` для user preferences.\n\n## VueUse First\n\n- Перед написанием нового composable сначала проверь, нет ли подходящего решения в `@vueuse/core`.\n- Кастомный composable добавляй только если готового utility реально нет.\n\n## Renderer Boundaries\n\n- Renderer не импортирует storage internals или backend-модули доступа к данным напрямую.\n- Renderer не обращается напрямую к Node.js, filesystem или storage runtime.\n- Доступ к main process возможен только через `api` или `ipc`.\n\n## Common Mistakes\n\n- Ручной импорт `ref` / `computed` / `watch`.\n- Ручной импорт локальных project components.\n- Локальный state внутри composable, который должен быть общим между несколькими компонентами.\n- Попытка “срезать путь” и импортировать backend-модуль прямо в renderer.\n","AGENTS.md":"# Точка входа для агента massCode\n\nОтвечай всегда на русском.\n\nmassCode — это приложение на Electron + Vue 3 + TypeScript с TailwindCSS v4 в renderer, API-маршрутами на Elysia в main process, markdown vault как основным хранилищем пользовательского контента в v5 и `store.app` / `store.preferences` для локального UI state и настроек.\n\n## Всегда действующие правила\n\n- Следуй YAGNI. Предпочитай минимальную корректную реализацию вместо спекулятивных абстракций.\n- Соблюдай границы слоёв: renderer не должен напрямую обращаться к Node.js, filesystem или DB. Используй API или IPC.\n- Никогда не хардкодь пользовательские строки. Используй систему локализации.\n- Не запускай lint или тесты по всему проекту для локальной задачи. Ограничивай команды затронутыми файлами или директориями.\n- После изменений API DTO или routes запускай `pnpm api:generate`.\n- После изменений locale-файлов запускай `pnpm i18n:copy`.\n- Если задача совпадает по теме с одним из skills ниже, загружай этот skill до внесения изменений.\n\n## Skills\n\n- `.agents/skills/architecture-standards/SKILL.md`\n  Используй первым для общих правил репозитория: архитектура, naming, декомпозиция и выбор следующего skill.\n- `.agents/skills/vue-renderer-standards/SKILL.md`\n  Используй для работы с Vue renderer: `<script setup lang=\"ts\">`, правила auto-import, composables, shared state и renderer-side паттерны.\n- `.agents/skills/ui-foundations/SKILL.md`\n  Используй для базовых UI-правил: Tailwind v4, typography через `UiText` и согласованных styling decisions для renderer UI.\n- `.agents/skills/ui-primitives/SKILL.md`\n  Используй для component-level UI работы: `Ui*` components, Shadcn imports, `cn`, `cva`, notifications и правил против переизобретения primitives.\n- `.agents/skills/electron-api-and-ipc/SKILL.md`\n  Используй для API routes, DTO, IPC handlers, renderer-to-main communication и границ Electron-интеграции.\n- `.agents/skills/api-and-typing/SKILL.md`\n  Используй для generated API types, DTO-derived renderer typing и решения, когда локальный UI type оправдан, а когда нужно переиспользовать существующие API types.\n- `.agents/skills/spaces-architecture/SKILL.md`\n  Используй при изменениях, связанных с `code` / `notes` / `math` / `tools`, markdown-space state, sync behavior или `spaces:*` IPC.\n- `.agents/skills/i18n/SKILL.md`\n  Используй для правил локализации, размещения locale keys, `i18n.t(...)` и требования не хардкодить строки.\n- `.agents/skills/documentation-workflow/SKILL.md`\n  Используй для добавления или обновления документации, страниц `docs/website/documentation`, sidebar, assets и README-упоминаний фич.\n- `.agents/skills/release-notes/SKILL.md`\n  Используй для генерации release notes нового релиза в игнорируемый файл `docs/releases/<tag>.md` для вставки в GitHub release: группировка merged PR в user-facing разделы и compare-ссылка.\n- `.agents/skills/development-workflow/SKILL.md`\n  Используй для repo-specific workflow rules: scoped lint/test команды и обязательные follow-up шаги после изменений source-of-truth файлов.\n- `.agents/skills/github-workflow/SKILL.md`\n  Используй для massCode git и GitHub workflow: issue, ветки, commits, PR и подготовки к merge.\n\n## Рекомендуемый порядок загрузки\n\n- Широкая или неочевидная задача: начни с `architecture-standards`, затем загрузи профильный skill.\n- Renderer UI задача: `architecture-standards` → `vue-renderer-standards` → `ui-foundations` → `ui-primitives`.\n- API / IPC / Electron задача: `architecture-standards` → `electron-api-and-ipc`.\n- Generated types / renderer typing задача: `architecture-standards` → `api-and-typing`.\n- Spaces задача: `architecture-standards` → `spaces-architecture`.\n- Задача про текст и локализацию: `i18n`.\n- Задача про документацию или README: `documentation-workflow`.\n- Задача про release notes нового релиза: `release-notes`.\n- Workflow-чувствительная задача: `development-workflow`.\n- Задача про git / branch / commit / PR: `github-workflow`.\n\n## Основной стек\n\n- Framework: Vue 3, Composition API, `<script setup lang=\"ts\">`\n- Styling: TailwindCSS v4, `tailwind-merge`, `cva`\n- UI: локальные `src/renderer/components/ui`, Shadcn поверх `reka-ui`, `lucide-vue-next`\n- State: composables, без Pinia/Vuex\n- Backend: Electron main, Elysia API, markdown vault для контента и `electron-store` для локального состояния приложения\n- Utilities: `@vueuse/core`, `vue-sonner`\n","CLAUDE.md":"AGENTS.md","docs/website/documentation/tools/index.md":"---\ntitle: Overview\ndescription: \"Use built-in developer tools in massCode for JSON diffing, text conversion, hashing, HMAC generation, URL parsing, and other quick tasks.\"\n---\n\n# Tools overview\n\nTools is for the small developer tasks that should take seconds, not a trip to a random website. Use it when you need to compare JSON, convert, encode, hash, or generate something quickly without leaving massCode.\n\nThe available tools are grouped by category:\n\n## Compare\n\n### [JSON Diff](/documentation/tools/json-diff)\n\nCompare two JSON documents side by side with validation, filters, and a tree diff for nested changes.\n\n## Text tools\n\n### Case Converter\n\nConvert text between common casing formats such as camelCase, snake_case, kebab-case, and uppercase.\n\n### Slug Generator\n\nTurn free-form text into a URL-friendly slug.\n\n### URL Parser\n\nSplit a URL into its protocol, host, path, query, and hash parts.\n\n### Line Break Normalizer\n\nRemove hard wraps from copied terminal output while preserving Markdown lists, tables, quotes, commands, and code blocks. The same normalization is available from the **Editor** menu in Code and Notes.\n\n## Cryptography & Security\n\n### Hash Generators\n\nGenerate one-way hashes from text input.\n\n### HMAC Generators\n\nBuild keyed message authentication hashes from a secret and a message.\n\n### Password Generators\n\nGenerate random passwords with configurable character sets.\n\n### UUID Generators\n\nCreate unique identifiers for fixtures, payloads, and test data.\n\n## Encoders & Decoders\n\n### URL\n\nEncode or decode URL strings safely.\n\n### Base64\n\nConvert plain text to and from Base64.\n\n### JSON ⇄ TOML/XML/YAML\n\nTransform JSON between common structured data formats.\n\n### Text ⇄ ASCII/Binary/Unicode\n\nConvert text into different low-level or escaped representations and back.\n\n### Color Converter\n\nTranslate color values between supported formats.\n\n## Generators\n\n### JSON Generator\n\nBuild mock JSON payloads with typed fields for testing and demos.\n\n### Lorem Ipsum Generator\n\nGenerate placeholder words, sentences, or paragraphs.\n","docs/website/documentation/tools/json-diff.md":"---\ntitle: JSON Diff\ndescription: \"Compare two JSON documents side by side in massCode with validation, filters, and a tree diff.\"\n---\n\n# JSON Diff\n\nJSON Diff lets you compare two JSON documents side by side without leaving massCode. It is useful for checking API responses, fixture changes, configuration edits, and generated JSON payloads.\n\n## Where to find it\n\nOpen **Tools** in the left rail, then go to **Compare** → **JSON Diff**.\n\n## What it does\n\n- Shows the original and modified JSON in two editors\n- Validates each side independently\n- Formats valid JSON on paste and blur\n- Builds a tree-based diff for nested objects and arrays\n- Highlights added, removed, and modified values\n- Filters the diff by change type\n- Keeps both input editors scrolled in sync\n- Uses the same editor font settings as the main code editor\n\n## How to use it\n\n1. Paste the original JSON into the left editor.\n2. Paste the modified JSON into the right editor.\n3. Review the diff tree below the editors.\n4. Use the checkboxes to focus on added, removed, or modified nodes.\n5. Expand or collapse nested objects and arrays as needed.\n\n## Notes\n\n- Both inputs must contain valid JSON before the diff viewer appears.\n- Validation errors are shown under each editor separately.\n- If only one side is filled, the tool stays in the empty state instead of guessing missing data.\n- Array move visualization is not exposed as a separate state. In this version, the tool prefers predictable output over compact move semantics.\n"},"files":{".agents/skills/api-and-typing/SKILL.md":"---\nname: api-and-typing\ndescription: Use when defining or reviewing massCode renderer types that come from generated API clients or DTOs, especially when deciding whether to reuse existing API shapes, derive narrower local types, or introduce a UI-only model.\n---\n\n# API And Typing\n\n## Overview\n\nДля massCode API types считаются generated-first. Если данные пришли из `~/renderer/services/api/generated` или соответствуют DTO из `src/main/api/dto`, сначала используй существующие типы и utility typing, а не придумывай новый interface рядом с компонентом.\n\n## Core Rules\n\n- Ручные дубли API response types не пиши.\n- Сначала ищи тип в `~/renderer/services/api/generated`.\n- Если прямого export нет, выводи нужный shape через `Pick`, `Omit`, indexed access, `Parameters`, `ReturnType`, `Awaited`, `NonNullable`.\n- Локальный тип допустим только как UI-only model, form model, derived display model или narrow type после нормального data narrowing.\n\n## Good Uses Of Local Types\n\n- Узкий renderer shape после того, как nullable API data уже очищена в одном месте.\n- View-model для dashboard card, graph node, readonly row или editor-side helper, если он не равен transport shape.\n- Тип аргумента, выводимый из существующего composable или API method через `Parameters` / `ReturnType`.\n\n## Bad Uses Of Local Types\n\n- Полный дубль `SnippetsResponse`, `NotesDashboardResponse`, `TagsResponse` и других generated types.\n- Новый interface “для удобства”, если можно взять одну ветку из existing response type.\n- Копирование DTO shape в renderer file, хотя он уже импортируемый.\n\n## Common Mistakes\n\n- Сначала придумать локальный interface, а потом уже искать generated type.\n- Смешать transport shape и UI view-model без явного adapter step.\n- Тащить глубоко в UI сырые nullable API поля вместо одного нормального normalization place.\n",".agents/skills/architecture-standards/SKILL.md":"---\nname: architecture-standards\ndescription: Use when working in massCode and you need repo-wide architecture rules, naming conventions, decomposition boundaries, or guidance on which massCode skill to load next.\n---\n\n# Architecture Standards\n\n## Overview\n\nБазовый принцип проекта: **YAGNI и простота прежде всего**. Не усложняй код ради гипотетических сценариев, не строй абстракции без повторяющейся потребности и не размывай границы между renderer, API и main.\n\n## Core Rules\n\n- Соблюдай разделение слоёв:\n  - Renderer: только UI, composables, вызовы `api.*` и `ipc.invoke(...)`.\n  - API: маршруты Elysia, DTO, orchestration и доступ к сервисам и данным приложения.\n  - Main: системные интеграции, IPC handlers, lifecycle и слой данных приложения.\n- Data flow по умолчанию: Renderer → API / IPC → service / data layer → response.\n- Vue-компоненты называй в `PascalCase`.\n- TypeScript-файлы называй в `camelCase`.\n- Composables именуй с префиксом `use`, а имя файла должно совпадать с экспортируемой функцией.\n\n## YAGNI Guardrails\n\nПризнаки overengineering:\n\n- функция страхуется от кейса, которого реально не существует;\n- factory или wrapper используется ровно в одном месте и не скрывает состояние;\n- abstraction-for-abstraction без повторяющейся боли;\n- константы, паттерны и конфигурации придуманы заранее, а не из реальной потребности.\n\n## Component Decomposition\n\n- Если компонент становится больше примерно `300` строк или держит `3+` несвязанных обязанности, дели его.\n- Порядок разбиения:\n  1. вынеси константы и статические данные;\n  2. вынеси чистые функции в utils, только если это реально переиспользуется;\n  3. перемести состояние и эффекты в composable;\n  4. разбей шаблон на локальные child components.\n- Не держи в `<template>` логику сложнее тернарного оператора.\n\n## Feature Subdirectories\n\n- Если часть домена выросла в отдельный subsystem, группируй локальные компоненты, helpers, tests и fixtures в поддиректорию.\n- Внутри поддиректории не повторяй полный родительский префикс в именах файлов.\n- Локальные файлы держи рядом с фичей. Shared-код, который нужен нескольким областям, оставляй выше уровнем.\n\n## When to Load Other Skills\n\n- Vue renderer, auto-imports, composables, shared state:\n  `vue-renderer-standards`\n- визуальная база, typography, renderer styling decisions:\n  `ui-foundations`\n- `Ui*`, Shadcn, `cn`, `cva`, notifications:\n  `ui-primitives`\n- API routes, DTO, IPC, Electron boundaries:\n  `electron-api-and-ipc`\n- generated API types, utility typing, локальные view-model:\n  `api-and-typing`\n- `code` / `notes` / `math` / `tools`, состояние spaces и их синхронизация:\n  `spaces-architecture`\n- i18n, locale keys, `i18n.t(...)`:\n  `i18n`\n- docs website, docs sidebar, скриншоты, README-упоминания фич:\n  `documentation-workflow`\n- scoped lint/test и follow-up commands:\n  `development-workflow`\n\n## Common Mistakes\n\n- Тянуть DB или filesystem knowledge в renderer.\n- Раздувать один компонент до “оркестратора всего”.\n- Выносить абстракцию до появления второй реальной точки использования.\n- Размазывать одну фичу по плоской структуре файлов, когда ей уже нужен локальный subdirectory.\n- Придумывать локальные typing-паттерны, хотя для них уже пора иметь отдельный skill.\n",".agents/skills/development-workflow/SKILL.md":"---\nname: development-workflow\ndescription: Use when following massCode repo workflow rules, especially for scoped lint and test commands, or when changes require required follow-up commands like code generation or locale sync.\n---\n\n# Development Workflow\n\n## Overview\n\nВ massCode workflow rules считаются частью качества изменений. Для локальной задачи команды должны быть точечными, а изменения source-of-truth файлов должны сопровождаться обязательными follow-up шагами.\n\n## Linting Rules\n\n- Всегда запускай lint только по затронутым файлам или директориям.\n- Никогда не запускай lint по всему проекту во время локальной задачи.\n- Используй scoped commands вроде:\n  - `pnpm lint <path>`\n  - `pnpm lint:fix <path>`\n\n## Testing Rules\n\n- Всегда запускай тесты только по затронутым файлам или директориям.\n- Никогда не запускай весь test suite без явной необходимости.\n- Используй scoped commands вроде:\n  - `pnpm test <path>`\n  - `pnpm test:watch <path>`\n\n## Required Follow-Up Commands\n\n- Изменил API DTO/routes → `pnpm api:generate`\n- Изменил locale-файлы → `pnpm i18n:copy`\n\n## Common Mistakes\n\n- Прогонять весь lint/test suite для маленькой точечной правки.\n- Менять source-of-truth файлы и забывать generation/sync шаг.\n- Запускать “на всякий случай” широкие команды вместо минимального релевантного набора.\n",".agents/skills/documentation-workflow/SKILL.md":"---\nname: documentation-workflow\ndescription: Use when adding or updating massCode documentation, documenting a new feature, changing docs website pages, adding docs assets, updating the VitePress sidebar, or adding README feature mentions.\n---\n\n# Documentation Workflow\n\n## Overview\n\nДокументация massCode живёт в VitePress сайте в `docs/website/documentation`. README — это общий обзор проекта, а не источник детального описания фич.\n\n## Documentation Surfaces\n\n- Документация фич: `docs/website/documentation/**`\n- Sidebar документации: `docs/website/.vitepress/config.mts`\n- Assets документации: `docs/website/public/**`\n- Overview документации: `docs/website/documentation/index.md`\n- Overview проекта: `README.md`\n\n## Core Rules\n\n- Проверяй поведение фичи в коде или существующей документации; не документируй по памяти.\n- Используй `rg`, чтобы найти связанные страницы, скриншоты, shortcuts, labels и существующие формулировки.\n- Если целевая версия известна, используй именно её. Если версия неизвестна, не придумывай её.\n- Пользовательская документация сайта пишется на английском, в стиле существующих docs pages.\n- Добавляй или обновляй наиболее конкретную страницу в `docs/website/documentation`.\n- Для новых страниц используй frontmatter с `title` и `description`.\n- Добавляй страницу в `docs/website/.vitepress/config.mts` только если она должна появиться в навигации.\n- Ссылайся из `docs/website/documentation/index.md` только на широкие, cross-cutting фичи.\n- Пиши короткими task-oriented секциями. Предпочитай пользовательские флоу, а не детали реализации.\n- Shortcuts документируй через `<kbd>...</kbd>` и указывай macOS плюс Windows/Linux варианты, если они отличаются.\n\n## Version Availability\n\n- Перед добавлением или изменением `<AppVersion>` проверяй историю фичи в коде, документации или предыдущем релизном теге.\n- Считай `<AppVersion text=\">=x.y\" />` минимальной версией, где появилась ровно описываемая возможность, а не версией её последнего улучшения.\n- Ставь marker на уровне страницы или общего раздела только когда вся описываемая сущность впервые появилась в этой версии.\n- Если новый релиз расширяет существующую фичу, сохраняй её исходный marker или отсутствие marker, а новую версию указывай только у отдельного подпункта или предложения про улучшение.\n- Разделяй смешанное описание на базовую возможность и versioned enhancement, если общий marker создаёт впечатление, что старая возможность раньше была недоступна.\n- Не добавляй version marker для bugfix или внутренней переработки без нового пользовательского сценария. Локально отмечай изменение формата хранения, если оно влияет на совместимость.\n\nПример: если custom folder icons существуют с 3.7, а Emoji и Upload добавлены в 5.9, оставляй `>=3.7` у базовой возможности и ставь `>=5.9` только у подпункта про Emoji и Upload.\n\n## Documentation Weight\n\n- Перед созданием страницы или раздела оцени самостоятельность пользовательского сценария, количество шагов, настроек и ограничений.\n- Описывай мелкое одношаговое действие одной строкой или буллетом внутри существующего релевантного раздела.\n- Создавай отдельный раздел для самостоятельного workflow с несколькими шагами, вариантами, настройками или важными ограничениями.\n- Выбирай одно основное место для подробного описания cross-cutting фичи. В других страницах оставляй короткое упоминание или ссылку вместо повторения полного объяснения.\n- Оставляй bugfix, внутреннюю оптимизацию и implementation detail только в release notes, если они не меняют пользовательский сценарий или требования совместимости.\n\n## Callouts\n\n- Используй `warning` для риска потери данных, несовместимости, необратимого действия или существенного security-ограничения.\n- Используй `info` для автоматической миграции и неочевидного поведения, которое помогает правильно понять основной workflow.\n- Оставляй основные инструкции обычным текстом; callout должен выделять контекст или исключение, а не содержать весь сценарий.\n- Объединяй связанные риски в один callout и избегай нескольких соседних блоков, если их можно прочитать как одно сообщение.\n- Добавляй короткий предметный заголовок, например `::: warning Compatibility` или `::: info Automatic migration`.\n\n## VitePress Markdown Gotchas\n\n- VitePress компилирует markdown как Vue-компонент, поэтому `{{ ... }}` трактуется как Vue-интерполяция и **исчезает** из вывода.\n- Fenced-блоки (` ``` `) защищены автоматически — внутри них `{{var}}` рендерится буквально.\n- **Инлайн-код в backticks НЕ защищён**: `` `{{variables}}` `` отрендерится пустым. Чтобы вывести литеральные двойные фигурные скобки в тексте или таблице, оборачивай в `v-pre`:\n  `<code v-pre>{{variables}}</code>`\n- Это же касается любых других Vue-конструкций (`{{ }}`, директивы) в произвольном тексте страницы.\n\n## Images And Assets Rules\n\n- Картинки для docs клади в `docs/website/public`.\n- Ссылайся на картинки через `withBase`, например:\n  `<img :src=\"withBase('/feature.png')\">`\n- Если страница использует `withBase`, добавь соответствующий script block:\n  `import { withBase } from 'vitepress'`\n- Используй скриншоты только когда они реально объясняют фичу. Не добавляй декоративные изображения.\n\n## README Rules\n\n- Добавляй README-упоминания только для user-facing фич, которые важны на уровне общего обзора проекта.\n- Держи README copy коротким и product-level; подробное использование должно быть в `docs/website/documentation`.\n- Не пиши в README, когда фича была добавлена. Version availability должна жить в docs pages или release notes.\n- Не ставь новую фичу первой автоматически. Сохраняй текущую информационную архитектуру: сначала основные spaces/features, затем широкие workflow helpers, если пользователь не попросил иначе.\n\n## Validation\n\n- Запускай `git diff --check`.\n- Для изменений docs website запускай `pnpm -C docs/website build`.\n- Если нужно форматирование, ограничивай его изменёнными файлами и избегай широкого churn в config-файлах.\n- Не коммить без явной просьбы пользователя. Для commit или PR загружай `github-workflow`.\n\n## Common Mistakes\n\n- Добавлять README-only документацию для фичи, которой нужна настоящая docs page.\n- Забывать VitePress sidebar для новой страницы, которая должна быть в навигации.\n- Добавлять version availability в README.\n- Переносить `<AppVersion>` всего существующего раздела на версию, в которой фича лишь получила улучшение.\n- Создавать отдельный раздел для одношаговой мелкой фичи, которую достаточно упомянуть в существующем разделе.\n- Повторять полное описание cross-cutting фичи на нескольких страницах вместо одного основного места и коротких упоминаний.\n- Использовать callout для обычной инструкции без риска, совместимости или неочевидного поведения.\n- Документировать shortcuts или поведение без проверки реализации.\n- Запускать широкие formatters, которые переписывают существующий стиль docs config.\n- Писать литеральные `{{ ... }}` в инлайн-коде без `v-pre` — VitePress съест их как Vue-интерполяцию.\n",".agents/skills/electron-api-and-ipc/SKILL.md":"---\nname: electron-api-and-ipc\ndescription: Use when changing massCode API routes, DTOs, IPC handlers, Electron bridges, or any renderer-to-main communication and storage-access boundaries.\n---\n\n# Electron API And IPC\n\n## Overview\n\nВсе backend-возможности massCode живут в main process. Renderer получает доступ к данным и системным операциям только через Elysia API или IPC channels.\n\n## Renderer Access Rules\n\n- В renderer для данных используй `import { api } from '~/renderer/services/api'`.\n- В renderer для системных операций используй `ipc.invoke('channel:action', payload)`.\n- Electron API из renderer доступен только через `src/renderer/electron.ts`.\n- Никогда не импортируй storage internals или backend-модули напрямую в renderer.\n\n## New API Endpoints\n\nПри добавлении нового endpoint:\n\n1. создай DTO в `src/main/api/dto/`;\n2. добавь route в `src/main/api/routes/`;\n3. запусти `pnpm api:generate`, чтобы обновить клиент.\n\nНе оставляй API-клиент рассинхронизированным с route/DTO изменениями.\n\n## IPC Conventions\n\n- Для filesystem и system ops используй `ipc.invoke(...)`.\n- Каналы должны укладываться в семейства:\n  - `fs:*`\n  - `system:*`\n  - `db:*` — legacy или migration flows, не основной путь для новой функциональности\n  - `main-menu:*`\n  - `prettier:*`\n  - `spaces:*`\n  - `theme:*`\n\n## Good Boundaries\n\n- Renderer формирует intent и payload.\n- Main/API работает с данными приложения, файловой системой и system APIs.\n- Ответ возвращается обратно в renderer в виде DTO или IPC result, а не через shared mutable backend module.\n\n## Common Mistakes\n\n- Тянуть backend-модуль напрямую в renderer ради “удобства”.\n- Менять DTO/route без `pnpm api:generate`.\n- Добавлять system/file behavior в renderer вместо IPC handler.\n- Добавлять новые `db:*` flows там, где задача должна идти через текущую API/IPC модель приложения.\n- Создавать ad-hoc каналы, которые не укладываются в существующие channel families.\n",".agents/skills/github-workflow/SKILL.md":"---\nname: github-workflow\ndescription: Use when working with massCode issues, branches, commits, pull requests, or merge preparation in GitHub.\n---\n\n# github-workflow\n\n## Issue\n\nЕсли работа идёт по issue, читать его через `gh`:\n\n```bash\ngh issue view <number> -R massCodeIO/massCode\n```\n\nЕсли issue описывает bug, не считай его автоматически подтверждённым.\n\nСначала:\n\n1. понять ожидаемое поведение;\n2. проверить текущее поведение в коде или воспроизвести проблему;\n3. подтвердить bug или явно зафиксировать, что он не подтверждается;\n4. только после этого переходить к ветке, фиксу и PR.\n\nЕсли bug не воспроизводится или issue описан неясно:\n\n- не начинать слепую реализацию;\n- сначала сообщить, что проблема не подтверждена, и уточнить условия или шаги воспроизведения.\n\n## Branch\n\nСоздавай ветку от `main` с префиксом по типу изменения (`feat/`, `fix/`, `chore/`, `refactor/`) и коротким описанием. Если работа идёт по issue — уместно добавить номер в конец.\n\n```bash\ngit checkout main && git pull\ngit checkout -b feat/<short-description> main\n```\n\n## PR\n\nЗаголовок PR — conventional commits:\n\n```text\ntype: description\n```\n\nПеред созданием PR предложи заголовок пользователю на подтверждение.\n\nЕсли PR закрывает существующий issue, в описании добавляй:\n\n```text\ncloses #123\n```\n\nПеред PR убедись, что релевантные проверки и тесты для затронутой области действительно прогнаны.\n\nСоздание:\n\n```bash\ngh pr create \\\n  --base main \\\n  --head <branch-name> \\\n  --title \"type: description\" \\\n  --body \"closes #<issue_number>\" \\\n  --assignee @me\n```\n\nЕсли issue нет — в `--body` кратко опиши суть изменений без служебного AI-хвоста.\n\nПосле создания PR предложи пользователю смерджить его в `main`:\n\n```bash\ngh pr merge <pr_number> -R massCodeIO/massCode --squash --delete-branch\n```\n\nПосле merge синхронизируй локальную ветку:\n\n```bash\ngit checkout main && git pull\ngit branch -d <branch-name>\n```\n\n## Commit\n\n- Только однострочный заголовок conventional commit.\n- Используй подходящий scope для коммитов и PR (`feat(notes):`, 'fix(math):).\n- Без тела, без `Co-Authored-By`.\n",".agents/skills/release-notes/SKILL.md":"---\nname: release-notes\ndescription: Use when generating massCode release notes for a GitHub release. Writes the notes to a gitignored file `docs/releases/<tag>.md` for the user to paste into the GitHub release. Use when summarizing merged PRs of a version into a consistent release notes structure.\n---\n\n# Release Notes\n\n## Overview\n\nЭтот skill генерирует release notes одного релиза `vX.Y.Z` для вставки в GitHub release. Цель — единая повторяемая структура от релиза к релизу.\n\nНе трогай `docs/website/download/latest-release.md` — это отдельная repo-страница со своим форматом.\n\n## Source Of Truth\n\n- Содержимое выводи из merged PR между предыдущим и новым тегом, не из памяти.\n- Список изменений бери так:\n  `git log --first-parent --oneline <prev-tag>..<new-tag>` (например `v5.5.0..v5.6.0`).\n- Если новый тег ещё не создан, используй `<prev-tag>..HEAD` и спроси/подтверди номер новой версии.\n- Поведение значимых фич проверяй в коде или в `docs/website/documentation`, прежде чем формулировать, если оно неочевидно из заголовка PR.\n\n## Output\n\n- Записывай результат в файл `docs/releases/<new-tag>.md` (например `docs/releases/v5.6.0.md`). Папка `docs/releases` в `.gitignore`, это рабочий буфер, а не часть репозитория.\n- Пиши именно в файл, а не выводом в терминал: так пользователь копирует чистый markdown без переносов строк, которые добавляет терминал.\n- После записи коротко сообщи путь к файлу и при необходимости покажи итог. Не коммить файл.\n\n## Format\n\nФайл содержит один markdown-блок в этой структуре и порядке:\n\n```\n## <Feature Name>\n\n<1-2 абзаца: что это и что даёт пользователю.>\n\n## <Another Feature Name>\n\n<1-2 абзаца.>\n\n## Workflow Improvements\n\n- <мелкое улучшение>\n- <мелкое улучшение>\n\n## Fixes\n\n- <исправление>\n- <исправление>\n\n**Full Changelog**: https://github.com/massCodeIO/massCode/compare/<prev-tag>...<new-tag>\n```\n\nПравила структуры:\n\n- Начинай прямо с тематических `##`-разделов. Не добавляй заголовок версии `# vX.Y.Z` (его даёт сам GitHub release), frontmatter или `<AssetsDownload />` — это артефакты repo-страницы.\n- Один `##`-раздел на каждую значимую фичу или связную группу фич.\n- `## Workflow Improvements` и `## Fixes` включай только если для них есть содержимое.\n- Compare-ссылка всегда последней строкой, с актуальными предыдущим и новым тегами.\n\n## What To Include\n\n- User-facing изменения: новые spaces и фичи, заметные улучшения workflow, видимые исправления.\n- Крупную фичу выноси в отдельный `##`-раздел с 1-2 абзацами о пользе для пользователя.\n- Мелкие улучшения собирай в `## Workflow Improvements` буллетами.\n- Исправления собирай в `## Fixes` буллетами, по одному на исправление.\n\n## What To Omit\n\n- Чисто внутренние коммиты: `ci`, `build`, `chore`, рефакторинг, bump зависимостей, релизные служебные коммиты (`build: release vX.Y.Z`).\n- Исключение: выноси платформенные изменения, заметные пользователю (например code signing и notarization на macOS), в `## Workflow Improvements`.\n- Не описывай детали реализации; пиши о результате для пользователя.\n\n## Writing Style\n\n- Английский, спокойный фактический тон. Что делает фича и зачем она пользователю, без маркетинговых превосходных степеней.\n- Никаких em dash. Это общее правило репозитория.\n- Имена spaces пиши консистентно: `Code`, `Notes`, `Math Notebook`, `Drawings`, `HTTP`, `Tools`. Не смешивай `Code` и `Snippets` как имя пространства.\n- `snippet` — единица контента внутри пространства Code, а не имя пространства. В Fixes допустимо «snippet fences», «snippet sync», но пространство всё равно называется Code.\n- Code identifiers, расширения файлов и токены оборачивай в backticks (`` `.excalidraw` ``, `` `@` ``, `` `Esc` ``).\n- Shortcuts указывай как в интерфейсе; macOS и Windows/Linux варианты различай, если они отличаются.\n\n## Common Mistakes\n\n- Перечислять коммиты дословно вместо группировки в user-facing разделы.\n- Включать `ci` / `build` / `chore` шум, который не виден пользователю.\n- Добавлять `# vX.Y.Z`, frontmatter или `<AssetsDownload />` (это формат repo-страницы, а не GitHub release).\n- Выводить нотис простыней в терминал вместо файла `docs/releases/<new-tag>.md` (терминал ломает переносы строк при копировании).\n- Коммитить файл из `docs/releases` — это игнорируемый рабочий буфер.\n- Смешивать имена пространств (`Code` против `Snippets`) внутри одного документа.\n- Описывать детали реализации вместо пользы для пользователя.\n- Забыть обновить compare-ссылку на актуальные теги.\n- Использовать em dash вопреки правилу репозитория.\n",".agents/skills/spaces-architecture/SKILL.md":"---\nname: spaces-architecture\ndescription: Use when working on massCode spaces such as code, notes, math, or tools, especially when changing their state, behavior, synchronization, or spaces IPC channels.\n---\n\n# Spaces Architecture\n\n## Overview\n\nmassCode использует систему Spaces для разделения функциональных областей. Это не просто UI tabs: у каждого space есть собственное состояние, свои правила обновления и свой способ синхронизации с данными в vault.\n\n## Space Model\n\n- `code` — snippets, folders, tags\n- `notes` — notes, folders, tags, markdown-based flows\n- `math` — calculation sheets и состояние math notebook\n- `tools` — developer utilities\n\nОсновные определения живут в `src/renderer/spaceDefinitions.ts`.\n\n## Space State Storage\n\n- Состояние каждого space хранится в `__spaces__/{spaceId}/.state.yaml` внутри vault.\n- Runtime helpers:\n  - `src/main/storage/providers/markdown/runtime/spaces.ts`\n  - `src/main/storage/providers/markdown/runtime/spaceState.ts`\n- Директория `__spaces__/` — служебная часть vault для состояния spaces.\n\n## Persistence Rules\n\n- Запись состояния spaces использует ту же debounce/flush инфраструктуру, что и `state.json`.\n- Не ломай совместимость с `pendingStateWriteByPath` и flush-on-exit поведением.\n- Если меняешь способ записи, учитывай сценарий завершения приложения до явного ручного flush.\n\n## IPC Rules\n\n- Space-specific IPC handlers живут в `src/main/ipc/handlers/spaces.ts`.\n- Текущие math handlers:\n  - `spaces:math:read`\n  - `spaces:math:write`\n- Если добавляется новый `spaces:*` flow, он должен работать через общую модель состояния spaces, а не в обход неё.\n\n## Space-Aware Sync\n\n- `system:storage-synced` обновляет активное пространство через `getActiveSpaceId()`.\n- Ожидаемое поведение:\n  - `code` → refresh folders + snippets\n  - `notes` → refresh notes + note folders\n  - `math` → `reloadFromDisk()` через `useMathNotebook()`\n  - `tools` → no-op\n- Изменения, которые уже сохранены в vault, должны вызывать `markPersistedStorageMutation()`, чтобы не создавать sync loops.\n\n## Common Mistakes\n\n- Считать spaces только UI-концепцией и забывать, что у них есть собственное состояние и правила синхронизации.\n- Писать состояние space в обход общих markdown runtime helpers.\n- Добавлять mutation без `markPersistedStorageMutation()`.\n- Ломать согласованность между состоянием space, helpers и sync behavior.\n",".agents/skills/ui-foundations/SKILL.md":"---\nname: ui-foundations\ndescription: Use when defining or reviewing massCode UI foundation rules such as typography, renderer styling consistency, TailwindCSS v4 usage, and when raw markup starts competing with established UI text patterns.\n---\n\n# UI Foundations\n\n## Overview\n\nUI в massCode должен оставаться визуально консистентным. Этот skill отвечает за базовые styling decisions: как относиться к typography, когда использовать established text patterns и как не скатываться в разрозненный renderer styling.\n\n## Core Rules\n\n- Базовая styling system в renderer строится на TailwindCSS v4.\n- Новые UI-экраны и состояния должны продолжать существующий visual language, а не вводить локальные правила “для одного места”.\n- Для стандартного app UI предпочитай семантические токены вроде `bg-background`, `text-muted-foreground`, `border-border`, `border-destructive/*` вместо raw palette-классов вроде `bg-white`, `text-black`, `text-green-500`, `bg-slate-900`.\n- Typography по умолчанию строится через `UiText`.\n- Не заменяй `UiText` на произвольный набор `text-*`, `font-*`, `text-muted-foreground`, если подходящий variant уже существует.\n- Если `UiText` почти подходит, лучше добавить точечные классы поверх него, чем уходить в raw typography markup.\n\n## Typography\n\n- `UiText` — базовый источник правды для текстовых размеров и muted-state.\n- `caption` и `xs` — подписи, helper text, secondary labels.\n- `sm` и `base` — основной интерфейсный текст.\n- `lg` и `xl` — усиленные title/value cases, когда это действительно нужно по hierarchy.\n- `font-mono` — только для code-like content, IDs, counts with alignment needs, readonly generated output и подобных случаев.\n- Для uppercase labels используй существующий pattern через `UiText` или согласованный tracking/uppercase стиль, а не случайную смесь utility classes в каждом месте.\n\n## Spacing And Layout Rhythm\n\n- Корневые screen/container wrappers обычно живут в ритме `space-y-4` или `space-y-6`.\n- Внутри компактных секций чаще всего `space-y-2` или `space-y-3`.\n- Grid gaps по умолчанию: `gap-2`, `gap-3`, `gap-4` в зависимости от плотности.\n- Не придумывай локальный spacing-scale для одного экрана, если существующие интервалы уже покрывают задачу.\n- Повторяющиеся content blocks должны иметь одинаковый padding и vertical rhythm.\n\n## Radius And Shadows\n\n- `rounded-md` — controls, inline boxes, compact containers.\n- `rounded-lg` — card-like blocks, dialogs, overlays, dashboard sections.\n- `rounded-xl` — preview-heavy surfaces и крупные visual blocks.\n- `rounded-full` — pills, badges, circular handles.\n- `shadow-xs` — inputs, buttons, small controls.\n- `shadow-md` и `shadow-lg` — overlays, popovers, previews, где elevation реально нужна.\n- Не вводи произвольные `rounded-[...]` и `shadow-[...]`, если стандартные токены уже подходят.\n\n## Exceptions\n\n- Raw colors допустимы, если цвет является частью самих данных или preview:\n  color pickers, contrast previews, code/image export backgrounds, diagram or visualizer nodes.\n- Если цвет вычисляется из контента или нужен для корректного контраста на пользовательском фоне, raw class или inline style допустимы.\n- Исключения не должны становиться поводом тащить raw palette в обычный application chrome.\n\n## When To Prefer This Skill\n\n- Нужно понять, как оформлять текст и подписи в новом UI.\n- Есть соблазн писать raw Tailwind typography вместо существующего text pattern.\n- В экране начинают появляться локальные styling rules, которые расходятся с остальным renderer UI.\n- Нужно принять решение на уровне визуальной базы, а не конкретного button/input/dialog.\n\n## Common Mistakes\n\n- Размазывать локальные визуальные исключения по фичам.\n- Тащить raw palette в обычный app UI без реальной причины.\n- Писать текст напрямую через произвольные utility classes там, где подходит `UiText`.\n- Делать новый экран со своим spacing rhythm вместо существующего scale.\n- Случайно смешивать small-control radii и preview-surface radii в одном и том же UI слое.\n- Считать Tailwind поводом делать каждый экран визуально “с нуля”.\n",".agents/skills/ui-primitives/SKILL.md":"---\nname: ui-primitives\ndescription: Use when building or refactoring massCode UI components with local Ui primitives or Shadcn, especially for cn, cva, notifications, and rules against reimplementing basic controls.\n---\n\n# UI Primitives\n\n## Overview\n\nБазовые UI-элементы в massCode должны собираться из существующих `Ui*` компонентов и Shadcn-паттернов. Этот skill отвечает за component-level usage rules, а не за общую визуальную базу.\n\n## Component Usage\n\n- Локальные UI-компоненты доступны через auto-import с префиксом `Ui`.\n- Базовые элементы вроде button, input, checkbox, action button не переизобретай на сыром HTML, если есть готовый `Ui*` вариант.\n- Если нужного элемента нет, сначала создай его в `src/renderer/components/ui/`, потом используй в фиче.\n\n## Buttons\n\n- Primary action должен быть явным и не конкурировать с несколькими равноправными CTA в одном контейнере.\n- Icon-only actions должны быть понятны по контексту и иметь tooltip или другой доступный label path.\n- Loading и pending actions должны использовать существующий button pattern, а не ad-hoc “disabled text swap”.\n- Destructive actions не должны выглядеть как обычные secondary controls.\n\n## Cards And Containers\n\n- Для автономных panel-like блоков используй существующий `Card` / `Ui*` container pattern, если он уже есть в области.\n- Внутренние muted blocks не нужно пересобирать разными `div`-паттернами в каждой фиче.\n- Repeated panel structure должна переезжать в shared primitive или local feature primitive, а не копироваться markup-в-маркап.\n\n## Readonly And Copyable Content\n\n- Длинный readonly output, generated text, URLs и similar content не показывай как “обычный disabled input”, если это ухудшает чтение.\n- Для copy flows используй существующий copy pattern и уведомления через `useSonner()`.\n- Readonly content должен оставаться визуально читаемым и удобно копируемым.\n\n## Styling Helpers\n\n- Для variants используй `cva`.\n- Для склейки классов используй `cn()`.\n- Не делай variants вручную строковыми `if`-цепочками там, где нужен нормальный variant API.\n\n## Shadcn Rules\n\n- Shadcn-компоненты импортируй вручную из `@/components/ui/shadcn/*`.\n- Для namespace-based компонентов используй паттерн вроде `import * as Dialog from '@/components/ui/shadcn/dialog'`.\n\n## Notifications\n\n- Для уведомлений используй `useSonner()`.\n- Не добавляй локальную, параллельную систему toast/notification внутри фичи.\n\n## Tooltip, Popover, Overlay\n\n- Tooltip — для короткого пояснения.\n- Popover — для richer inline content, picker-like content или contextual controls.\n- Не заменяй их ad-hoc overlay-разметкой без необходимости.\n- Validation и inline guidance должны использовать существующие tooltip/popover primitives, если проект уже их применяет в аналогичных местах.\n\n## Dialog Focus\n\n- Во всех диалогах явно управляй фокусом при открытии и закрытии. Не допускай автоматического фокуса на крестике закрытия и появления tooltip на кнопке открытия из-за возврата фокуса после закрытия.\n- По умолчанию отменяй стандартный autofocus на `DialogContent`:\n\n  ```vue\n  @open-auto-focus=\"(e) => e.preventDefault()\"\n  @close-auto-focus=\"(e) => e.preventDefault()\"\n  ```\n\n- Исключение — намеренный фокус на конкретном поле или действии, нужном для сценария диалога. Задавай такую цель явно; при закрытии выбирай цель возврата фокуса без побочного показа tooltip.\n- Сохраняй focus trap и клавиатурную навигацию. Проверяй открытие и закрытие мышью и клавиатурой, включая Escape.\n\n## Common Mistakes\n\n- Писать ещё одну кнопку или input с нуля “потому что быстрее”.\n- Склеивать сложные conditional classes без `cn()`.\n- Дублировать существующий primitive внутри feature directory вместо общего `src/renderer/components/ui/`.\n- Использовать disabled input как универсальный readonly display surface.\n- Делать overlay pattern вручную там, где уже есть Shadcn primitive.\n- Смешивать правила primitives с вопросами визуальной базы, которые должны идти в `ui-foundations`.\n",".agents/skills/vue-renderer-standards/SKILL.md":"---\nname: vue-renderer-standards\ndescription: Use when editing massCode renderer code in Vue 3, especially for script setup patterns, import rules, composables, shared state, and renderer-side conventions.\n---\n\n# Vue Renderer Standards\n\n## Overview\n\nRenderer в massCode строится на Vue 3 Composition API с `<script setup lang=\"ts\">`. Здесь важны строгие import rules, composable-first state sharing и запрет на прямой доступ к backend-возможностям.\n\n## Component Pattern\n\n- Используй Vue 3 Composition API и `<script setup lang=\"ts\">`.\n- Vue core (`ref`, `computed`, `watch`, `onMounted` и подобные) не импортируй вручную: они auto-imported.\n- Проектные компоненты из `src/renderer/components/` тоже не импортируй вручную: они auto-imported.\n- Локальную логику компонента держи в script, а не в template.\n\n## Manual Imports Only Where Required\n\nВсегда импортируй вручную:\n\n- composables из `@/composables`;\n- utils из `@/utils`;\n- `@vueuse/core`;\n- Electron bridge из `@/electron`;\n- Shadcn UI из `@/components/ui/shadcn/*`.\n\n## Shared State\n\n- Глобальное shared state реализуется composables без Pinia/Vuex.\n- Reactive state, который должен шариться между компонентами, объявляй на module level, вне экспортируемой функции composable.\n- Persistent UI/settings state храни через `store` из `@/electron`:\n  - `store.app` для UI state;\n  - `store.preferences` для user preferences.\n\n## VueUse First\n\n- Перед написанием нового composable сначала проверь, нет ли подходящего решения в `@vueuse/core`.\n- Кастомный composable добавляй только если готового utility реально нет.\n\n## Renderer Boundaries\n\n- Renderer не импортирует storage internals или backend-модули доступа к данным напрямую.\n- Renderer не обращается напрямую к Node.js, filesystem или storage runtime.\n- Доступ к main process возможен только через `api` или `ipc`.\n\n## Common Mistakes\n\n- Ручной импорт `ref` / `computed` / `watch`.\n- Ручной импорт локальных project components.\n- Локальный state внутри composable, который должен быть общим между несколькими компонентами.\n- Попытка “срезать путь” и импортировать backend-модуль прямо в renderer.\n","AGENTS.md":"# Точка входа для агента massCode\n\nОтвечай всегда на русском.\n\nmassCode — это приложение на Electron + Vue 3 + TypeScript с TailwindCSS v4 в renderer, API-маршрутами на Elysia в main process, markdown vault как основным хранилищем пользовательского контента в v5 и `store.app` / `store.preferences` для локального UI state и настроек.\n\n## Всегда действующие правила\n\n- Следуй YAGNI. Предпочитай минимальную корректную реализацию вместо спекулятивных абстракций.\n- Соблюдай границы слоёв: renderer не должен напрямую обращаться к Node.js, filesystem или DB. Используй API или IPC.\n- Никогда не хардкодь пользовательские строки. Используй систему локализации.\n- Не запускай lint или тесты по всему проекту для локальной задачи. Ограничивай команды затронутыми файлами или директориями.\n- После изменений API DTO или routes запускай `pnpm api:generate`.\n- После изменений locale-файлов запускай `pnpm i18n:copy`.\n- Если задача совпадает по теме с одним из skills ниже, загружай этот skill до внесения изменений.\n\n## Skills\n\n- `.agents/skills/architecture-standards/SKILL.md`\n  Используй первым для общих правил репозитория: архитектура, naming, декомпозиция и выбор следующего skill.\n- `.agents/skills/vue-renderer-standards/SKILL.md`\n  Используй для работы с Vue renderer: `<script setup lang=\"ts\">`, правила auto-import, composables, shared state и renderer-side паттерны.\n- `.agents/skills/ui-foundations/SKILL.md`\n  Используй для базовых UI-правил: Tailwind v4, typography через `UiText` и согласованных styling decisions для renderer UI.\n- `.agents/skills/ui-primitives/SKILL.md`\n  Используй для component-level UI работы: `Ui*` components, Shadcn imports, `cn`, `cva`, notifications и правил против переизобретения primitives.\n- `.agents/skills/electron-api-and-ipc/SKILL.md`\n  Используй для API routes, DTO, IPC handlers, renderer-to-main communication и границ Electron-интеграции.\n- `.agents/skills/api-and-typing/SKILL.md`\n  Используй для generated API types, DTO-derived renderer typing и решения, когда локальный UI type оправдан, а когда нужно переиспользовать существующие API types.\n- `.agents/skills/spaces-architecture/SKILL.md`\n  Используй при изменениях, связанных с `code` / `notes` / `math` / `tools`, markdown-space state, sync behavior или `spaces:*` IPC.\n- `.agents/skills/i18n/SKILL.md`\n  Используй для правил локализации, размещения locale keys, `i18n.t(...)` и требования не хардкодить строки.\n- `.agents/skills/documentation-workflow/SKILL.md`\n  Используй для добавления или обновления документации, страниц `docs/website/documentation`, sidebar, assets и README-упоминаний фич.\n- `.agents/skills/release-notes/SKILL.md`\n  Используй для генерации release notes нового релиза в игнорируемый файл `docs/releases/<tag>.md` для вставки в GitHub release: группировка merged PR в user-facing разделы и compare-ссылка.\n- `.agents/skills/development-workflow/SKILL.md`\n  Используй для repo-specific workflow rules: scoped lint/test команды и обязательные follow-up шаги после изменений source-of-truth файлов.\n- `.agents/skills/github-workflow/SKILL.md`\n  Используй для massCode git и GitHub workflow: issue, ветки, commits, PR и подготовки к merge.\n\n## Рекомендуемый порядок загрузки\n\n- Широкая или неочевидная задача: начни с `architecture-standards`, затем загрузи профильный skill.\n- Renderer UI задача: `architecture-standards` → `vue-renderer-standards` → `ui-foundations` → `ui-primitives`.\n- API / IPC / Electron задача: `architecture-standards` → `electron-api-and-ipc`.\n- Generated types / renderer typing задача: `architecture-standards` → `api-and-typing`.\n- Spaces задача: `architecture-standards` → `spaces-architecture`.\n- Задача про текст и локализацию: `i18n`.\n- Задача про документацию или README: `documentation-workflow`.\n- Задача про release notes нового релиза: `release-notes`.\n- Workflow-чувствительная задача: `development-workflow`.\n- Задача про git / branch / commit / PR: `github-workflow`.\n\n## Основной стек\n\n- Framework: Vue 3, Composition API, `<script setup lang=\"ts\">`\n- Styling: TailwindCSS v4, `tailwind-merge`, `cva`\n- UI: локальные `src/renderer/components/ui`, Shadcn поверх `reka-ui`, `lucide-vue-next`\n- State: composables, без Pinia/Vuex\n- Backend: Electron main, Elysia API, markdown vault для контента и `electron-store` для локального состояния приложения\n- Utilities: `@vueuse/core`, `vue-sonner`\n","CLAUDE.md":"AGENTS.md","docs/website/documentation/tools/index.md":"---\ntitle: Overview\ndescription: \"Use built-in developer tools in massCode for JSON diffing, text conversion, hashing, HMAC generation, URL parsing, and other quick tasks.\"\n---\n\n# Tools overview\n\nTools is for the small developer tasks that should take seconds, not a trip to a random website. Use it when you need to compare JSON, convert, encode, hash, or generate something quickly without leaving massCode.\n\nThe available tools are grouped by category:\n\n## Compare\n\n### [JSON Diff](/documentation/tools/json-diff)\n\nCompare two JSON documents side by side with validation, filters, and a tree diff for nested changes.\n\n## Text tools\n\n### Case Converter\n\nConvert text between common casing formats such as camelCase, snake_case, kebab-case, and uppercase.\n\n### Slug Generator\n\nTurn free-form text into a URL-friendly slug.\n\n### URL Parser\n\nSplit a URL into its protocol, host, path, query, and hash parts.\n\n### Line Break Normalizer\n\nRemove hard wraps from copied terminal output while preserving Markdown lists, tables, quotes, commands, and code blocks. The same normalization is available from the **Editor** menu in Code and Notes.\n\n## Cryptography & Security\n\n### Hash Generators\n\nGenerate one-way hashes from text input.\n\n### HMAC Generators\n\nBuild keyed message authentication hashes from a secret and a message.\n\n### Password Generators\n\nGenerate random passwords with configurable character sets.\n\n### UUID Generators\n\nCreate unique identifiers for fixtures, payloads, and test data.\n\n## Encoders & Decoders\n\n### URL\n\nEncode or decode URL strings safely.\n\n### Base64\n\nConvert plain text to and from Base64.\n\n### JSON ⇄ TOML/XML/YAML\n\nTransform JSON between common structured data formats.\n\n### Text ⇄ ASCII/Binary/Unicode\n\nConvert text into different low-level or escaped representations and back.\n\n### Color Converter\n\nTranslate color values between supported formats.\n\n## Generators\n\n### JSON Generator\n\nBuild mock JSON payloads with typed fields for testing and demos.\n\n### Lorem Ipsum Generator\n\nGenerate placeholder words, sentences, or paragraphs.\n","docs/website/documentation/tools/json-diff.md":"---\ntitle: JSON Diff\ndescription: \"Compare two JSON documents side by side in massCode with validation, filters, and a tree diff.\"\n---\n\n# JSON Diff\n\nJSON Diff lets you compare two JSON documents side by side without leaving massCode. It is useful for checking API responses, fixture changes, configuration edits, and generated JSON payloads.\n\n## Where to find it\n\nOpen **Tools** in the left rail, then go to **Compare** → **JSON Diff**.\n\n## What it does\n\n- Shows the original and modified JSON in two editors\n- Validates each side independently\n- Formats valid JSON on paste and blur\n- Builds a tree-based diff for nested objects and arrays\n- Highlights added, removed, and modified values\n- Filters the diff by change type\n- Keeps both input editors scrolled in sync\n- Uses the same editor font settings as the main code editor\n\n## How to use it\n\n1. Paste the original JSON into the left editor.\n2. Paste the modified JSON into the right editor.\n3. Review the diff tree below the editors.\n4. Use the checkboxes to focus on added, removed, or modified nodes.\n5. Expand or collapse nested objects and arrays as needed.\n\n## Notes\n\n- Both inputs must contain valid JSON before the diff viewer appears.\n- Validation errors are shown under each editor separately.\n- If only one side is filled, the tool stays in the empty state instead of guessing missing data.\n- Array move visualization is not exposed as a separate state. In this version, the tool prefers predictable output over compact move semantics.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Точка входа для агента massCode\n\nОтвечай всегда на русском.\n\nmassCode — это приложение на Electron + Vue 3 + TypeScript с TailwindCSS v4 в renderer, API-маршрутами на Elysia в main process, markdown vault как основным хранилищем пользовательского контента в v5 и `store.app` / `store.preferences` для локального UI state и настроек.\n\n## Всегда действующие правила\n\n- Следуй YAGNI. Предпочитай минимальную корректную реализацию вместо спекулятивных абстракций.\n- Соблюдай границы слоёв: renderer не должен напрямую обращаться к Node.js, filesystem или DB. Используй API или IPC.\n- Никогда не хардкодь пользовательские строки. Используй систему локализации.\n- Не запускай lint или тесты по всему проекту для локальной задачи. Ограничивай команды затронутыми файлами или директориями.\n- После изменений API DTO или routes запускай `pnpm api:generate`.\n- После изменений locale-файлов запускай `pnpm i18n:copy`.\n- Если задача совпадает по теме с одним из skills ниже, загружай этот skill до внесения изменений.\n\n## Skills\n\n- `.agents/skills/architecture-standards/SKILL.md`\n  Используй первым для общих правил репозитория: архитектура, naming, декомпозиция и выбор следующего skill.\n- `.agents/skills/vue-renderer-standards/SKILL.md`\n  Используй для работы с Vue renderer: `<script setup lang=\"ts\">`, правила auto-import, composables, shared state и renderer-side паттерны.\n- `.agents/skills/ui-foundations/SKILL.md`\n  Используй для базовых UI-правил: Tailwind v4, typography через `UiText` и согласованных styling decisions для renderer UI.\n- `.agents/skills/ui-primitives/SKILL.md`\n  Используй для component-level UI работы: `Ui*` components, Shadcn imports, `cn`, `cva`, notifications и правил против переизобретения primitives.\n- `.agents/skills/electron-api-and-ipc/SKILL.md`\n  Используй для API routes, DTO, IPC handlers, renderer-to-main communication и границ Electron-интеграции.\n- `.agents/skills/api-and-typing/SKILL.md`\n  Используй для generated API types, DTO-derived renderer typing и решения, когда локальный UI type оправдан, а когда нужно переиспользовать существующие API types.\n- `.agents/skills/spaces-architecture/SKILL.md`\n  Используй при изменениях, связанных с `code` / `notes` / `math` / `tools`, markdown-space state, sync behavior или `spaces:*` IPC.\n- `.agents/skills/i18n/SKILL.md`\n  Используй для правил локализации, размещения locale keys, `i18n.t(...)` и требования не хардкодить строки.\n- `.agents/skills/documentation-workflow/SKILL.md`\n  Используй для добавления или обновления документации, страниц `docs/website/documentation`, sidebar, assets и README-упоминаний фич.\n- `.agents/skills/release-notes/SKILL.md`\n  Используй для генерации release notes нового релиза в игнорируемый файл `docs/releases/<tag>.md` для вставки в GitHub release: группировка merged PR в user-facing разделы и compare-ссылка.\n- `.agents/skills/development-workflow/SKILL.md`\n  Используй для repo-specific workflow rules: scoped lint/test команды и обязательные follow-up шаги после изменений source-of-truth файлов.\n- `.agents/skills/github-workflow/SKILL.md`\n  Используй для massCode git и GitHub workflow: issue, ветки, commits, PR и подготовки к merge.\n\n## Рекомендуемый порядок загрузки\n\n- Широкая или неочевидная задача: начни с `architecture-standards`, затем загрузи профильный skill.\n- Renderer UI задача: `architecture-standards` → `vue-renderer-standards` → `ui-foundations` → `ui-primitives`.\n- API / IPC / Electron задача: `architecture-standards` → `electron-api-and-ipc`.\n- Generated types / renderer typing задача: `architecture-standards` → `api-and-typing`.\n- Spaces задача: `architecture-standards` → `spaces-architecture`.\n- Задача про текст и локализацию: `i18n`.\n- Задача про документацию или README: `documentation-workflow`.\n- Задача про release notes нового релиза: `release-notes`.\n- Workflow-чувствительная задача: `development-workflow`.\n- Задача про git / branch / commit / PR: `github-workflow`.\n\n## Основной стек\n\n- Framework: Vue 3, Composition API, `<script setup lang=\"ts\">`\n- Styling: TailwindCSS v4, `tailwind-merge`, `cva`\n- UI: локальные `src/renderer/components/ui`, Shadcn поверх `reka-ui`, `lucide-vue-next`\n- State: composables, без Pinia/Vuex\n- Backend: Electron main, Elysia API, markdown vault для контента и `electron-store` для локального состояния приложения\n- Utilities: `@vueuse/core`, `vue-sonner`\n","isInternal":false,"tokens":1441,"sizeBytes":5907},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"AGENTS.md","isInternal":false,"tokens":3,"sizeBytes":9},{"name":"SKILL.md","path":".agents/skills/api-and-typing/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/api-and-typing/SKILL.md","title":"api-and-typing","category":"anthropic-skill","format":"markdown","content":"---\nname: api-and-typing\ndescription: Use when defining or reviewing massCode renderer types that come from generated API clients or DTOs, especially when deciding whether to reuse existing API shapes, derive narrower local types, or introduce a UI-only model.\n---\n\n# API And Typing\n\n## Overview\n\nДля massCode API types считаются generated-first. Если данные пришли из `~/renderer/services/api/generated` или соответствуют DTO из `src/main/api/dto`, сначала используй существующие типы и utility typing, а не придумывай новый interface рядом с компонентом.\n\n## Core Rules\n\n- Ручные дубли API response types не пиши.\n- Сначала ищи тип в `~/renderer/services/api/generated`.\n- Если прямого export нет, выводи нужный shape через `Pick`, `Omit`, indexed access, `Parameters`, `ReturnType`, `Awaited`, `NonNullable`.\n- Локальный тип допустим только как UI-only model, form model, derived display model или narrow type после нормального data narrowing.\n\n## Good Uses Of Local Types\n\n- Узкий renderer shape после того, как nullable API data уже очищена в одном месте.\n- View-model для dashboard card, graph node, readonly row или editor-side helper, если он не равен transport shape.\n- Тип аргумента, выводимый из существующего composable или API method через `Parameters` / `ReturnType`.\n\n## Bad Uses Of Local Types\n\n- Полный дубль `SnippetsResponse`, `NotesDashboardResponse`, `TagsResponse` и других generated types.\n- Новый interface “для удобства”, если можно взять одну ветку из existing response type.\n- Копирование DTO shape в renderer file, хотя он уже импортируемый.\n\n## Common Mistakes\n\n- Сначала придумать локальный interface, а потом уже искать generated type.\n- Смешать transport shape и UI view-model без явного adapter step.\n- Тащить глубоко в UI сырые nullable API поля вместо одного нормального normalization place.\n","frontmatter":{"name":"api-and-typing","description":"Use when defining or reviewing massCode renderer types that come from generated API clients or DTOs, especially when deciding whether to reuse existing API shapes, derive narrower local types, or introduce a UI-only model."},"isInternal":false,"tokens":506,"sizeBytes":2354},{"name":"SKILL.md","path":".agents/skills/architecture-standards/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/architecture-standards/SKILL.md","title":"architecture-standards","category":"anthropic-skill","format":"markdown","content":"---\nname: architecture-standards\ndescription: Use when working in massCode and you need repo-wide architecture rules, naming conventions, decomposition boundaries, or guidance on which massCode skill to load next.\n---\n\n# Architecture Standards\n\n## Overview\n\nБазовый принцип проекта: **YAGNI и простота прежде всего**. Не усложняй код ради гипотетических сценариев, не строй абстракции без повторяющейся потребности и не размывай границы между renderer, API и main.\n\n## Core Rules\n\n- Соблюдай разделение слоёв:\n  - Renderer: только UI, composables, вызовы `api.*` и `ipc.invoke(...)`.\n  - API: маршруты Elysia, DTO, orchestration и доступ к сервисам и данным приложения.\n  - Main: системные интеграции, IPC handlers, lifecycle и слой данных приложения.\n- Data flow по умолчанию: Renderer → API / IPC → service / data layer → response.\n- Vue-компоненты называй в `PascalCase`.\n- TypeScript-файлы называй в `camelCase`.\n- Composables именуй с префиксом `use`, а имя файла должно совпадать с экспортируемой функцией.\n\n## YAGNI Guardrails\n\nПризнаки overengineering:\n\n- функция страхуется от кейса, которого реально не существует;\n- factory или wrapper используется ровно в одном месте и не скрывает состояние;\n- abstraction-for-abstraction без повторяющейся боли;\n- константы, паттерны и конфигурации придуманы заранее, а не из реальной потребности.\n\n## Component Decomposition\n\n- Если компонент становится больше примерно `300` строк или держит `3+` несвязанных обязанности, дели его.\n- Порядок разбиения:\n  1. вынеси константы и статические данные;\n  2. вынеси чистые функции в utils, только если это реально переиспользуется;\n  3. перемести состояние и эффекты в composable;\n  4. разбей шаблон на локальные child components.\n- Не держи в `<template>` логику сложнее тернарного оператора.\n\n## Feature Subdirectories\n\n- Если часть домена выросла в отдельный subsystem, группируй локальные компоненты, helpers, tests и fixtures в поддиректорию.\n- Внутри поддиректории не повторяй полный родительский префикс в именах файлов.\n- Локальные файлы держи рядом с фичей. Shared-код, который нужен нескольким областям, оставляй выше уровнем.\n\n## When to Load Other Skills\n\n- Vue renderer, auto-imports, composables, shared state:\n  `vue-renderer-standards`\n- визуальная база, typography, renderer styling decisions:\n  `ui-foundations`\n- `Ui*`, Shadcn, `cn`, `cva`, notifications:\n  `ui-primitives`\n- API routes, DTO, IPC, Electron boundaries:\n  `electron-api-and-ipc`\n- generated API types, utility typing, локальные view-model:\n  `api-and-typing`\n- `code` / `notes` / `math` / `tools`, состояние spaces и их синхронизация:\n  `spaces-architecture`\n- i18n, locale keys, `i18n.t(...)`:\n  `i18n`\n- docs website, docs sidebar, скриншоты, README-упоминания фич:\n  `documentation-workflow`\n- scoped lint/test и follow-up commands:\n  `development-workflow`\n\n## Common Mistakes\n\n- Тянуть DB или filesystem knowledge в renderer.\n- Раздувать один компонент до “оркестратора всего”.\n- Выносить абстракцию до появления второй реальной точки использования.\n- Размазывать одну фичу по плоской структуре файлов, когда ей уже нужен локальный subdirectory.\n- Придумывать локальные typing-паттерны, хотя для них уже пора иметь отдельный skill.\n","frontmatter":{"name":"architecture-standards","description":"Use when working in massCode and you need repo-wide architecture rules, naming conventions, decomposition boundaries, or guidance on which massCode skill to load next."},"isInternal":false,"tokens":1130,"sizeBytes":4602},{"name":"SKILL.md","path":".agents/skills/development-workflow/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/development-workflow/SKILL.md","title":"development-workflow","category":"anthropic-skill","format":"markdown","content":"---\nname: development-workflow\ndescription: Use when following massCode repo workflow rules, especially for scoped lint and test commands, or when changes require required follow-up commands like code generation or locale sync.\n---\n\n# Development Workflow\n\n## Overview\n\nВ massCode workflow rules считаются частью качества изменений. Для локальной задачи команды должны быть точечными, а изменения source-of-truth файлов должны сопровождаться обязательными follow-up шагами.\n\n## Linting Rules\n\n- Всегда запускай lint только по затронутым файлам или директориям.\n- Никогда не запускай lint по всему проекту во время локальной задачи.\n- Используй scoped commands вроде:\n  - `pnpm lint <path>`\n  - `pnpm lint:fix <path>`\n\n## Testing Rules\n\n- Всегда запускай тесты только по затронутым файлам или директориям.\n- Никогда не запускай весь test suite без явной необходимости.\n- Используй scoped commands вроде:\n  - `pnpm test <path>`\n  - `pnpm test:watch <path>`\n\n## Required Follow-Up Commands\n\n- Изменил API DTO/routes → `pnpm api:generate`\n- Изменил locale-файлы → `pnpm i18n:copy`\n\n## Common Mistakes\n\n- Прогонять весь lint/test suite для маленькой точечной правки.\n- Менять source-of-truth файлы и забывать generation/sync шаг.\n- Запускать “на всякий случай” широкие команды вместо минимального релевантного набора.\n","frontmatter":{"name":"development-workflow","description":"Use when following massCode repo workflow rules, especially for scoped lint and test commands, or when changes require required follow-up commands like code generation or locale sync."},"isInternal":false,"tokens":438,"sizeBytes":1839},{"name":"SKILL.md","path":".agents/skills/documentation-workflow/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/documentation-workflow/SKILL.md","title":"documentation-workflow","category":"anthropic-skill","format":"markdown","content":"---\nname: documentation-workflow\ndescription: Use when adding or updating massCode documentation, documenting a new feature, changing docs website pages, adding docs assets, updating the VitePress sidebar, or adding README feature mentions.\n---\n\n# Documentation Workflow\n\n## Overview\n\nДокументация massCode живёт в VitePress сайте в `docs/website/documentation`. README — это общий обзор проекта, а не источник детального описания фич.\n\n## Documentation Surfaces\n\n- Документация фич: `docs/website/documentation/**`\n- Sidebar документации: `docs/website/.vitepress/config.mts`\n- Assets документации: `docs/website/public/**`\n- Overview документации: `docs/website/documentation/index.md`\n- Overview проекта: `README.md`\n\n## Core Rules\n\n- Проверяй поведение фичи в коде или существующей документации; не документируй по памяти.\n- Используй `rg`, чтобы найти связанные страницы, скриншоты, shortcuts, labels и существующие формулировки.\n- Если целевая версия известна, используй именно её. Если версия неизвестна, не придумывай её.\n- Пользовательская документация сайта пишется на английском, в стиле существующих docs pages.\n- Добавляй или обновляй наиболее конкретную страницу в `docs/website/documentation`.\n- Для новых страниц используй frontmatter с `title` и `description`.\n- Добавляй страницу в `docs/website/.vitepress/config.mts` только если она должна появиться в навигации.\n- Ссылайся из `docs/website/documentation/index.md` только на широкие, cross-cutting фичи.\n- Пиши короткими task-oriented секциями. Предпочитай пользовательские флоу, а не детали реализации.\n- Shortcuts документируй через `<kbd>...</kbd>` и указывай macOS плюс Windows/Linux варианты, если они отличаются.\n\n## Version Availability\n\n- Перед добавлением или изменением `<AppVersion>` проверяй историю фичи в коде, документации или предыдущем релизном теге.\n- Считай `<AppVersion text=\">=x.y\" />` минимальной версией, где появилась ровно описываемая возможность, а не версией её последнего улучшения.\n- Ставь marker на уровне страницы или общего раздела только когда вся описываемая сущность впервые появилась в этой версии.\n- Если новый релиз расширяет существующую фичу, сохраняй её исходный marker или отсутствие marker, а новую версию указывай только у отдельного подпункта или предложения про улучшение.\n- Разделяй смешанное описание на базовую возможность и versioned enhancement, если общий marker создаёт впечатление, что старая возможность раньше была недоступна.\n- Не добавляй version marker для bugfix или внутренней переработки без нового пользовательского сценария. Локально отмечай изменение формата хранения, если оно влияет на совместимость.\n\nПример: если custom folder icons существуют с 3.7, а Emoji и Upload добавлены в 5.9, оставляй `>=3.7` у базовой возможности и ставь `>=5.9` только у подпункта про Emoji и Upload.\n\n## Documentation Weight\n\n- Перед созданием страницы или раздела оцени самостоятельность пользовательского сценария, количество шагов, настроек и ограничений.\n- Описывай мелкое одношаговое действие одной строкой или буллетом внутри существующего релевантного раздела.\n- Создавай отдельный раздел для самостоятельного workflow с несколькими шагами, вариантами, настройками или важными ограничениями.\n- Выбирай одно основное место для подробного описания cross-cutting фичи. В других страницах оставляй короткое упоминание или ссылку вместо повторения полного объяснения.\n- Оставляй bugfix, внутреннюю оптимизацию и implementation detail только в release notes, если они не меняют пользовательский сценарий или требования совместимости.\n\n## Callouts\n\n- Используй `warning` для риска потери данных, несовместимости, необратимого действия или существенного security-ограничения.\n- Используй `info` для автоматической миграции и неочевидного поведения, которое помогает правильно понять основной workflow.\n- Оставляй основные инструкции обычным текстом; callout должен выделять контекст или исключение, а не содержать весь сценарий.\n- Объединяй связанные риски в один callout и избегай нескольких соседних блоков, если их можно прочитать как одно сообщение.\n- Добавляй короткий предметный заголовок, например `::: warning Compatibility` или `::: info Automatic migration`.\n\n## VitePress Markdown Gotchas\n\n- VitePress компилирует markdown как Vue-компонент, поэтому `{{ ... }}` трактуется как Vue-интерполяция и **исчезает** из вывода.\n- Fenced-блоки (` ``` `) защищены автоматически — внутри них `{{var}}` рендерится буквально.\n- **Инлайн-код в backticks НЕ защищён**: `` `{{variables}}` `` отрендерится пустым. Чтобы вывести литеральные двойные фигурные скобки в тексте или таблице, оборачивай в `v-pre`:\n  `<code v-pre>{{variables}}</code>`\n- Это же касается любых других Vue-конструкций (`{{ }}`, директивы) в произвольном тексте страницы.\n\n## Images And Assets Rules\n\n- Картинки для docs клади в `docs/website/public`.\n- Ссылайся на картинки через `withBase`, например:\n  `<img :src=\"withBase('/feature.png')\">`\n- Если страница использует `withBase`, добавь соответствующий script block:\n  `import { withBase } from 'vitepress'`\n- Используй скриншоты только когда они реально объясняют фичу. Не добавляй декоративные изображения.\n\n## README Rules\n\n- Добавляй README-упоминания только для user-facing фич, которые важны на уровне общего обзора проекта.\n- Держи README copy коротким и product-level; подробное использование должно быть в `docs/website/documentation`.\n- Не пиши в README, когда фича была добавлена. Version availability должна жить в docs pages или release notes.\n- Не ставь новую фичу первой автоматически. Сохраняй текущую информационную архитектуру: сначала основные spaces/features, затем широкие workflow helpers, если пользователь не попросил иначе.\n\n## Validation\n\n- Запускай `git diff --check`.\n- Для изменений docs website запускай `pnpm -C docs/website build`.\n- Если нужно форматирование, ограничивай его изменёнными файлами и избегай широкого churn в config-файлах.\n- Не коммить без явной просьбы пользователя. Для commit или PR загружай `github-workflow`.\n\n## Common Mistakes\n\n- Добавлять README-only документацию для фичи, которой нужна настоящая docs page.\n- Забывать VitePress sidebar для новой страницы, которая должна быть в навигации.\n- Добавлять version availability в README.\n- Переносить `<AppVersion>` всего существующего раздела на версию, в которой фича лишь получила улучшение.\n- Создавать отдельный раздел для одношаговой мелкой фичи, которую достаточно упомянуть в существующем разделе.\n- Повторять полное описание cross-cutting фичи на нескольких страницах вместо одного основного места и коротких упоминаний.\n- Использовать callout для обычной инструкции без риска, совместимости или неочевидного поведения.\n- Документировать shortcuts или поведение без проверки реализации.\n- Запускать широкие formatters, которые переписывают существующий стиль docs config.\n- Писать литеральные `{{ ... }}` в инлайн-коде без `v-pre` — VitePress съест их как Vue-интерполяцию.\n","frontmatter":{"name":"documentation-workflow","description":"Use when adding or updating massCode documentation, documenting a new feature, changing docs website pages, adding docs assets, updating the VitePress sidebar, or adding README feature mentions."},"isInternal":false,"tokens":2450,"sizeBytes":10902},{"name":"SKILL.md","path":".agents/skills/electron-api-and-ipc/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/electron-api-and-ipc/SKILL.md","title":"electron-api-and-ipc","category":"anthropic-skill","format":"markdown","content":"---\nname: electron-api-and-ipc\ndescription: Use when changing massCode API routes, DTOs, IPC handlers, Electron bridges, or any renderer-to-main communication and storage-access boundaries.\n---\n\n# Electron API And IPC\n\n## Overview\n\nВсе backend-возможности massCode живут в main process. Renderer получает доступ к данным и системным операциям только через Elysia API или IPC channels.\n\n## Renderer Access Rules\n\n- В renderer для данных используй `import { api } from '~/renderer/services/api'`.\n- В renderer для системных операций используй `ipc.invoke('channel:action', payload)`.\n- Electron API из renderer доступен только через `src/renderer/electron.ts`.\n- Никогда не импортируй storage internals или backend-модули напрямую в renderer.\n\n## New API Endpoints\n\nПри добавлении нового endpoint:\n\n1. создай DTO в `src/main/api/dto/`;\n2. добавь route в `src/main/api/routes/`;\n3. запусти `pnpm api:generate`, чтобы обновить клиент.\n\nНе оставляй API-клиент рассинхронизированным с route/DTO изменениями.\n\n## IPC Conventions\n\n- Для filesystem и system ops используй `ipc.invoke(...)`.\n- Каналы должны укладываться в семейства:\n  - `fs:*`\n  - `system:*`\n  - `db:*` — legacy или migration flows, не основной путь для новой функциональности\n  - `main-menu:*`\n  - `prettier:*`\n  - `spaces:*`\n  - `theme:*`\n\n## Good Boundaries\n\n- Renderer формирует intent и payload.\n- Main/API работает с данными приложения, файловой системой и system APIs.\n- Ответ возвращается обратно в renderer в виде DTO или IPC result, а не через shared mutable backend module.\n\n## Common Mistakes\n\n- Тянуть backend-модуль напрямую в renderer ради “удобства”.\n- Менять DTO/route без `pnpm api:generate`.\n- Добавлять system/file behavior в renderer вместо IPC handler.\n- Добавлять новые `db:*` flows там, где задача должна идти через текущую API/IPC модель приложения.\n- Создавать ad-hoc каналы, которые не укладываются в существующие channel families.\n","frontmatter":{"name":"electron-api-and-ipc","description":"Use when changing massCode API routes, DTOs, IPC handlers, Electron bridges, or any renderer-to-main communication and storage-access boundaries."},"isInternal":false,"tokens":572,"sizeBytes":2565},{"name":"SKILL.md","path":".agents/skills/github-workflow/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/github-workflow/SKILL.md","title":"github-workflow","category":"anthropic-skill","format":"markdown","content":"---\nname: github-workflow\ndescription: Use when working with massCode issues, branches, commits, pull requests, or merge preparation in GitHub.\n---\n\n# github-workflow\n\n## Issue\n\nЕсли работа идёт по issue, читать его через `gh`:\n\n```bash\ngh issue view <number> -R massCodeIO/massCode\n```\n\nЕсли issue описывает bug, не считай его автоматически подтверждённым.\n\nСначала:\n\n1. понять ожидаемое поведение;\n2. проверить текущее поведение в коде или воспроизвести проблему;\n3. подтвердить bug или явно зафиксировать, что он не подтверждается;\n4. только после этого переходить к ветке, фиксу и PR.\n\nЕсли bug не воспроизводится или issue описан неясно:\n\n- не начинать слепую реализацию;\n- сначала сообщить, что проблема не подтверждена, и уточнить условия или шаги воспроизведения.\n\n## Branch\n\nСоздавай ветку от `main` с префиксом по типу изменения (`feat/`, `fix/`, `chore/`, `refactor/`) и коротким описанием. Если работа идёт по issue — уместно добавить номер в конец.\n\n```bash\ngit checkout main && git pull\ngit checkout -b feat/<short-description> main\n```\n\n## PR\n\nЗаголовок PR — conventional commits:\n\n```text\ntype: description\n```\n\nПеред созданием PR предложи заголовок пользователю на подтверждение.\n\nЕсли PR закрывает существующий issue, в описании добавляй:\n\n```text\ncloses #123\n```\n\nПеред PR убедись, что релевантные проверки и тесты для затронутой области действительно прогнаны.\n\nСоздание:\n\n```bash\ngh pr create \\\n  --base main \\\n  --head <branch-name> \\\n  --title \"type: description\" \\\n  --body \"closes #<issue_number>\" \\\n  --assignee @me\n```\n\nЕсли issue нет — в `--body` кратко опиши суть изменений без служебного AI-хвоста.\n\nПосле создания PR предложи пользователю смерджить его в `main`:\n\n```bash\ngh pr merge <pr_number> -R massCodeIO/massCode --squash --delete-branch\n```\n\nПосле merge синхронизируй локальную ветку:\n\n```bash\ngit checkout main && git pull\ngit branch -d <branch-name>\n```\n\n## Commit\n\n- Только однострочный заголовок conventional commit.\n- Используй подходящий scope для коммитов и PR (`feat(notes):`, 'fix(math):).\n- Без тела, без `Co-Authored-By`.\n","frontmatter":{"name":"github-workflow","description":"Use when working with massCode issues, branches, commits, pull requests, or merge preparation in GitHub."},"isInternal":false,"tokens":742,"sizeBytes":2968},{"name":"SKILL.md","path":".agents/skills/release-notes/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/release-notes/SKILL.md","title":"release-notes","category":"anthropic-skill","format":"markdown","content":"---\nname: release-notes\ndescription: Use when generating massCode release notes for a GitHub release. Writes the notes to a gitignored file `docs/releases/<tag>.md` for the user to paste into the GitHub release. Use when summarizing merged PRs of a version into a consistent release notes structure.\n---\n\n# Release Notes\n\n## Overview\n\nЭтот skill генерирует release notes одного релиза `vX.Y.Z` для вставки в GitHub release. Цель — единая повторяемая структура от релиза к релизу.\n\nНе трогай `docs/website/download/latest-release.md` — это отдельная repo-страница со своим форматом.\n\n## Source Of Truth\n\n- Содержимое выводи из merged PR между предыдущим и новым тегом, не из памяти.\n- Список изменений бери так:\n  `git log --first-parent --oneline <prev-tag>..<new-tag>` (например `v5.5.0..v5.6.0`).\n- Если новый тег ещё не создан, используй `<prev-tag>..HEAD` и спроси/подтверди номер новой версии.\n- Поведение значимых фич проверяй в коде или в `docs/website/documentation`, прежде чем формулировать, если оно неочевидно из заголовка PR.\n\n## Output\n\n- Записывай результат в файл `docs/releases/<new-tag>.md` (например `docs/releases/v5.6.0.md`). Папка `docs/releases` в `.gitignore`, это рабочий буфер, а не часть репозитория.\n- Пиши именно в файл, а не выводом в терминал: так пользователь копирует чистый markdown без переносов строк, которые добавляет терминал.\n- После записи коротко сообщи путь к файлу и при необходимости покажи итог. Не коммить файл.\n\n## Format\n\nФайл содержит один markdown-блок в этой структуре и порядке:\n\n```\n## <Feature Name>\n\n<1-2 абзаца: что это и что даёт пользователю.>\n\n## <Another Feature Name>\n\n<1-2 абзаца.>\n\n## Workflow Improvements\n\n- <мелкое улучшение>\n- <мелкое улучшение>\n\n## Fixes\n\n- <исправление>\n- <исправление>\n\n**Full Changelog**: https://github.com/massCodeIO/massCode/compare/<prev-tag>...<new-tag>\n```\n\nПравила структуры:\n\n- Начинай прямо с тематических `##`-разделов. Не добавляй заголовок версии `# vX.Y.Z` (его даёт сам GitHub release), frontmatter или `<AssetsDownload />` — это артефакты repo-страницы.\n- Один `##`-раздел на каждую значимую фичу или связную группу фич.\n- `## Workflow Improvements` и `## Fixes` включай только если для них есть содержимое.\n- Compare-ссылка всегда последней строкой, с актуальными предыдущим и новым тегами.\n\n## What To Include\n\n- User-facing изменения: новые spaces и фичи, заметные улучшения workflow, видимые исправления.\n- Крупную фичу выноси в отдельный `##`-раздел с 1-2 абзацами о пользе для пользователя.\n- Мелкие улучшения собирай в `## Workflow Improvements` буллетами.\n- Исправления собирай в `## Fixes` буллетами, по одному на исправление.\n\n## What To Omit\n\n- Чисто внутренние коммиты: `ci`, `build`, `chore`, рефакторинг, bump зависимостей, релизные служебные коммиты (`build: release vX.Y.Z`).\n- Исключение: выноси платформенные изменения, заметные пользователю (например code signing и notarization на macOS), в `## Workflow Improvements`.\n- Не описывай детали реализации; пиши о результате для пользователя.\n\n## Writing Style\n\n- Английский, спокойный фактический тон. Что делает фича и зачем она пользователю, без маркетинговых превосходных степеней.\n- Никаких em dash. Это общее правило репозитория.\n- Имена spaces пиши консистентно: `Code`, `Notes`, `Math Notebook`, `Drawings`, `HTTP`, `Tools`. Не смешивай `Code` и `Snippets` как имя пространства.\n- `snippet` — единица контента внутри пространства Code, а не имя пространства. В Fixes допустимо «snippet fences», «snippet sync», но пространство всё равно называется Code.\n- Code identifiers, расширения файлов и токены оборачивай в backticks (`` `.excalidraw` ``, `` `@` ``, `` `Esc` ``).\n- Shortcuts указывай как в интерфейсе; macOS и Windows/Linux варианты различай, если они отличаются.\n\n## Common Mistakes\n\n- Перечислять коммиты дословно вместо группировки в user-facing разделы.\n- Включать `ci` / `build` / `chore` шум, который не виден пользователю.\n- Добавлять `# vX.Y.Z`, frontmatter или `<AssetsDownload />` (это формат repo-страницы, а не GitHub release).\n- Выводить нотис простыней в терминал вместо файла `docs/releases/<new-tag>.md` (терминал ломает переносы строк при копировании).\n- Коммитить файл из `docs/releases` — это игнорируемый рабочий буфер.\n- Смешивать имена пространств (`Code` против `Snippets`) внутри одного документа.\n- Описывать детали реализации вместо пользы для пользователя.\n- Забыть обновить compare-ссылку на актуальные теги.\n- Использовать em dash вопреки правилу репозитория.\n","frontmatter":{"name":"release-notes","description":"Use when generating massCode release notes for a GitHub release. Writes the notes to a gitignored file `docs/releases/<tag>.md` for the user to paste into the GitHub release. Use when summarizing merged PRs of a version into a consistent release notes structure."},"isInternal":false,"tokens":1656,"sizeBytes":6670},{"name":"SKILL.md","path":".agents/skills/spaces-architecture/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/spaces-architecture/SKILL.md","title":"spaces-architecture","category":"anthropic-skill","format":"markdown","content":"---\nname: spaces-architecture\ndescription: Use when working on massCode spaces such as code, notes, math, or tools, especially when changing their state, behavior, synchronization, or spaces IPC channels.\n---\n\n# Spaces Architecture\n\n## Overview\n\nmassCode использует систему Spaces для разделения функциональных областей. Это не просто UI tabs: у каждого space есть собственное состояние, свои правила обновления и свой способ синхронизации с данными в vault.\n\n## Space Model\n\n- `code` — snippets, folders, tags\n- `notes` — notes, folders, tags, markdown-based flows\n- `math` — calculation sheets и состояние math notebook\n- `tools` — developer utilities\n\nОсновные определения живут в `src/renderer/spaceDefinitions.ts`.\n\n## Space State Storage\n\n- Состояние каждого space хранится в `__spaces__/{spaceId}/.state.yaml` внутри vault.\n- Runtime helpers:\n  - `src/main/storage/providers/markdown/runtime/spaces.ts`\n  - `src/main/storage/providers/markdown/runtime/spaceState.ts`\n- Директория `__spaces__/` — служебная часть vault для состояния spaces.\n\n## Persistence Rules\n\n- Запись состояния spaces использует ту же debounce/flush инфраструктуру, что и `state.json`.\n- Не ломай совместимость с `pendingStateWriteByPath` и flush-on-exit поведением.\n- Если меняешь способ записи, учитывай сценарий завершения приложения до явного ручного flush.\n\n## IPC Rules\n\n- Space-specific IPC handlers живут в `src/main/ipc/handlers/spaces.ts`.\n- Текущие math handlers:\n  - `spaces:math:read`\n  - `spaces:math:write`\n- Если добавляется новый `spaces:*` flow, он должен работать через общую модель состояния spaces, а не в обход неё.\n\n## Space-Aware Sync\n\n- `system:storage-synced` обновляет активное пространство через `getActiveSpaceId()`.\n- Ожидаемое поведение:\n  - `code` → refresh folders + snippets\n  - `notes` → refresh notes + note folders\n  - `math` → `reloadFromDisk()` через `useMathNotebook()`\n  - `tools` → no-op\n- Изменения, которые уже сохранены в vault, должны вызывать `markPersistedStorageMutation()`, чтобы не создавать sync loops.\n\n## Common Mistakes\n\n- Считать spaces только UI-концепцией и забывать, что у них есть собственное состояние и правила синхронизации.\n- Писать состояние space в обход общих markdown runtime helpers.\n- Добавлять mutation без `markPersistedStorageMutation()`.\n- Ломать согласованность между состоянием space, helpers и sync behavior.\n","frontmatter":{"name":"spaces-architecture","description":"Use when working on massCode spaces such as code, notes, math, or tools, especially when changing their state, behavior, synchronization, or spaces IPC channels."},"isInternal":false,"tokens":727,"sizeBytes":3147},{"name":"SKILL.md","path":".agents/skills/ui-foundations/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/ui-foundations/SKILL.md","title":"ui-foundations","category":"anthropic-skill","format":"markdown","content":"---\nname: ui-foundations\ndescription: Use when defining or reviewing massCode UI foundation rules such as typography, renderer styling consistency, TailwindCSS v4 usage, and when raw markup starts competing with established UI text patterns.\n---\n\n# UI Foundations\n\n## Overview\n\nUI в massCode должен оставаться визуально консистентным. Этот skill отвечает за базовые styling decisions: как относиться к typography, когда использовать established text patterns и как не скатываться в разрозненный renderer styling.\n\n## Core Rules\n\n- Базовая styling system в renderer строится на TailwindCSS v4.\n- Новые UI-экраны и состояния должны продолжать существующий visual language, а не вводить локальные правила “для одного места”.\n- Для стандартного app UI предпочитай семантические токены вроде `bg-background`, `text-muted-foreground`, `border-border`, `border-destructive/*` вместо raw palette-классов вроде `bg-white`, `text-black`, `text-green-500`, `bg-slate-900`.\n- Typography по умолчанию строится через `UiText`.\n- Не заменяй `UiText` на произвольный набор `text-*`, `font-*`, `text-muted-foreground`, если подходящий variant уже существует.\n- Если `UiText` почти подходит, лучше добавить точечные классы поверх него, чем уходить в raw typography markup.\n\n## Typography\n\n- `UiText` — базовый источник правды для текстовых размеров и muted-state.\n- `caption` и `xs` — подписи, helper text, secondary labels.\n- `sm` и `base` — основной интерфейсный текст.\n- `lg` и `xl` — усиленные title/value cases, когда это действительно нужно по hierarchy.\n- `font-mono` — только для code-like content, IDs, counts with alignment needs, readonly generated output и подобных случаев.\n- Для uppercase labels используй существующий pattern через `UiText` или согласованный tracking/uppercase стиль, а не случайную смесь utility classes в каждом месте.\n\n## Spacing And Layout Rhythm\n\n- Корневые screen/container wrappers обычно живут в ритме `space-y-4` или `space-y-6`.\n- Внутри компактных секций чаще всего `space-y-2` или `space-y-3`.\n- Grid gaps по умолчанию: `gap-2`, `gap-3`, `gap-4` в зависимости от плотности.\n- Не придумывай локальный spacing-scale для одного экрана, если существующие интервалы уже покрывают задачу.\n- Повторяющиеся content blocks должны иметь одинаковый padding и vertical rhythm.\n\n## Radius And Shadows\n\n- `rounded-md` — controls, inline boxes, compact containers.\n- `rounded-lg` — card-like blocks, dialogs, overlays, dashboard sections.\n- `rounded-xl` — preview-heavy surfaces и крупные visual blocks.\n- `rounded-full` — pills, badges, circular handles.\n- `shadow-xs` — inputs, buttons, small controls.\n- `shadow-md` и `shadow-lg` — overlays, popovers, previews, где elevation реально нужна.\n- Не вводи произвольные `rounded-[...]` и `shadow-[...]`, если стандартные токены уже подходят.\n\n## Exceptions\n\n- Raw colors допустимы, если цвет является частью самих данных или preview:\n  color pickers, contrast previews, code/image export backgrounds, diagram or visualizer nodes.\n- Если цвет вычисляется из контента или нужен для корректного контраста на пользовательском фоне, raw class или inline style допустимы.\n- Исключения не должны становиться поводом тащить raw palette в обычный application chrome.\n\n## When To Prefer This Skill\n\n- Нужно понять, как оформлять текст и подписи в новом UI.\n- Есть соблазн писать raw Tailwind typography вместо существующего text pattern.\n- В экране начинают появляться локальные styling rules, которые расходятся с остальным renderer UI.\n- Нужно принять решение на уровне визуальной базы, а не конкретного button/input/dialog.\n\n## Common Mistakes\n\n- Размазывать локальные визуальные исключения по фичам.\n- Тащить raw palette в обычный app UI без реальной причины.\n- Писать текст напрямую через произвольные utility classes там, где подходит `UiText`.\n- Делать новый экран со своим spacing rhythm вместо существующего scale.\n- Случайно смешивать small-control radii и preview-surface radii в одном и том же UI слое.\n- Считать Tailwind поводом делать каждый экран визуально “с нуля”.\n","frontmatter":{"name":"ui-foundations","description":"Use when defining or reviewing massCode UI foundation rules such as typography, renderer styling consistency, TailwindCSS v4 usage, and when raw markup starts competing with established UI text patterns."},"isInternal":false,"tokens":1297,"sizeBytes":5638},{"name":"SKILL.md","path":".agents/skills/ui-primitives/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/ui-primitives/SKILL.md","title":"ui-primitives","category":"anthropic-skill","format":"markdown","content":"---\nname: ui-primitives\ndescription: Use when building or refactoring massCode UI components with local Ui primitives or Shadcn, especially for cn, cva, notifications, and rules against reimplementing basic controls.\n---\n\n# UI Primitives\n\n## Overview\n\nБазовые UI-элементы в massCode должны собираться из существующих `Ui*` компонентов и Shadcn-паттернов. Этот skill отвечает за component-level usage rules, а не за общую визуальную базу.\n\n## Component Usage\n\n- Локальные UI-компоненты доступны через auto-import с префиксом `Ui`.\n- Базовые элементы вроде button, input, checkbox, action button не переизобретай на сыром HTML, если есть готовый `Ui*` вариант.\n- Если нужного элемента нет, сначала создай его в `src/renderer/components/ui/`, потом используй в фиче.\n\n## Buttons\n\n- Primary action должен быть явным и не конкурировать с несколькими равноправными CTA в одном контейнере.\n- Icon-only actions должны быть понятны по контексту и иметь tooltip или другой доступный label path.\n- Loading и pending actions должны использовать существующий button pattern, а не ad-hoc “disabled text swap”.\n- Destructive actions не должны выглядеть как обычные secondary controls.\n\n## Cards And Containers\n\n- Для автономных panel-like блоков используй существующий `Card` / `Ui*` container pattern, если он уже есть в области.\n- Внутренние muted blocks не нужно пересобирать разными `div`-паттернами в каждой фиче.\n- Repeated panel structure должна переезжать в shared primitive или local feature primitive, а не копироваться markup-в-маркап.\n\n## Readonly And Copyable Content\n\n- Длинный readonly output, generated text, URLs и similar content не показывай как “обычный disabled input”, если это ухудшает чтение.\n- Для copy flows используй существующий copy pattern и уведомления через `useSonner()`.\n- Readonly content должен оставаться визуально читаемым и удобно копируемым.\n\n## Styling Helpers\n\n- Для variants используй `cva`.\n- Для склейки классов используй `cn()`.\n- Не делай variants вручную строковыми `if`-цепочками там, где нужен нормальный variant API.\n\n## Shadcn Rules\n\n- Shadcn-компоненты импортируй вручную из `@/components/ui/shadcn/*`.\n- Для namespace-based компонентов используй паттерн вроде `import * as Dialog from '@/components/ui/shadcn/dialog'`.\n\n## Notifications\n\n- Для уведомлений используй `useSonner()`.\n- Не добавляй локальную, параллельную систему toast/notification внутри фичи.\n\n## Tooltip, Popover, Overlay\n\n- Tooltip — для короткого пояснения.\n- Popover — для richer inline content, picker-like content или contextual controls.\n- Не заменяй их ad-hoc overlay-разметкой без необходимости.\n- Validation и inline guidance должны использовать существующие tooltip/popover primitives, если проект уже их применяет в аналогичных местах.\n\n## Dialog Focus\n\n- Во всех диалогах явно управляй фокусом при открытии и закрытии. Не допускай автоматического фокуса на крестике закрытия и появления tooltip на кнопке открытия из-за возврата фокуса после закрытия.\n- По умолчанию отменяй стандартный autofocus на `DialogContent`:\n\n  ```vue\n  @open-auto-focus=\"(e) => e.preventDefault()\"\n  @close-auto-focus=\"(e) => e.preventDefault()\"\n  ```\n\n- Исключение — намеренный фокус на конкретном поле или действии, нужном для сценария диалога. Задавай такую цель явно; при закрытии выбирай цель возврата фокуса без побочного показа tooltip.\n- Сохраняй focus trap и клавиатурную навигацию. Проверяй открытие и закрытие мышью и клавиатурой, включая Escape.\n\n## Common Mistakes\n\n- Писать ещё одну кнопку или input с нуля “потому что быстрее”.\n- Склеивать сложные conditional classes без `cn()`.\n- Дублировать существующий primitive внутри feature directory вместо общего `src/renderer/components/ui/`.\n- Использовать disabled input как универсальный readonly display surface.\n- Делать overlay pattern вручную там, где уже есть Shadcn primitive.\n- Смешивать правила primitives с вопросами визуальной базы, которые должны идти в `ui-foundations`.\n","frontmatter":{"name":"ui-primitives","description":"Use when building or refactoring massCode UI components with local Ui primitives or Shadcn, especially for cn, cva, notifications, and rules against reimplementing basic controls."},"isInternal":false,"tokens":1306,"sizeBytes":5709},{"name":"SKILL.md","path":".agents/skills/vue-renderer-standards/SKILL.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/.agents/skills/vue-renderer-standards/SKILL.md","title":"vue-renderer-standards","category":"anthropic-skill","format":"markdown","content":"---\nname: vue-renderer-standards\ndescription: Use when editing massCode renderer code in Vue 3, especially for script setup patterns, import rules, composables, shared state, and renderer-side conventions.\n---\n\n# Vue Renderer Standards\n\n## Overview\n\nRenderer в massCode строится на Vue 3 Composition API с `<script setup lang=\"ts\">`. Здесь важны строгие import rules, composable-first state sharing и запрет на прямой доступ к backend-возможностям.\n\n## Component Pattern\n\n- Используй Vue 3 Composition API и `<script setup lang=\"ts\">`.\n- Vue core (`ref`, `computed`, `watch`, `onMounted` и подобные) не импортируй вручную: они auto-imported.\n- Проектные компоненты из `src/renderer/components/` тоже не импортируй вручную: они auto-imported.\n- Локальную логику компонента держи в script, а не в template.\n\n## Manual Imports Only Where Required\n\nВсегда импортируй вручную:\n\n- composables из `@/composables`;\n- utils из `@/utils`;\n- `@vueuse/core`;\n- Electron bridge из `@/electron`;\n- Shadcn UI из `@/components/ui/shadcn/*`.\n\n## Shared State\n\n- Глобальное shared state реализуется composables без Pinia/Vuex.\n- Reactive state, который должен шариться между компонентами, объявляй на module level, вне экспортируемой функции composable.\n- Persistent UI/settings state храни через `store` из `@/electron`:\n  - `store.app` для UI state;\n  - `store.preferences` для user preferences.\n\n## VueUse First\n\n- Перед написанием нового composable сначала проверь, нет ли подходящего решения в `@vueuse/core`.\n- Кастомный composable добавляй только если готового utility реально нет.\n\n## Renderer Boundaries\n\n- Renderer не импортирует storage internals или backend-модули доступа к данным напрямую.\n- Renderer не обращается напрямую к Node.js, filesystem или storage runtime.\n- Доступ к main process возможен только через `api` или `ipc`.\n\n## Common Mistakes\n\n- Ручной импорт `ref` / `computed` / `watch`.\n- Ручной импорт локальных project components.\n- Локальный state внутри composable, который должен быть общим между несколькими компонентами.\n- Попытка “срезать путь” и импортировать backend-модуль прямо в renderer.\n","frontmatter":{"name":"vue-renderer-standards","description":"Use when editing massCode renderer code in Vue 3, especially for script setup patterns, import rules, composables, shared state, and renderer-side conventions."},"isInternal":false,"tokens":662,"sizeBytes":2786},{"name":"index.md","path":"docs/website/documentation/tools/index.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/docs/website/documentation/tools/index.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"---\ntitle: Overview\ndescription: \"Use built-in developer tools in massCode for JSON diffing, text conversion, hashing, HMAC generation, URL parsing, and other quick tasks.\"\n---\n\n# Tools overview\n\nTools is for the small developer tasks that should take seconds, not a trip to a random website. Use it when you need to compare JSON, convert, encode, hash, or generate something quickly without leaving massCode.\n\nThe available tools are grouped by category:\n\n## Compare\n\n### [JSON Diff](/documentation/tools/json-diff)\n\nCompare two JSON documents side by side with validation, filters, and a tree diff for nested changes.\n\n## Text tools\n\n### Case Converter\n\nConvert text between common casing formats such as camelCase, snake_case, kebab-case, and uppercase.\n\n### Slug Generator\n\nTurn free-form text into a URL-friendly slug.\n\n### URL Parser\n\nSplit a URL into its protocol, host, path, query, and hash parts.\n\n### Line Break Normalizer\n\nRemove hard wraps from copied terminal output while preserving Markdown lists, tables, quotes, commands, and code blocks. The same normalization is available from the **Editor** menu in Code and Notes.\n\n## Cryptography & Security\n\n### Hash Generators\n\nGenerate one-way hashes from text input.\n\n### HMAC Generators\n\nBuild keyed message authentication hashes from a secret and a message.\n\n### Password Generators\n\nGenerate random passwords with configurable character sets.\n\n### UUID Generators\n\nCreate unique identifiers for fixtures, payloads, and test data.\n\n## Encoders & Decoders\n\n### URL\n\nEncode or decode URL strings safely.\n\n### Base64\n\nConvert plain text to and from Base64.\n\n### JSON ⇄ TOML/XML/YAML\n\nTransform JSON between common structured data formats.\n\n### Text ⇄ ASCII/Binary/Unicode\n\nConvert text into different low-level or escaped representations and back.\n\n### Color Converter\n\nTranslate color values between supported formats.\n\n## Generators\n\n### JSON Generator\n\nBuild mock JSON payloads with typed fields for testing and demos.\n\n### Lorem Ipsum Generator\n\nGenerate placeholder words, sentences, or paragraphs.\n","frontmatter":{"title":"Overview","description":"Use built-in developer tools in massCode for JSON diffing, text conversion, hashing, HMAC generation, URL parsing, and other quick tasks."},"isInternal":false,"tokens":418,"sizeBytes":2068},{"name":"json-diff.md","path":"docs/website/documentation/tools/json-diff.md","rawUrl":"https://raw.githubusercontent.com/massCodeIO/massCode/HEAD/docs/website/documentation/tools/json-diff.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"---\ntitle: JSON Diff\ndescription: \"Compare two JSON documents side by side in massCode with validation, filters, and a tree diff.\"\n---\n\n# JSON Diff\n\nJSON Diff lets you compare two JSON documents side by side without leaving massCode. It is useful for checking API responses, fixture changes, configuration edits, and generated JSON payloads.\n\n## Where to find it\n\nOpen **Tools** in the left rail, then go to **Compare** → **JSON Diff**.\n\n## What it does\n\n- Shows the original and modified JSON in two editors\n- Validates each side independently\n- Formats valid JSON on paste and blur\n- Builds a tree-based diff for nested objects and arrays\n- Highlights added, removed, and modified values\n- Filters the diff by change type\n- Keeps both input editors scrolled in sync\n- Uses the same editor font settings as the main code editor\n\n## How to use it\n\n1. Paste the original JSON into the left editor.\n2. Paste the modified JSON into the right editor.\n3. Review the diff tree below the editors.\n4. Use the checkboxes to focus on added, removed, or modified nodes.\n5. Expand or collapse nested objects and arrays as needed.\n\n## Notes\n\n- Both inputs must contain valid JSON before the diff viewer appears.\n- Validation errors are shown under each editor separately.\n- If only one side is filled, the tool stays in the empty state instead of guessing missing data.\n- Array move visualization is not exposed as a separate state. In this version, the tool prefers predictable output over compact move semantics.\n","frontmatter":{"title":"JSON Diff","description":"Compare two JSON documents side by side in massCode with validation, filters, and a tree diff."},"isInternal":false,"tokens":318,"sizeBytes":1504}],"systemPromptSnippet":"<yakaai_skills repo=\"massCodeIO/massCode\">\n<!-- File: AGENTS.md (Tokens: ~1441 | Category: root-instruction) -->\n# Точка входа для агента massCode\n\nОтвечай всегда на русском.\n\nmassCode — это приложение на Electron + Vue 3 + TypeScript с TailwindCSS v4 в renderer, API-маршрутами на Elysia в main process, markdown vault как основным хранилищем пользовательского контента в v5 и `store.app` / `store.preferences` для локального UI state и настроек.\n\n## Всегда действующие правила\n\n- Следуй YAGNI. Предпочитай минимальную корректную реализацию вместо спекулятивных абстракций.\n- Соблюдай границы слоёв: renderer не должен напрямую обращаться к Node.js, filesystem или DB. Используй API или IPC.\n- Никогда не хардкодь пользовательские строки. Используй систему локализации.\n- Не запускай lint или тесты по всему проекту для локальной задачи. Ограничивай команды затронутыми файлами или директориями.\n- После изменений API DTO или routes запускай `pnpm api:generate`.\n- После изменений locale-файлов запускай `pnpm i18n:copy`.\n- Если задача совпадает по теме с одним из skills ниже, загружай этот skill до внесения изменений.\n\n## Skills\n\n- `.agents/skills/architecture-standards/SKILL.md`\n  Используй первым для общих правил репозитория: архитектура, naming, декомпозиция и выбор следующего skill.\n- `.agents/skills/vue-renderer-standards/SKILL.md`\n  Используй для работы с Vue renderer: `<script setup lang=\"ts\">`, правила auto-import, composables, shared state и renderer-side паттерны.\n- `.agents/skills/ui-foundations/SKILL.md`\n  Используй для базовых UI-правил: Tailwind v4, typography через `UiText` и согласованных styling decisions для renderer UI.\n- `.agents/skills/ui-primitives/SKILL.md`\n  Используй для component-level UI работы: `Ui*` components, Shadcn imports, `cn`, `cva`, notifications и правил против переизобретения primitives.\n- `.agents/skills/electron-api-and-ipc/SKILL.md`\n  Используй для API routes, DTO, IPC handlers, renderer-to-main communication и границ Electron-интеграции.\n- `.agents/skills/api-and-typing/SKILL.md`\n  Используй для generated API types, DTO-derived renderer typing и решения, когда локальный UI type оправдан, а когда нужно переиспользовать существующие API types.\n- `.agents/skills/spaces-architecture/SKILL.md`\n  Используй при изменениях, связанных с `code` / `notes` / `math` / `tools`, markdown-space state, sync behavior или `spaces:*` IPC.\n- `.agents/skills/i18n/SKILL.md`\n  Используй для правил локализации, размещения locale keys, `i18n.t(...)` и требования не хардкодить строки.\n- `.agents/skills/documentation-workflow/SKILL.md`\n  Используй для добавления или обновления документации, страниц `docs/website/documentation`, sidebar, assets и README-упоминаний фич.\n- `.agents/skills/release-notes/SKILL.md`\n  Используй для генерации release notes нового релиза в игнорируемый файл `docs/releases/<tag>.md` для вставки в GitHub release: группировка merged PR в user-facing разделы и compare-ссылка.\n- `.agents/skills/development-workflow/SKILL.md`\n  Используй для repo-specific workflow rules: scoped lint/test команды и обязательные follow-up шаги после изменений source-of-truth файлов.\n- `.agents/skills/github-workflow/SKILL.md`\n  Используй для massCode git и GitHub workflow: issue, ветки, commits, PR и подготовки к merge.\n\n## Рекомендуемый порядок загрузки\n\n- Широкая или неочевидная задача: начни с `architecture-standards`, затем загрузи профильный skill.\n- Renderer UI задача: `architecture-standards` → `vue-renderer-standards` → `ui-foundations` → `ui-primitives`.\n- API / IPC / Electron задача: `architecture-standards` → `electron-api-and-ipc`.\n- Generated types / renderer typing задача: `architecture-standards` → `api-and-typing`.\n- Spaces задача: `architecture-standards` → `spaces-architecture`.\n- Задача про текст и локализацию: `i18n`.\n- Задача про документацию или README: `documentation-workflow`.\n- Задача про release notes нового релиза: `release-notes`.\n- Workflow-чувствительная задача: `development-workflow`.\n- Задача про git / branch / commit / PR: `github-workflow`.\n\n## Основной стек\n\n- Framework: Vue 3, Composition API, `<script setup lang=\"ts\">`\n- Styling: TailwindCSS v4, `tailwind-merge`, `cva`\n- UI: локальные `src/renderer/components/ui`, Shadcn поверх `reka-ui`, `lucide-vue-next`\n- State: composables, без Pinia/Vuex\n- Backend: Electron main, Elysia API, markdown vault для контента и `electron-store` для локального состояния приложения\n- Utilities: `@vueuse/core`, `vue-sonner`\n\n<!-- File: CLAUDE.md (Tokens: ~3 | Category: claude-rule) -->\nAGENTS.md\n\n<!-- File: .agents/skills/api-and-typing/SKILL.md (Tokens: ~506 | Category: anthropic-skill) -->\n---\nname: api-and-typing\ndescription: Use when defining or reviewing massCode renderer types that come from generated API clients or DTOs, especially when deciding whether to reuse existing API shapes, derive narrower local types, or introduce a UI-only model.\n---\n\n# API And Typing\n\n## Overview\n\nДля massCode API types считаются generated-first. Если данные пришли из `~/renderer/services/api/generated` или соответствуют DTO из `src/main/api/dto`, сначала используй существующие типы и utility typing, а не придумывай новый interface рядом с компонентом.\n\n## Core Rules\n\n- Ручные дубли API response types не пиши.\n- Сначала ищи тип в `~/renderer/services/api/generated`.\n- Если прямого export нет, выводи нужный shape через `Pick`, `Omit`, indexed access, `Parameters`, `ReturnType`, `Awaited`, `NonNullable`.\n- Локальный тип допустим только как UI-only model, form model, derived display model или narrow type после нормального data narrowing.\n\n## Good Uses Of Local Types\n\n- Узкий renderer shape после того, как nullable API data уже очищена в одном месте.\n- View-model для dashboard card, graph node, readonly row или editor-side helper, если он не равен transport shape.\n- Тип аргумента, выводимый из существующего composable или API method через `Parameters` / `ReturnType`.\n\n## Bad Uses Of Local Types\n\n- Полный дубль `SnippetsResponse`, `NotesDashboardResponse`, `TagsResponse` и других generated types.\n- Новый interface “для удобства”, если можно взять одну ветку из existing response type.\n- Копирование DTO shape в renderer file, хотя он уже импортируемый.\n\n## Common Mistakes\n\n- Сначала придумать локальный interface, а потом уже искать generated type.\n- Смешать transport shape и UI view-model без явного adapter step.\n- Тащить глубоко в UI сырые nullable API поля вместо одного нормального normalization place.\n\n<!-- File: .agents/skills/architecture-standards/SKILL.md (Tokens: ~1130 | Category: anthropic-skill) -->\n---\nname: architecture-standards\ndescription: Use when working in massCode and you need repo-wide architecture rules, naming conventions, decomposition boundaries, or guidance on which massCode skill to load next.\n---\n\n# Architecture Standards\n\n## Overview\n\nБазовый принцип проекта: **YAGNI и простота прежде всего**. Не усложняй код ради гипотетических сценариев, не строй абстракции без повторяющейся потребности и не размывай границы между renderer, API и main.\n\n## Core Rules\n\n- Соблюдай разделение слоёв:\n  - Renderer: только UI, composables, вызовы `api.*` и `ipc.invoke(...)`.\n  - API: маршруты Elysia, DTO, orchestration и доступ к сервисам и данным приложения.\n  - Main: системные интеграции, IPC handlers, lifecycle и слой данных приложения.\n- Data flow по умолчанию: Renderer → API / IPC → service / data layer → response.\n- Vue-компоненты называй в `PascalCase`.\n- TypeScript-файлы называй в `camelCase`.\n- Composables именуй с префиксом `use`, а имя файла должно совпадать с экспортируемой функцией.\n\n## YAGNI Guardrails\n\nПризнаки overengineering:\n\n- функция страхуется от кейса, которого реально не существует;\n- factory или wrapper используется ровно в одном месте и не скрывает состояние;\n- abstraction-for-abstraction без повторяющейся боли;\n- константы, паттерны и конфигурации придуманы заранее, а не из реальной потребности.\n\n## Component Decomposition\n\n- Если компонент становится больше примерно `300` строк или держит `3+` несвязанных обязанности, дели его.\n- Порядок разбиения:\n  1. вынеси константы и статические данные;\n  2. вынеси чистые функции в utils, только если это реально переиспользуется;\n  3. перемести состояние и эффекты в composable;\n  4. разбей шаблон на локальные child components.\n- Не держи в `<template>` логику сложнее тернарного оператора.\n\n## Feature Subdirectories\n\n- Если часть домена выросла в отдельный subsystem, группируй локальные компоненты, helpers, tests и fixtures в поддиректорию.\n- Внутри поддиректории не повторяй полный родительский префикс в именах файлов.\n- Локальные файлы держи рядом с фичей. Shared-код, который нужен нескольким областям, оставляй выше уровнем.\n\n## When to Load Other Skills\n\n- Vue renderer, auto-imports, composables, shared state:\n  `vue-renderer-standards`\n- визуальная база, typography, renderer styling decisions:\n  `ui-foundations`\n- `Ui*`, Shadcn, `cn`, `cva`, notifications:\n  `ui-primitives`\n- API routes, DTO, IPC, Electron boundaries:\n  `electron-api-and-ipc`\n- generated API types, utility typing, локальные view-model:\n  `api-and-typing`\n- `code` / `notes` / `math` / `tools`, состояние spaces и их синхронизация:\n  `spaces-architecture`\n- i18n, locale keys, `i18n.t(...)`:\n  `i18n`\n- docs website, docs sidebar, скриншоты, README-упоминания фич:\n  `documentation-workflow`\n- scoped lint/test и follow-up commands:\n  `development-workflow`\n\n## Common Mistakes\n\n- Тянуть DB или filesystem knowledge в renderer.\n- Раздувать один компонент до “оркестратора всего”.\n- Выносить абстракцию до появления второй реальной точки использования.\n- Размазывать одну фичу по плоской структуре файлов, когда ей уже нужен локальный subdirectory.\n- Придумывать локальные typing-паттерны, хотя для них уже пора иметь отдельный skill.\n\n<!-- File: .agents/skills/development-workflow/SKILL.md (Tokens: ~438 | Category: anthropic-skill) -->\n---\nname: development-workflow\ndescription: Use when following massCode repo workflow rules, especially for scoped lint and test commands, or when changes require required follow-up commands like code generation or locale sync.\n---\n\n# Development Workflow\n\n## Overview\n\nВ massCode workflow rules считаются частью качества изменений. Для локальной задачи команды должны быть точечными, а изменения source-of-truth файлов должны сопровождаться обязательными follow-up шагами.\n\n## Linting Rules\n\n- Всегда запускай lint только по затронутым файлам или директориям.\n- Никогда не запускай lint по всему проекту во время локальной задачи.\n- Используй scoped commands вроде:\n  - `pnpm lint <path>`\n  - `pnpm lint:fix <path>`\n\n## Testing Rules\n\n- Всегда запускай тесты только по затронутым файлам или директориям.\n- Никогда не запускай весь test suite без явной необходимости.\n- Используй scoped commands вроде:\n  - `pnpm test <path>`\n  - `pnpm test:watch <path>`\n\n## Required Follow-Up Commands\n\n- Изменил API DTO/routes → `pnpm api:generate`\n- Изменил locale-файлы → `pnpm i18n:copy`\n\n## Common Mistakes\n\n- Прогонять весь lint/test suite для маленькой точечной правки.\n- Менять source-of-truth файлы и забывать generation/sync шаг.\n- Запускать “на всякий случай” широкие команды вместо минимального релевантного набора.\n\n<!-- File: .agents/skills/documentation-workflow/SKILL.md (Tokens: ~2450 | Category: anthropic-skill) -->\n---\nname: documentation-workflow\ndescription: Use when adding or updating massCode documentation, documenting a new feature, changing docs website pages, adding docs assets, updating the VitePress sidebar, or adding README feature mentions.\n---\n\n# Documentation Workflow\n\n## Overview\n\nДокументация massCode живёт в VitePress сайте в `docs/website/documentation`. README — это общий обзор проекта, а не источник детального описания фич.\n\n## Documentation Surfaces\n\n- Документация фич: `docs/website/documentation/**`\n- Sidebar документации: `docs/website/.vitepress/config.mts`\n- Assets документации: `docs/website/public/**`\n- Overview документации: `docs/website/documentation/index.md`\n- Overview проекта: `README.md`\n\n## Core Rules\n\n- Проверяй поведение фичи в коде или существующей документации; не документируй по памяти.\n- Используй `rg`, чтобы найти связанные страницы, скриншоты, shortcuts, labels и существующие формулировки.\n- Если целевая версия известна, используй именно её. Если версия неизвестна, не придумывай её.\n- Пользовательская документация сайта пишется на английском, в стиле существующих docs pages.\n- Добавляй или обновляй наиболее конкретную страницу в `docs/website/documentation`.\n- Для новых страниц используй frontmatter с `title` и `description`.\n- Добавляй страницу в `docs/website/.vitepress/config.mts` только если она должна появиться в навигации.\n- Ссылайся из `docs/website/documentation/index.md` только на широкие, cross-cutting фичи.\n- Пиши короткими task-oriented секциями. Предпочитай пользовательские флоу, а не детали реализации.\n- Shortcuts документируй через `<kbd>...</kbd>` и указывай macOS плюс Windows/Linux варианты, если они отличаются.\n\n## Version Availability\n\n- Перед добавлением или изменением `<AppVersion>` проверяй историю фичи в коде, документации или предыдущем релизном теге.\n- Считай `<AppVersion text=\">=x.y\" />` минимальной версией, где появилась ровно описываемая возможность, а не версией её последнего улучшения.\n- Ставь marker на уровне страницы или общего раздела только когда вся описываемая сущность впервые появилась в этой версии.\n- Если новый релиз расширяет существующую фичу, сохраняй её исходный marker или отсутствие marker, а новую версию указывай только у отдельного подпункта или предложения про улучшение.\n- Разделяй смешанное описание на базовую возможность и versioned enhancement, если общий marker создаёт впечатление, что старая возможность раньше была недоступна.\n- Не добавляй version marker для bugfix или внутренней переработки без нового пользовательского сценария. Локально отмечай изменение формата хранения, если оно влияет на совместимость.\n\nПример: если custom folder icons существуют с 3.7, а Emoji и Upload добавлены в 5.9, оставляй `>=3.7` у базовой возможности и ставь `>=5.9` только у подпункта про Emoji и Upload.\n\n## Documentation Weight\n\n- Перед созданием страницы или раздела оцени самостоятельность пользовательского сценария, количество шагов, настроек и ограничений.\n- Описывай мелкое одношаговое действие одной строкой или буллетом внутри существующего релевантного раздела.\n- Создавай отдельный раздел для самостоятельного workflow с несколькими шагами, вариантами, настройками или важными ограничениями.\n- Выбирай одно основное место для подробного описания cross-cutting фичи. В других страницах оставляй короткое упоминание или ссылку вместо повторения полного объяснения.\n- Оставляй bugfix, внутреннюю оптимизацию и implementation detail только в release notes, если они не меняют пользовательский сценарий или требования совместимости.\n\n## Callouts\n\n- Используй `warning` для риска потери данных, несовместимости, необратимого действия или существенного security-ограничения.\n- Используй `info` для автоматической миграции и неочевидного поведения, которое помогает правильно понять основной workflow.\n- Оставляй основные инструкции обычным текстом; callout должен выделять контекст или исключение, а не содержать весь сценарий.\n- Объединяй связанные риски в один callout и избегай нескольких соседних блоков, если их можно прочитать как одно сообщение.\n- Добавляй короткий предметный заголовок, например `::: warning Compatibility` или `::: info Automatic migration`.\n\n## VitePress Markdown Gotchas\n\n- VitePress компилирует markdown как Vue-компонент, поэтому `{{ ... }}` трактуется как Vue-интерполяция и **исчезает** из вывода.\n- Fenced-блоки (` ``` `) защищены автоматически — внутри них `{{var}}` рендерится буквально.\n- **Инлайн-код в backticks НЕ защищён**: `` `{{variables}}` `` отрендерится пустым. Чтобы вывести литеральные двойные фигурные скобки в тексте или таблице, оборачивай в `v-pre`:\n  `<code v-pre>{{variables}}</code>`\n- Это же касается любых других Vue-конструкций (`{{ }}`, директивы) в произвольном тексте страницы.\n\n## Images And Assets Rules\n\n- Картинки для docs клади в `docs/website/public`.\n- Ссылайся на картинки через `withBase`, например:\n  `<img :src=\"withBase('/feature.png')\">`\n- Если страница использует `withBase`, добавь соответствующий script block:\n  `import { withBase } from 'vitepress'`\n- Используй скриншоты только когда они реально объясняют фичу. Не добавляй декоративные изображения.\n\n## README Rules\n\n- Добавляй README-упоминания только для user-facing фич, которые важны на уровне общего обзора проекта.\n- Держи README copy коротким и product-level; подробное использование должно быть в `docs/website/documentation`.\n- Не пиши в README, когда фича была добавлена. Version availability должна жить в docs pages или release notes.\n- Не ставь новую фичу первой автоматически. Сохраняй текущую информационную архитектуру: сначала основные spaces/features, затем широкие workflow helpers, если пользователь не попросил иначе.\n\n## Validation\n\n- Запускай `git diff --check`.\n- Для изменений docs website запускай `pnpm -C docs/website build`.\n- Если нужно форматирование, ограничивай его изменёнными файлами и избегай широкого churn в config-файлах.\n- Не коммить без явной просьбы пользователя. Для commit или PR загружай `github-workflow`.\n\n## Common Mistakes\n\n- Добавлять README-only документацию для фичи, которой нужна настоящая docs page.\n- Забывать VitePress sidebar для новой страницы, которая должна быть в навигации.\n- Добавлять version availability в README.\n- Переносить `<AppVersion>` всего существующего раздела на версию, в которой фича лишь получила улучшение.\n- Создавать отдельный раздел для одношаговой мелкой фичи, которую достаточно упомянуть в существующем разделе.\n- Повторять полное описание cross-cutting фичи на нескольких страницах вместо одного основного места и коротких упоминаний.\n- Использовать callout для обычной инструкции без риска, совместимости или неочевидного поведения.\n- Документировать shortcuts или поведение без проверки реализации.\n- Запускать широкие formatters, которые переписывают существующий стиль docs config.\n- Писать литеральные `{{ ... }}` в инлайн-коде без `v-pre` — VitePress съест их как Vue-интерполяцию.\n\n<!-- File: .agents/skills/electron-api-and-ipc/SKILL.md (Tokens: ~572 | Category: anthropic-skill) -->\n---\nname: electron-api-and-ipc\ndescription: Use when changing massCode API routes, DTOs, IPC handlers, Electron bridges, or any renderer-to-main communication and storage-access boundaries.\n---\n\n# Electron API And IPC\n\n## Overview\n\nВсе backend-возможности massCode живут в main process. Renderer получает доступ к данным и системным операциям только через Elysia API или IPC channels.\n\n## Renderer Access Rules\n\n- В renderer для данных используй `import { api } from '~/renderer/services/api'`.\n- В renderer для системных операций используй `ipc.invoke('channel:action', payload)`.\n- Electron API из renderer доступен только через `src/renderer/electron.ts`.\n- Никогда не импортируй storage internals или backend-модули напрямую в renderer.\n\n## New API Endpoints\n\nПри добавлении нового endpoint:\n\n1. создай DTO в `src/main/api/dto/`;\n2. добавь route в `src/main/api/routes/`;\n3. запусти `pnpm api:generate`, чтобы обновить клиент.\n\nНе оставляй API-клиент рассинхронизированным с route/DTO изменениями.\n\n## IPC Conventions\n\n- Для filesystem и system ops используй `ipc.invoke(...)`.\n- Каналы должны укладываться в семейства:\n  - `fs:*`\n  - `system:*`\n  - `db:*` — legacy или migration flows, не основной путь для новой функциональности\n  - `main-menu:*`\n  - `prettier:*`\n  - `spaces:*`\n  - `theme:*`\n\n## Good Boundaries\n\n- Renderer формирует intent и payload.\n- Main/API работает с данными приложения, файловой системой и system APIs.\n- Ответ возвращается обратно в renderer в виде DTO или IPC result, а не через shared mutable backend module.\n\n## Common Mistakes\n\n- Тянуть backend-модуль напрямую в renderer ради “удобства”.\n- Менять DTO/route без `pnpm api:generate`.\n- Добавлять system/file behavior в renderer вместо IPC handler.\n- Добавлять новые `db:*` flows там, где задача должна идти через текущую API/IPC модель приложения.\n- Создавать ad-hoc каналы, которые не укладываются в существующие channel families.\n\n<!-- File: .agents/skills/github-workflow/SKILL.md (Tokens: ~742 | Category: anthropic-skill) -->\n---\nname: github-workflow\ndescription: Use when working with massCode issues, branches, commits, pull requests, or merge preparation in GitHub.\n---\n\n# github-workflow\n\n## Issue\n\nЕсли работа идёт по issue, читать его через `gh`:\n\n```bash\ngh issue view <number> -R massCodeIO/massCode\n```\n\nЕсли issue описывает bug, не считай его автоматически подтверждённым.\n\nСначала:\n\n1. понять ожидаемое поведение;\n2. проверить текущее поведение в коде или воспроизвести проблему;\n3. подтвердить bug или явно зафиксировать, что он не подтверждается;\n4. только после этого переходить к ветке, фиксу и PR.\n\nЕсли bug не воспроизводится или issue описан неясно:\n\n- не начинать слепую реализацию;\n- сначала сообщить, что проблема не подтверждена, и уточнить условия или шаги воспроизведения.\n\n## Branch\n\nСоздавай ветку от `main` с префиксом по типу изменения (`feat/`, `fix/`, `chore/`, `refactor/`) и коротким описанием. Если работа идёт по issue — уместно добавить номер в конец.\n\n```bash\ngit checkout main && git pull\ngit checkout -b feat/<short-description> main\n```\n\n## PR\n\nЗаголовок PR — conventional commits:\n\n```text\ntype: description\n```\n\nПеред созданием PR предложи заголовок пользователю на подтверждение.\n\nЕсли PR закрывает существующий issue, в описании добавляй:\n\n```text\ncloses #123\n```\n\nПеред PR убедись, что релевантные проверки и тесты для затронутой области действительно прогнаны.\n\nСоздание:\n\n```bash\ngh pr create \\\n  --base main \\\n  --head <branch-name> \\\n  --title \"type: description\" \\\n  --body \"closes #<issue_number>\" \\\n  --assignee @me\n```\n\nЕсли issue нет — в `--body` кратко опиши суть изменений без служебного AI-хвоста.\n\nПосле создания PR предложи пользователю смерджить его в `main`:\n\n```bash\ngh pr merge <pr_number> -R massCodeIO/massCode --squash --delete-branch\n```\n\nПосле merge синхронизируй локальную ветку:\n\n```bash\ngit checkout main && git pull\ngit branch -d <branch-name>\n```\n\n## Commit\n\n- Только однострочный заголовок conventional commit.\n- Используй подходящий scope для коммитов и PR (`feat(notes):`, 'fix(math):).\n- Без тела, без `Co-Authored-By`.\n\n<!-- File: .agents/skills/release-notes/SKILL.md (Tokens: ~1656 | Category: anthropic-skill) -->\n---\nname: release-notes\ndescription: Use when generating massCode release notes for a GitHub release. Writes the notes to a gitignored file `docs/releases/<tag>.md` for the user to paste into the GitHub release. Use when summarizing merged PRs of a version into a consistent release notes structure.\n---\n\n# Release Notes\n\n## Overview\n\nЭтот skill генерирует release notes одного релиза `vX.Y.Z` для вставки в GitHub release. Цель — единая повторяемая структура от релиза к релизу.\n\nНе трогай `docs/website/download/latest-release.md` — это отдельная repo-страница со своим форматом.\n\n## Source Of Truth\n\n- Содержимое выводи из merged PR между предыдущим и новым тегом, не из памяти.\n- Список изменений бери так:\n  `git log --first-parent --oneline <prev-tag>..<new-tag>` (например `v5.5.0..v5.6.0`).\n- Если новый тег ещё не создан, используй `<prev-tag>..HEAD` и спроси/подтверди номер новой версии.\n- Поведение значимых фич проверяй в коде или в `docs/website/documentation`, прежде чем формулировать, если оно неочевидно из заголовка PR.\n\n## Output\n\n- Записывай результат в файл `docs/releases/<new-tag>.md` (например `docs/releases/v5.6.0.md`). Папка `docs/releases` в `.gitignore`, это рабочий буфер, а не часть репозитория.\n- Пиши именно в файл, а не выводом в терминал: так пользователь копирует чистый markdown без переносов строк, которые добавляет терминал.\n- После записи коротко сообщи путь к файлу и при необходимости покажи итог. Не коммить файл.\n\n## Format\n\nФайл содержит один markdown-блок в этой структуре и порядке:\n\n```\n## <Feature Name>\n\n<1-2 абзаца: что это и что даёт пользователю.>\n\n## <Another Feature Name>\n\n<1-2 абзаца.>\n\n## Workflow Improvements\n\n- <мелкое улучшение>\n- <мелкое улучшение>\n\n## Fixes\n\n- <исправление>\n- <исправление>\n\n**Full Changelog**: https://github.com/massCodeIO/massCode/compare/<prev-tag>...<new-tag>\n```\n\nПравила структуры:\n\n- Начинай прямо с тематических `##`-разделов. Не добавляй заголовок версии `# vX.Y.Z` (его даёт сам GitHub release), frontmatter или `<AssetsDownload />` — это артефакты repo-страницы.\n- Один `##`-раздел на каждую значимую фичу или связную группу фич.\n- `## Workflow Improvements` и `## Fixes` включай только если для них есть содержимое.\n- Compare-ссылка всегда последней строкой, с актуальными предыдущим и новым тегами.\n\n## What To Include\n\n- User-facing изменения: новые spaces и фичи, заметные улучшения workflow, видимые исправления.\n- Крупную фичу выноси в отдельный `##`-раздел с 1-2 абзацами о пользе для пользователя.\n- Мелкие улучшения собирай в `## Workflow Improvements` буллетами.\n- Исправления собирай в `## Fixes` буллетами, по одному на исправление.\n\n## What To Omit\n\n- Чисто внутренние коммиты: `ci`, `build`, `chore`, рефакторинг, bump зависимостей, релизные служебные коммиты (`build: release vX.Y.Z`).\n- Исключение: выноси платформенные изменения, заметные пользователю (например code signing и notarization на macOS), в `## Workflow Improvements`.\n- Не описывай детали реализации; пиши о результате для пользователя.\n\n## Writing Style\n\n- Английский, спокойный фактический тон. Что делает фича и зачем она пользователю, без маркетинговых превосходных степеней.\n- Никаких em dash. Это общее правило репозитория.\n- Имена spaces пиши консистентно: `Code`, `Notes`, `Math Notebook`, `Drawings`, `HTTP`, `Tools`. Не смешивай `Code` и `Snippets` как имя пространства.\n- `snippet` — единица контента внутри пространства Code, а не имя пространства. В Fixes допустимо «snippet fences», «snippet sync», но пространство всё равно называется Code.\n- Code identifiers, расширения файлов и токены оборачивай в backticks (`` `.excalidraw` ``, `` `@` ``, `` `Esc` ``).\n- Shortcuts указывай как в интерфейсе; macOS и Windows/Linux варианты различай, если они отличаются.\n\n## Common Mistakes\n\n- Перечислять коммиты дословно вместо группировки в user-facing разделы.\n- Включать `ci` / `build` / `chore` шум, который не виден пользователю.\n- Добавлять `# vX.Y.Z`, frontmatter или `<AssetsDownload />` (это формат repo-страницы, а не GitHub release).\n- Выводить нотис простыней в терминал вместо файла `docs/releases/<new-tag>.md` (терминал ломает переносы строк при копировании).\n- Коммитить файл из `docs/releases` — это игнорируемый рабочий буфер.\n- Смешивать имена пространств (`Code` против `Snippets`) внутри одного документа.\n- Описывать детали реализации вместо пользы для пользователя.\n- Забыть обновить compare-ссылку на актуальные теги.\n- Использовать em dash вопреки правилу репозитория.\n\n<!-- File: .agents/skills/spaces-architecture/SKILL.md (Tokens: ~727 | Category: anthropic-skill) -->\n---\nname: spaces-architecture\ndescription: Use when working on massCode spaces such as code, notes, math, or tools, especially when changing their state, behavior, synchronization, or spaces IPC channels.\n---\n\n# Spaces Architecture\n\n## Overview\n\nmassCode использует систему Spaces для разделения функциональных областей. Это не просто UI tabs: у каждого space есть собственное состояние, свои правила обновления и свой способ синхронизации с данными в vault.\n\n## Space Model\n\n- `code` — snippets, folders, tags\n- `notes` — notes, folders, tags, markdown-based flows\n- `math` — calculation sheets и состояние math notebook\n- `tools` — developer utilities\n\nОсновные определения живут в `src/renderer/spaceDefinitions.ts`.\n\n## Space State Storage\n\n- Состояние каждого space хранится в `__spaces__/{spaceId}/.state.yaml` внутри vault.\n- Runtime helpers:\n  - `src/main/storage/providers/markdown/runtime/spaces.ts`\n  - `src/main/storage/providers/markdown/runtime/spaceState.ts`\n- Директория `__spaces__/` — служебная часть vault для состояния spaces.\n\n## Persistence Rules\n\n- Запись состояния spaces использует ту же debounce/flush инфраструктуру, что и `state.json`.\n- Не ломай совместимость с `pendingStateWriteByPath` и flush-on-exit поведением.\n- Если меняешь способ записи, учитывай сценарий завершения приложения до явного ручного flush.\n\n## IPC Rules\n\n- Space-specific IPC handlers живут в `src/main/ipc/handlers/spaces.ts`.\n- Текущие math handlers:\n  - `spaces:math:read`\n  - `spaces:math:write`\n- Если добавляется новый `spaces:*` flow, он должен работать через общую модель состояния spaces, а не в обход неё.\n\n## Space-Aware Sync\n\n- `system:storage-synced` обновляет активное пространство через `getActiveSpaceId()`.\n- Ожидаемое поведение:\n  - `code` → refresh folders + snippets\n  - `notes` → refresh notes + note folders\n  - `math` → `reloadFromDisk()` через `useMathNotebook()`\n  - `tools` → no-op\n- Изменения, которые уже сохранены в vault, должны вызывать `markPersistedStorageMutation()`, чтобы не создавать sync loops.\n\n## Common Mistakes\n\n- Считать spaces только UI-концепцией и забывать, что у них есть собственное состояние и правила синхронизации.\n- Писать состояние space в обход общих markdown runtime helpers.\n- Добавлять mutation без `markPersistedStorageMutation()`.\n- Ломать согласованность между состоянием space, helpers и sync behavior.\n\n<!-- File: .agents/skills/ui-foundations/SKILL.md (Tokens: ~1297 | Category: anthropic-skill) -->\n---\nname: ui-foundations\ndescription: Use when defining or reviewing massCode UI foundation rules such as typography, renderer styling consistency, TailwindCSS v4 usage, and when raw markup starts competing with established UI text patterns.\n---\n\n# UI Foundations\n\n## Overview\n\nUI в massCode должен оставаться визуально консистентным. Этот skill отвечает за базовые styling decisions: как относиться к typography, когда использовать established text patterns и как не скатываться в разрозненный renderer styling.\n\n## Core Rules\n\n- Базовая styling system в renderer строится на TailwindCSS v4.\n- Новые UI-экраны и состояния должны продолжать существующий visual language, а не вводить локальные правила “для одного места”.\n- Для стандартного app UI предпочитай семантические токены вроде `bg-background`, `text-muted-foreground`, `border-border`, `border-destructive/*` вместо raw palette-классов вроде `bg-white`, `text-black`, `text-green-500`, `bg-slate-900`.\n- Typography по умолчанию строится через `UiText`.\n- Не заменяй `UiText` на произвольный набор `text-*`, `font-*`, `text-muted-foreground`, если подходящий variant уже существует.\n- Если `UiText` почти подходит, лучше добавить точечные классы поверх него, чем уходить в raw typography markup.\n\n## Typography\n\n- `UiText` — базовый источник правды для текстовых размеров и muted-state.\n- `caption` и `xs` — подписи, helper text, secondary labels.\n- `sm` и `base` — основной интерфейсный текст.\n- `lg` и `xl` — усиленные title/value cases, когда это действительно нужно по hierarchy.\n- `font-mono` — только для code-like content, IDs, counts with alignment needs, readonly generated output и подобных случаев.\n- Для uppercase labels используй существующий pattern через `UiText` или согласованный tracking/uppercase стиль, а не случайную смесь utility classes в каждом месте.\n\n## Spacing And Layout Rhythm\n\n- Корневые screen/container wrappers обычно живут в ритме `space-y-4` или `space-y-6`.\n- Внутри компактных секций чаще всего `space-y-2` или `space-y-3`.\n- Grid gaps по умолчанию: `gap-2`, `gap-3`, `gap-4` в зависимости от плотности.\n- Не придумывай локальный spacing-scale для одного экрана, если существующие интервалы уже покрывают задачу.\n- Повторяющиеся content blocks должны иметь одинаковый padding и vertical rhythm.\n\n## Radius And Shadows\n\n- `rounded-md` — controls, inline boxes, compact containers.\n- `rounded-lg` — card-like blocks, dialogs, overlays, dashboard sections.\n- `rounded-xl` — preview-heavy surfaces и крупные visual blocks.\n- `rounded-full` — pills, badges, circular handles.\n- `shadow-xs` — inputs, buttons, small controls.\n- `shadow-md` и `shadow-lg` — overlays, popovers, previews, где elevation реально нужна.\n- Не вводи произвольные `rounded-[...]` и `shadow-[...]`, если стандартные токены уже подходят.\n\n## Exceptions\n\n- Raw colors допустимы, если цвет является частью самих данных или preview:\n  color pickers, contrast previews, code/image export backgrounds, diagram or visualizer nodes.\n- Если цвет вычисляется из контента или нужен для корректного контраста на пользовательском фоне, raw class или inline style допустимы.\n- Исключения не должны становиться поводом тащить raw palette в обычный application chrome.\n\n## When To Prefer This Skill\n\n- Нужно понять, как оформлять текст и подписи в новом UI.\n- Есть соблазн писать raw Tailwind typography вместо существующего text pattern.\n- В экране начинают появляться локальные styling rules, которые расходятся с остальным renderer UI.\n- Нужно принять решение на уровне визуальной базы, а не конкретного button/input/dialog.\n\n## Common Mistakes\n\n- Размазывать локальные визуальные исключения по фичам.\n- Тащить raw palette в обычный app UI без реальной причины.\n- Писать текст напрямую через произвольные utility classes там, где подходит `UiText`.\n- Делать новый экран со своим spacing rhythm вместо существующего scale.\n- Случайно смешивать small-control radii и preview-surface radii в одном и том же UI слое.\n- Считать Tailwind поводом делать каждый экран визуально “с нуля”.\n\n<!-- File: .agents/skills/ui-primitives/SKILL.md (Tokens: ~1306 | Category: anthropic-skill) -->\n---\nname: ui-primitives\ndescription: Use when building or refactoring massCode UI components with local Ui primitives or Shadcn, especially for cn, cva, notifications, and rules against reimplementing basic controls.\n---\n\n# UI Primitives\n\n## Overview\n\nБазовые UI-элементы в massCode должны собираться из существующих `Ui*` компонентов и Shadcn-паттернов. Этот skill отвечает за component-level usage rules, а не за общую визуальную базу.\n\n## Component Usage\n\n- Локальные UI-компоненты доступны через auto-import с префиксом `Ui`.\n- Базовые элементы вроде button, input, checkbox, action button не переизобретай на сыром HTML, если есть готовый `Ui*` вариант.\n- Если нужного элемента нет, сначала создай его в `src/renderer/components/ui/`, потом используй в фиче.\n\n## Buttons\n\n- Primary action должен быть явным и не конкурировать с несколькими равноправными CTA в одном контейнере.\n- Icon-only actions должны быть понятны по контексту и иметь tooltip или другой доступный label path.\n- Loading и pending actions должны использовать существующий button pattern, а не ad-hoc “disabled text swap”.\n- Destructive actions не должны выглядеть как обычные secondary controls.\n\n## Cards And Containers\n\n- Для автономных panel-like блоков используй существующий `Card` / `Ui*` container pattern, если он уже есть в области.\n- Внутренние muted blocks не нужно пересобирать разными `div`-паттернами в каждой фиче.\n- Repeated panel structure должна переезжать в shared primitive или local feature primitive, а не копироваться markup-в-маркап.\n\n## Readonly And Copyable Content\n\n- Длинный readonly output, generated text, URLs и similar content не показывай как “обычный disabled input”, если это ухудшает чтение.\n- Для copy flows используй существующий copy pattern и уведомления через `useSonner()`.\n- Readonly content должен оставаться визуально читаемым и удобно копируемым.\n\n## Styling Helpers\n\n- Для variants используй `cva`.\n- Для склейки классов используй `cn()`.\n- Не делай variants вручную строковыми `if`-цепочками там, где нужен нормальный variant API.\n\n## Shadcn Rules\n\n- Shadcn-компоненты импортируй вручную из `@/components/ui/shadcn/*`.\n- Для namespace-based компонентов используй паттерн вроде `import * as Dialog from '@/components/ui/shadcn/dialog'`.\n\n## Notifications\n\n- Для уведомлений используй `useSonner()`.\n- Не добавляй локальную, параллельную систему toast/notification внутри фичи.\n\n## Tooltip, Popover, Overlay\n\n- Tooltip — для короткого пояснения.\n- Popover — для richer inline content, picker-like content или contextual controls.\n- Не заменяй их ad-hoc overlay-разметкой без необходимости.\n- Validation и inline guidance должны использовать существующие tooltip/popover primitives, если проект уже их применяет в аналогичных местах.\n\n## Dialog Focus\n\n- Во всех диалогах явно управляй фокусом при открытии и закрытии. Не допускай автоматического фокуса на крестике закрытия и появления tooltip на кнопке открытия из-за возврата фокуса после закрытия.\n- По умолчанию отменяй стандартный autofocus на `DialogContent`:\n\n  ```vue\n  @open-auto-focus=\"(e) => e.preventDefault()\"\n  @close-auto-focus=\"(e) => e.preventDefault()\"\n  ```\n\n- Исключение — намеренный фокус на конкретном поле или действии, нужном для сценария диалога. Задавай такую цель явно; при закрытии выбирай цель возврата фокуса без побочного показа tooltip.\n- Сохраняй focus trap и клавиатурную навигацию. Проверяй открытие и закрытие мышью и клавиатурой, включая Escape.\n\n## Common Mistakes\n\n- Писать ещё одну кнопку или input с нуля “потому что быстрее”.\n- Склеивать сложные conditional classes без `cn()`.\n- Дублировать существующий primitive внутри feature directory вместо общего `src/renderer/components/ui/`.\n- Использовать disabled input как универсальный readonly display surface.\n- Делать overlay pattern вручную там, где уже есть Shadcn primitive.\n- Смешивать правила primitives с вопросами визуальной базы, которые должны идти в `ui-foundations`.\n\n<!-- File: .agents/skills/vue-renderer-standards/SKILL.md (Tokens: ~662 | Category: anthropic-skill) -->\n---\nname: vue-renderer-standards\ndescription: Use when editing massCode renderer code in Vue 3, especially for script setup patterns, import rules, composables, shared state, and renderer-side conventions.\n---\n\n# Vue Renderer Standards\n\n## Overview\n\nRenderer в massCode строится на Vue 3 Composition API с `<script setup lang=\"ts\">`. Здесь важны строгие import rules, composable-first state sharing и запрет на прямой доступ к backend-возможностям.\n\n## Component Pattern\n\n- Используй Vue 3 Composition API и `<script setup lang=\"ts\">`.\n- Vue core (`ref`, `computed`, `watch`, `onMounted` и подобные) не импортируй вручную: они auto-imported.\n- Проектные компоненты из `src/renderer/components/` тоже не импортируй вручную: они auto-imported.\n- Локальную логику компонента держи в script, а не в template.\n\n## Manual Imports Only Where Required\n\nВсегда импортируй вручную:\n\n- composables из `@/composables`;\n- utils из `@/utils`;\n- `@vueuse/core`;\n- Electron bridge из `@/electron`;\n- Shadcn UI из `@/components/ui/shadcn/*`.\n\n## Shared State\n\n- Глобальное shared state реализуется composables без Pinia/Vuex.\n- Reactive state, который должен шариться между компонентами, объявляй на module level, вне экспортируемой функции composable.\n- Persistent UI/settings state храни через `store` из `@/electron`:\n  - `store.app` для UI state;\n  - `store.preferences` для user preferences.\n\n## VueUse First\n\n- Перед написанием нового composable сначала проверь, нет ли подходящего решения в `@vueuse/core`.\n- Кастомный composable добавляй только если готового utility реально нет.\n\n## Renderer Boundaries\n\n- Renderer не импортирует storage internals или backend-модули доступа к данным напрямую.\n- Renderer не обращается напрямую к Node.js, filesystem или storage runtime.\n- Доступ к main process возможен только через `api` или `ipc`.\n\n## Common Mistakes\n\n- Ручной импорт `ref` / `computed` / `watch`.\n- Ручной импорт локальных project components.\n- Локальный state внутри composable, который должен быть общим между несколькими компонентами.\n- Попытка “срезать путь” и импортировать backend-модуль прямо в renderer.\n\n<!-- File: docs/website/documentation/tools/index.md (Tokens: ~418 | Category: anthropic-skill) -->\n---\ntitle: Overview\ndescription: \"Use built-in developer tools in massCode for JSON diffing, text conversion, hashing, HMAC generation, URL parsing, and other quick tasks.\"\n---\n\n# Tools overview\n\nTools is for the small developer tasks that should take seconds, not a trip to a random website. Use it when you need to compare JSON, convert, encode, hash, or generate something quickly without leaving massCode.\n\nThe available tools are grouped by category:\n\n## Compare\n\n### [JSON Diff](/documentation/tools/json-diff)\n\nCompare two JSON documents side by side with validation, filters, and a tree diff for nested changes.\n\n## Text tools\n\n### Case Converter\n\nConvert text between common casing formats such as camelCase, snake_case, kebab-case, and uppercase.\n\n### Slug Generator\n\nTurn free-form text into a URL-friendly slug.\n\n### URL Parser\n\nSplit a URL into its protocol, host, path, query, and hash parts.\n\n### Line Break Normalizer\n\nRemove hard wraps from copied terminal output while preserving Markdown lists, tables, quotes, commands, and code blocks. The same normalization is available from the **Editor** menu in Code and Notes.\n\n## Cryptography & Security\n\n### Hash Generators\n\nGenerate one-way hashes from text input.\n\n### HMAC Generators\n\nBuild keyed message authentication hashes from a secret and a message.\n\n### Password Generators\n\nGenerate random passwords with configurable character sets.\n\n### UUID Generators\n\nCreate unique identifiers for fixtures, payloads, and test data.\n\n## Encoders & Decoders\n\n### URL\n\nEncode or decode URL strings safely.\n\n### Base64\n\nConvert plain text to and from Base64.\n\n### JSON ⇄ TOML/XML/YAML\n\nTransform JSON between common structured data formats.\n\n### Text ⇄ ASCII/Binary/Unicode\n\nConvert text into different low-level or escaped representations and back.\n\n### Color Converter\n\nTranslate color values between supported formats.\n\n## Generators\n\n### JSON Generator\n\nBuild mock JSON payloads with typed fields for testing and demos.\n\n### Lorem Ipsum Generator\n\nGenerate placeholder words, sentences, or paragraphs.\n\n<!-- File: docs/website/documentation/tools/json-diff.md (Tokens: ~318 | Category: anthropic-skill) -->\n---\ntitle: JSON Diff\ndescription: \"Compare two JSON documents side by side in massCode with validation, filters, and a tree diff.\"\n---\n\n# JSON Diff\n\nJSON Diff lets you compare two JSON documents side by side without leaving massCode. It is useful for checking API responses, fixture changes, configuration edits, and generated JSON payloads.\n\n## Where to find it\n\nOpen **Tools** in the left rail, then go to **Compare** → **JSON Diff**.\n\n## What it does\n\n- Shows the original and modified JSON in two editors\n- Validates each side independently\n- Formats valid JSON on paste and blur\n- Builds a tree-based diff for nested objects and arrays\n- Highlights added, removed, and modified values\n- Filters the diff by change type\n- Keeps both input editors scrolled in sync\n- Uses the same editor font settings as the main code editor\n\n## How to use it\n\n1. Paste the original JSON into the left editor.\n2. Paste the modified JSON into the right editor.\n3. Review the diff tree below the editors.\n4. Use the checkboxes to focus on added, removed, or modified nodes.\n5. Expand or collapse nested objects and arrays as needed.\n\n## Notes\n\n- Both inputs must contain valid JSON before the diff viewer appears.\n- Validation errors are shown under each editor separately.\n- If only one side is filled, the tool stays in the empty state instead of guessing missing data.\n- Array move visualization is not exposed as a separate state. In this version, the tool prefers predictable output over compact move semantics.\n</yakaai_skills>"}