Lattice — плагин
Lattice — составные скиллы для ИИ-ассистентов: требования, дизайн до кода, реализация по стандартам проекта, ревью с контекстом
- 211 ★ репозитория
- Последний коммит
Минимальный доступ
Почему такой уровень
- Скиллы читают проект и пишут файлы в `.lattice/`, исходный код меняет только этап реализации по утвержденному проекту
Установка
- Работает в
В терминале, через SkillFoxx CLI
npx skillfoxx add plugins/latticeОпределит агенты на машине, покажет уровень доступа и зафиксирует версию.
Другие способы установки
Доступ и проверки
Как мы проверяемМинимальный доступИнструмент ничего не запускает и не ходит в сеть.
- Скиллы читают проект и пишут файлы в `.lattice/`, исходный код меняет только этап реализации по утвержденному проекту
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
Lattice — набор скиллов в три уровня. «Атомы» задают одну границу каждый: чистый код, архитектура, DDD, безопасный код, качество тестов, дизайн до кода. «Молекулы» собирают атомы в процессы: проектирование, реализация, рефакторинг, исправление ошибок, ревью. «Уточнители» проводят интервью и записывают стандарты вашего проекта, которые меняют поведение атомов. Процесс идет по цепочке `requirement-forge`, `design-blueprint`, `code-forge`, `review`, а `refactor-safely` и `bug-fix` берут на себя структурные и дефектные задачи. Скилл `requirement-forge` играет пару старшего менеджера и аналитика, `design-blueprint` проводит пять уровней проектирования до первой строки кода. Контекст накапливается в папке `.lattice/` и после каждого цикла становится точнее. Команда `/lattice-init` сканирует проект и создает `.lattice/config.yaml`. Для Claude Code, Codex, Cursor и других клиентов есть манифесты плагина.
Для кого. Командам разработки, которым нужны общие версионируемые скиллы вместо личных промптов: от требований и дизайна до реализации и ревью одного изменения.
Подходит, если
- Агент сразу пишет код и молча принимает проектные решения, хотя дизайн хочется получить заранее
- Новая фича начинается с эпиков и спецификации, которые готовит `requirement-forge`
- Команда хочет единые стандарты чистого кода и архитектуры, записанные в `.lattice/`
- Рефакторинг идет под скиллом `refactor-safely`, чтобы не сломать поведение
Не подходит, если
- Задача в одну строку: цепочка с требованиями, дизайном и ревью замедлит работу
- Нужен готовый набор для одного языка или фреймворка: Lattice описывает процесс, а API у него нет
- Нужна проверка безопасности по списку уязвимостей: атом безопасного кода задает принципы
Пример запроса к агенту
Запусти lattice-init, затем сделай requirement-forge по этому PRD и design-blueprint перед кодомОграничения
- Скиллы задают порядок мышления, поэтому результат зависит от того, как команда заполнит `.lattice/config.yaml` и уточнители. Без этого стандарты остаются общими.
- Папка `.lattice/` растет с каждым циклом и лежит в репозитории, ее содержимое стоит просматривать при ревью.
- Для Codex и других клиентов README ведет таблицу статусов по хостам в `docs/plugins.md`, поддержка у них разная.
- Агент-проверяющий `verifier` включается вручную или автоматически и тратит дополнительные токены.
Как отключить. Для плагина Claude Code выполните `/plugin uninstall lattice`. При установке через `tools/install.sh` удалите скопированные папки скиллов, папку `.lattice/` проекта удаляется вручную.
Частые вопросы
Как поставить Lattice в Claude Code?
Командами `/plugins marketplace add techygarg/lattice`, `/plugins install lattice` и `/reload-plugins`. Cursor читает те же скиллы Claude Code автоматически.
Как поставить Lattice в Codex?
Командами `codex plugin marketplace add techygarg/lattice` и `codex plugin add lattice@lattice`. Манифест лежит в `.codex-plugin/`.
Что такое атомы, молекулы и уточнители?
Атом задает одну границу вроде чистого кода, молекула собирает атомы в процесс, уточнитель проводит интервью и записывает стандарты проекта.
Для чего папка `.lattice/`?
В ней лежат `config.yaml`, требования и накопленные выводы ревью. После каждого цикла содержимое пополняется, и следующий цикл начинается с более точного контекста.
Есть ли пример для пробы?
Да, папка `sample/` содержит спецификацию User Service на .NET 8 с требованиями и ограничениями. Скопируйте ее в пустой каталог и пройдите конвейер.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
ПлагиныСкиллы и CLI с графом продукта: до кода проверяют роли, состояния и сбои, после сборки проверяют живой продукт
lencx skills
lencx-skills
Два скилла для Claude Code и Codex: keel решает вопросы архитектуры, coding-protocol держит правки кода в границах задачи
Независимые скиллы на весь цикл разработки: продукт, архитектура, планирование, реализация, QA, поставка и эксплуатация
Десять скиллов жизненного цикла разработки для Claude Code: требования, дизайн, тесты, ревью и проверка релиза с хуками.
Хуки и навыки заставляют Claude Code планировать до кода, писать тесты до релиза и звать человека, когда уверенности нет.
Плагины Claude Code для разработки от замысла: схемы, требования EARS, тесты и код, плюс слежение за связью требований с кодом
Сравнение с похожими
Карточки с тем же главным запросом: чем они отличаются.
| Инструмент | Официальный | Звезды репозитория | Главное отличие |
|---|---|---|---|
| Lattice (эта карточка) | нет | 211 | |
| SpecKit Companion | нет | 105 | расширение для Spec Kit, а здесь собственные атомы, молекулы и накопление контекста |
| superpowers-zh | нет | 8 521 | общий набор процессных скиллов, а здесь три уровня и уточнители под проект |
Коротко о README
README объясняет три принципа Lattice, три уровня скиллов и конвейер от требований до ревью. Дальше идут четыре способа установки, шаги первого запуска, ссылки на руководства и серию статей на martinfowler.com, на которой основан набор.
Бейдж для README
Исходный SKILL.md
--- name: design-blueprint description: "Run a complete design workflow -- from establishing context through four progressive design levels (Capabilities, Components, Interactions, Contracts) to an approved blueprint. Composes knowledge-priming, context-anchoring, learning-harvest, collaborative-judgment, design-first, architecture, and domain-driven-design into one process. Handles both new features (create context doc) and resuming existing work (load context doc). Level 5 (Implementation) is delegated to code-forge. Use when starting a design, planning architecture, or when the user says 'design a feature', 'blueprint', 'start designing', 'plan the architecture', or 'let's design before coding'." --- # Design Blueprint ## Required Skills Read and apply in order before Step 1: 1. `framework:knowledge-priming` -- Load the project knowledge base so every decision grounds in the real project. (always) 2. `framework:context-anchoring` -- Create or load the feature's living context doc (Create / Load / Enrich behaviors). (always) 3. `framework:learning-harvest` -- Load prior operational learnings at session start; harvest new ones at session end. (always) 4. `framework:collaborative-judgment` -- Surface genuine judgment calls as structured options instead of silently assuming. (always) 5. `framework:design-first` -- Owns the 5-level methodology. Its Entry Assessment, Complexity Calibration, Simplicity Check, and Level Completion Protocol govern Step 2. (Step 2) 6. `framework:architecture` -- Validate components, layers, dependency direction, and boundary rules (design mode). (Levels 2-4) 7. `framework:domain-driven-design` -- Model aggregates, entities, value objects, events, and contracts (design mode). (Levels 2-4) ## Additional Instructions **STOP: Before Step 1, read `additional_instructions.design_blueprint` (one line or a list) from `.lattice/config.yaml`.** No file or no key → skip silently. When lines are found: 1. Show them verbatim under "Additional instructions (from config):". 2. **Highest priority — apply them for the whole session, including on resume.** On any conflict with anything else in this skill — steps, gates, STOP rules — or with its Required Skills, standards documents, or operational learnings, the config line wins. ## Workflow ### Step 1: Establish Context 1. Run `framework:learning-harvest` Load behavior. Focus hint: "design session — focus: design patterns, reliability, structural health". 2. Set up the feature's living doc with `framework:context-anchoring`: - **Discover**: run context-anchoring Document Discovery — scan the context base directory (per the atom's Config Resolution) for an existing anchor doc matching the feature name or frontmatter. - **Found** → Load behavior. Present the structured acknowledgment: feature name, status, decision count, open questions, constraints. Then run the resume check below. - **Not found** → Create behavior. Confirm the feature name, summary, and requirement doc link with the user before creating. Then begin Step 2 — the Entry Assessment sets the entry level. 3. **Resume check** (when a doc was found) — derive the earliest incomplete step from the doc itself. **STOP:** Never re-walk agreed work: - `status: approved` → design is finished. Say so and stop; suggest `/code-forge`. - No sections starting `## Design: Level` → begin Step 2 — the Entry Assessment (and its spec rule) sets the entry level. - Some levels persisted → summarize the approved levels briefly, then resume at the first missing level at or after the recorded entry level (the `[Entry]` Decisions Log entry; older docs without one → treat entry as Level 1). - Every level from entry through Level 4 persisted, but no `## Design Summary`, or `status` ≠ `approved` → go directly to Step 3. 4. **Requirement constraints**: read `requirement_doc` from the context doc frontmatter.