GRACE Marketplace and CLI — скилл
Пятнадцать скиллов GRACE и CLI для разработки по контрактам: спецификация, план, исполнение и проверка через артефакты .grace
- 268 ★ репозитория
- Последний коммит
- MIT
Широкий доступ
Почему такой уровень
- Скиллы создают и меняют файлы `.grace` и `AGENTS.md` в проекте, а миграция может предложить очистку старых документов
- CLI с флагом `--run-commands` выполняет команды `MustPassCommand`, которые объявлены в артефактах проекта
- Параллельный режим исполнения запускает нескольких агентов, и каждый пишет в репозиторий
Установка
- Работает в
В терминале, через SkillFoxx CLI
npx skillfoxx add skills/grace-marketplace-and-cliОпределит агенты на машине, покажет уровень доступа и зафиксирует версию.
Другие способы установки
Доступ и проверки
Как мы проверяемШирокий доступИнструмент может менять данные, выполнять команды или работать с секретами.
- Скиллы создают и меняют файлы `.grace` и `AGENTS.md` в проекте, а миграция может предложить очистку старых документов
- CLI с флагом `--run-commands` выполняет команды `MustPassCommand`, которые объявлены в артефактах проекта
- Параллельный режим исполнения запускает нескольких агентов, и каждый пишет в репозиторий
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
GRACE (Graph-RAG Anchored Code Engineering) — методология, по которой агент пишет код от контрактов: у модулей есть семантическая разметка, у проекта граф знаний, а у каждого изменения проверка. Репозиторий поставляет 15 скиллов в `skills/grace/`, зеркало для маркетплейса Claude Code и необязательный CLI `grace`. Источником правды служит папка `.grace`: контекст проекта (требования, технологии, принципы, развертывание, UX) в XML, граф модулей, записи проверки и пакеты изменений `C-*` в активном и архивном состоянии. Цикл работы идет по скиллам. `grace-init` создает каркас `.grace` и `AGENTS.md`, `grace-spec` оформляет согласованную спецификацию изменения, `grace-plan` строит из нее утверждения, области и проверки, а `grace-execute` выполняет план последовательно или в параллельном режиме. Для сопровождения есть `grace-refactor`, `grace-fix`, `grace-refresh` и `grace-status`, для вопросов `grace-ask`, для проверок `grace-verification` и `grace-reviewer`. Проекты старой версии переносит `grace-migrate`. CLI `grace lint` проверяет разметку и контракты, `grace status` показывает здоровье проекта и расхождения с git, а `grace module`, `grace verification` и `grace file show` ищут и показывают модули и записи. С флагом `--run-commands` линтер выполняет объявленные команды `MustPassCommand`, то есть тесты, проверку типов и сборку.
Для кого. Для разработчиков, которые ведут крупную кодовую базу с Claude Code или Codex и хотят закрепить в проекте контракты модулей, граф и проверки.
Подходит, если
- Агент все время отклоняется от архитектуры, и нужен документ, из которого ясно, какой модуль что обязан делать
- Перед большим изменением нужна спецификация, план и критерии приемки, которые вы одобряете до написания кода
- Рефакторинг (переименование, перенос, слияние модулей) должен идти без расхождений между кодом и артефактами
- Хочется ловить рассинхрон между кодом и описанием командой `grace status` и `grace lint`
- Требуется быстро найти по графу, где живет модуль и какие проверки с ним связаны
Не подходит, если
- Небольшой скрипт или одноразовый прототип: каркас `.grace`, контракты и проверки добавят больше работы, чем пользы
- Проект на Go, Rust, Java, C++, C# или оболочке и вам нужна точная проверка экспортов: для них проверяется структура разметки, а сверка экспортов не делается
- Нет Bun: CLI устанавливается через `bun add -g @osovv/grace-cli`, без него остаются только скиллы
- У проекта разметка в XML-комментариях, например `.xaml` или `.csproj`: маркеры распознаются только после префиксов `//`, `#`, `--`, `;` и `*`
Пример запроса к агенту
Запусти $grace-init для проекта на TypeScript, потом оформи через $grace-spec изменение «добавить оплату картой» и покажи спецификацию на одобрениеОграничения
Репозиторий служит для распространения: автор подчеркивает, что это не конечное приложение. Скиллы ставятся первыми, CLI необязателен, но рекомендован, и ему нужен Bun. Скиллы вызывают установленный бинарник `grace` напрямую, без `bunx` и `npx`.
Семантический анализ TypeScript и JavaScript встроен. Для Python и Dart нужны их рантаймы в PATH, а при отсутствии рантайма проверка завершается ошибкой `analysis.runtime-missing`. Для языков без адаптера, включая Go, Rust, Java, C/C++, C# и оболочку, проверяется только структура: разметка, полнота контрактов и форма `MODULE_MAP`, а сверка экспортов не выполняется. Проекты версии GRACE 3 не проходят проверку и переносятся скиллом `grace-migrate`. Очистка после миграции требует отдельного явного подтверждения. Лицензия MIT.
Как отключить. Удалите плагин командой `/plugin uninstall grace@grace-marketplace` или папки `grace-*` из каталога скиллов агента, а CLI командой `bun remove -g @osovv/grace-cli`. Папка `.grace` и `AGENTS.md` лежат в вашем проекте, удалите их вручную, если методология больше не нужна.
Частые вопросы
Как установить GRACE в Claude Code?
Выполните `/plugin marketplace add osovv/grace-marketplace`, затем `/plugin install grace@grace-marketplace`. Есть и другие пути: `opkg install gh@osovv/grace-marketplace` через OpenPackage или копирование папок `grace-*` из `skills/grace/` в каталог скиллов агента.
С чего начать новый проект?
Вызовите `$grace-init`, чтобы создать `.grace`, затем заполните файлы `.grace/context`. Для первого изменения идут `$grace-spec`, `$grace-plan` и `$grace-execute`. Перед записью работайте с `grace lint --path <корень> --assertions current`, перед архивацией проверяйте `--assertions final`.
Нужен ли CLI, если есть скиллы?
Скиллы работают сами, а CLI добавляет быструю проверку и поиск по артефактам. Он требует Bun: `bun add -g @osovv/grace-cli`, потом `grace --version` и `grace lint --path <проект>`.
Что делать с проектом GRACE 3?
Запустите `$grace-migrate` и просмотрите отчет о миграции перед записью артефактов `.grace`. CLI проверяет результат, но сам старые документы не преобразует. Очистка после миграции требует отдельных условий: свежего статуса без ошибок, просмотра git и явного подтверждения.
Какие языки программирования поддерживаются?
Для TypeScript и JavaScript анализ встроен. Python и Dart проверяются при наличии своих рантаймов в PATH. Для остальных языков, включая Go, Rust и Java, проверяется структура разметки без сверки экспортов.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
Скиллы73 скилла для конвейера разработки: план, код, ревью и QA, а в конце готовый PR с метками в вашем репозитории.
CLI устанавливает Graftcode Gateway и правила для кодовых агентов, чтобы открыть методы собственного сервиса как MCP-инструменты
Маркетплейс плагинов для Claude Code и AdaL CLI: skills для клонирования лендингов, графа кода, PostHog и 23 гайда по CLI.
Задачи, документы, спецификации и решения проекта лежат файлами Markdown в репозитории, а агент читает их через CLI и MCP
Личный набор автора: общие правила для агентов и десятки скиллов для GitHub, браузера, macOS, сообщений и релизов, плюс скрипт синхронизации
14 скиллов, которые находят пробелы в задаче до кода: интервью, план, проверка допущений и доказательство исправления бага
Коротко о README
Документ описывает модель GRACE 4 как набор артефактов `.grace`, перечисляет 15 скиллов и команды CLI, режимы вывода и настройку `.grace-lint.json`. Отдельно разобраны кэш анализа, встроенный список игнорируемых каталогов и совместимость с упаковкой для Claude Code, OpenPackage и общих каталогов скиллов.
Бейдж для README
Исходный SKILL.md
--- name: grace-init description: Bootstrap a Full GRACE 4 project by creating the canonical .grace context, graph, verification, and changes skeleton. --- <skill> <task> Create the canonical GRACE 4 project layout from this skill's `assets/` templates: - `AGENTS.md` - `.grace/context/requirements.xml` - `.grace/context/technology.xml` - `.grace/context/principles.xml` - `.grace/context/deployment.xml` - `.grace/context/ux-guidelines.xml` - `.grace/graph/index.xml` - `.grace/graph/main.xml` - `.grace/verification/index.xml` - `.grace/verification/main.xml` - `.grace/changes/active/` - `.grace/changes/archive/` Every XML artifact uses `graceVersion="4.0"`. Semantic anchors are XML tags, never attributes. Do not create dummy `C-*` change bundles. Do not overwrite existing `.grace` artifacts without explicit confirmation. </task> <template_sources> | Template source | Target in project | |---|---| | `assets/AGENTS.md.template` | `AGENTS.md` | | `assets/.grace/context/requirements.xml.template` | `.grace/context/requirements.xml` | | `assets/.grace/context/technology.xml.template` | `.grace/context/technology.xml` | | `assets/.grace/context/principles.xml.template` | `.grace/context/principles.xml` | | `assets/.grace/context/deployment.xml.template` | `.grace/context/deployment.xml` | | `assets/.grace/context/ux-guidelines.xml.template` | `.grace/context/ux-guidelines.xml` | | `assets/.grace/graph/index.xml.template` | `.grace/graph/index.xml` | | `assets/.grace/graph/main.xml.template` | `.grace/graph/main.xml` | | `assets/.grace/verification/index.xml.template` | `.grace/verification/index.xml` | | `assets/.grace/verification/main.xml.template` | `.grace/verification/main.xml` | </template_sources> <steps> 1. Gather project name, annotation, keywords, language/runtime/framework, testing stack, observability constraints, deployment applicability, UX applicability, and any known initial modules. 2. If `.grace` or `AGENTS.md` already exists, stop and ask whether to keep, merge, or overwrite each existing artifact. Never overwrite silently. 3. Create `.grace/context`, `.grace/graph`, `.grace/verification`, `.grace/changes/active`, and `.grace/changes/archive`. 4. Read each `.template` file, replace `$PLACEHOLDER` values with gathered project information, and write the target file.