KBD Project Orchestrator Init

Инициализация KBD Orchestrator для Claude Code. Автоматическое определение стека проекта, ограничений и настроек рабочего пространства для повышения эффективности и безопасности ИИ-кодинга.

Продуктивность и workflow GitHub

Навык kbd-init — это основа для KBD (Knowledge-Based Development) Process Orchestrator в Claude Code. Он автоматизирует сложную задачу настройки проекта, сканируя ваш репозиторий для определения ключевых технологических стеков, команд сборки и шаблонов документации. Анализируя файлы, такие как README.md, AGENTS.md и манифесты пакетов, он генерирует структурированный контекст проекта и набор машиночитаемых ограничений. Это гарантирует, что Claude работает с полным пониманием предметной области, соблюдает специфические правила «Никогда не делай» вашего проекта и использует правильные команды окружения для сборки и тестирования с самого начала.

Ключевые возможности

01Автоматическое определение команд сборки, тестирования и линтинга на основе скриптов проекта.

02Обнаружение мультикорневых рабочих областей VSCode и назначение ролей (основная vs. справочная).

03Интеллектуальное определение технологического стека для Rust, Node.js, Python, Go и других.

04Извлечение специфических ограничений проекта и правил «Никогда не делай» из AGENTS.md.

05Автоматическое обнаружение названия и описания проекта из нескольких источников метаданных.

060 звёзд на GitHub

Варианты использования

01Настройка нового проекта для ИИ-оркестрации с целью обеспечения единообразной обработки окружения.

02Ввод Claude в курc устаревшей кодовой базы путём автоматической генерации контекстного файла project.json.

03Обеспечение соблюдения строгих ограничений проекта и стилей кодирования в распределённой команде разработчиков.

name	kbd-init
description	Initialize KBD in a project. Auto-discovers project identity, stack, and constraints from existing context files (AGENTS.md, CLAUDE.md, README.md, package.json, Cargo.toml, pyproject.toml, etc.) and generates .kbd-orchestrator/project.json and .kbd-orchestrator/constraints.md. Run this once per project before any other KBD command.

/kbd-init

Initialize the KBD orchestrator for the current project.

This is the ONLY KBD command that creates project-specific configuration. All other skills read from project.json — they never write it.

What this does

Scans the current repository to auto-discover project identity and configuration, then generates two project-specific files:

.kbd-orchestrator/project.json — project context, stack commands, tool preferences
.kbd-orchestrator/constraints.md — project-specific blocking/warning rules derived from AGENTS.md "Never Do" section and known stack conventions

Does NOT modify anything in .agent/skills/kbd-process-orchestrator/. The skill directory is read-only from the project's perspective.

Discovery Algorithm

Step 1: Project Name & Description

Read in priority order:

Explicit argument: /kbd-init "My Project Name"
AGENTS.md — first H1 or "Project Identity" section
CLAUDE.md — first H1 or executive summary first sentence
README.md — first H1
package.json → name + description
Cargo.toml → [package] name + description
pyproject.toml → name + description
Repository directory name (last resort)

Step 2: Technology Stack Detection

Detect from lock files / config files:

File Present	Stack
`pnpm-lock.yaml` or `package.json` + `next.config.*`	Next.js (pnpm)
`package.json` + `vite.config.*`	Vite/React
`package.json` (no framework)	Node.js
`Cargo.toml`	Rust
`pyproject.toml`	Python
`go.mod`	Go
`build.gradle`	JVM
`.sln` or `.csproj`	.NET

Step 3: Build / Test / Lint Commands

Derive from package.json scripts, Cargo.toml, Makefile, or common conventions:

Look for build, test, lint, dev, check script keys
For Next.js: detect port from pnpm run dev script or default to 3000
For Rust: cargo check --workspace, cargo test --workspace, cargo clippy
Prepend environment path fixes as needed (e.g., nvm node path from .nvmrc)

Step 4: Spec Paths

Check in order:

openspec/specs/*.md — if openspec/ directory exists
docs/specs/*.md — if docs/specs/ exists
docs/*.md — fallback
None — set openspec_available: false

Step 5: Constraints

Read AGENTS.md sections:

"Never Do" → blocking constraints
"Always Do" → derive as warning constraints if they have machine-checkable form
"Code Style" → derive as warning constraints

If no AGENTS.md, use generic constraints from the skill's reference template.

Step 6: VSCode Workspace Discovery

Search for a .code-workspace file starting from the focus project's parent directory:

<focus_project_path>/../*.code-workspace
<focus_project_path>/../../*.code-workspace
<focus_project_path>/*.code-workspace

If found, read all folders entries and auto-assign roles:

Heuristic	Role
Folder IS the focus project (cwd or contains `AGENTS.md`)	`focus`
Folder name contains `MVP`, `legacy`, `spec`, `reference`, `old`	`reference`
Otherwise	Ask user: focus / reference / ignore

For reference folders, detect useful read paths:

src/pages/Doc*.jsx, src/pages/DocPage*.jsx — legacy spec files
docs/**/*.md — documentation
Root *.md files — readme/specs

Write the workspace block to project.json. If not found, set workspace.workspace_file = null and use single-project mode.

See references/workspace-context.md for the full specification.

Step 7: Agent Preferences

If AGENTS.md contains an "Agent-Specific Notes" section referring to specific tools, use those to populate preferred_planning_agent and preferred_execution_agents. Otherwise default to antigravity for planning and leave execution as an empty list.

Output: `.kbd-orchestrator/project.json`

Generated from references/schemas/project.template.json with discovered values:

{
  "name": "<discovered project name>",
  "description": "<discovered one-line description>",
  "active_phase": null,
  "focus_project_path": "<absolute path to focus project root>",
  "spec_paths": ["<discovered spec paths>"],
  "openspec_available": true,
  "constraint_file": ".kbd-orchestrator/constraints.md",
  "build_health_command": "<detected build command>",
  "test_command": "<detected test command>",
  "lint_command": "<detected lint command>",
  "dev_command": "<detected dev command or null>",
  "preferred_planning_agent": "<from AGENTS.md or 'antigravity'>",
  "preferred_execution_agents": ["<from AGENTS.md or empty>"],
  "agents_config": { "..." : "..." },
  "workspace": {
    "workspace_file": "<path to .code-workspace or null>",
    "folders": [
      { "path": "<focus>", "role": "focus", "write_access": true },
      { "path": "<reference>", "role": "reference", "write_access": false,
        "purpose": "<what to read from here>",
        "read_paths": ["<glob>"] }
    ]
  }
}

Output: `.kbd-orchestrator/constraints.md`

Generated from references/constraints.md template, with project-specific blocking rules derived from AGENTS.md "Never Do" section.

Idempotency

If .kbd-orchestrator/project.json already exists, print a diff of what would change and ask for confirmation before overwriting.
Using /kbd-init --force skips confirmation and overwrites.
Running /kbd-init --dry-run prints the discovered values without writing files.

How to invoke

/kbd-init                          # Auto-discover everything
/kbd-init "HotSeaters"             # Override project name
/kbd-init --force                  # Overwrite existing project.json
/kbd-init --dry-run                # Preview without writing

After Init

Run /kbd-status to confirm KBD is correctly initialized, then:

/kbd-new-phase <name> to start the first phase, OR
/kbd-assess if a phase is already defined in active_phase

Что это

KBD Project Orchestrator Init (kbd-init) — это единственный навык в экосистеме KBD, который создаёт проектную конфигурацию. Он автоматически сканирует репозиторий, определяет идентичность проекта, технологический стек, команды сборки/тестирования/линтера, пути к спецификациям, ограничения из AGENTS.md, настройки VSCode workspace и предпочтения агентов. На основе собранных данных генерируется два файла: .kbd-orchestrator/project.json (основной контекст) и .kbd-orchestrator/constraints.md (правила-ограничения). Все остальные навыки KBD только читают project.json — они никогда его не пишут.

Как работает

Алгоритм состоит из семи последовательных шагов. Каждый шаг использует приоритетный порядок источников и заполняет соответствующую секцию project.json.

Шаг 1: Имя и описание проекта

Источники проверяются в порядке убывания приоритета:

Явный аргумент: /kbd-init "My Project Name"
AGENTS.md — первый заголовок H1 или секция "Project Identity"
CLAUDE.md — первый H1 или первое предложение executive summary
README.md — первый H1
package.json → поля name и description
Cargo.toml → секция [package]
pyproject.toml → поля name и description
Имя директории репозитория (последнее средство)

Шаг 2: Определение технологического стека

По lock-файлам и конфигурационным файлам определяется стек:

pnpm-lock.yaml или package.json + next.config.* → Next.js (pnpm)
package.json + vite.config.* → Vite/React
package.json (без фреймворка) → Node.js
Cargo.toml → Rust
pyproject.toml → Python
go.mod → Go
build.gradle → JVM
*.sln или *.csproj → .NET

Шаг 3: Команды сборки, тестирования, линтинга и разработки

Извлекаются из package.json (скрипты build, test, lint, dev, check), Cargo.toml, Makefile или общих соглашений. Для Next.js дополнительно определяется порт из скрипта pnpm run dev (по умолчанию 3000). Для Rust генерируются cargo check --workspace, cargo test --workspace, cargo clippy. При необходимости добавляются коррекции путей окружения (например, путь к nvm из .nvmrc).

Шаг 4: Пути к спецификациям

Проверяются в порядке:

openspec/specs/*.md — если существует директория openspec/
docs/specs/*.md — если существует docs/specs/
docs/*.md — запасной вариант
Если ничего не найдено, устанавливается openspec_available: false

Шаг 5: Ограничения (constraints)

Читается AGENTS.md:

Секция "Never Do" → блокирующие ограничения (blocking constraints)
Секция "Always Do" → предупреждающие ограничения (warning constraints), если они имеют машиночитаемую форму
Секция "Code Style" → также предупреждающие ограничения

Если AGENTS.md отсутствует, используются общие ограничения из шаблона навыка.

Шаг 6: VSCode Workspace

Поиск файла .code-workspace начиная с родительской директории фокус-проекта:

<focus_project_path>/../*.code-workspace
<focus_project_path>/../../*.code-workspace
<focus_project_path>/*.code-workspace

Если найден, читаются все записи folders и автоматически назначаются роли:

Папка, совпадающая с фокус-проектом (cwd или содержит AGENTS.md) → focus
Имя папки содержит MVP, legacy, spec, reference, old, reference → reference
Остальные → запрос пользователю: focus / reference / ignore

Для reference-папок определяются полезные пути для чтения:

src/pages/Doc*.jsx, src/pages/DocPage*.jsx — legacy spec-файлы
docs/**/*.md — документация
Корневые *.md — readme/specs

Результат записывается в блок workspace в project.json. Если файл не найден, workspace.workspace_file = null и используется одномодульный режим.

Шаг 7: Предпочтения агентов

Если в AGENTS.md есть секция "Agent-Specific Notes", в которой упоминаются конкретные инструменты, они используются для заполнения preferred_planning_agent и preferred_execution_agents. По умолчанию для планирования назначается antigravity, а список исполнителей остаётся пустым.

Итоговые файлы

.kbd-orchestrator/project.json — генерируется из шаблона references/schemas/project.template.json и содержит:

name, description
active_phase (изначально null)
focus_project_path (абсолютный путь)
spec_paths (массив)
openspec_available (boolean)
constraint_file (путь к constraints.md)
build_health_command, test_command, lint_command, dev_command
preferred_planning_agent, preferred_execution_agents
agents_config (объект)
workspace (объект с workspace_file, folders)

.kbd-orchestrator/constraints.md — генерируется из шаблона references/constraints.md с проектно-специфичными блокирующими правилами из секции "Never Do" файла AGENTS.md.

Идемпотентность и флаги

Если .kbd-orchestrator/project.json уже существует, команда выводит diff изменений и запрашивает подтверждение перед перезаписью.
/kbd-init --force — пропускает подтверждение и перезаписывает.
/kbd-init --dry-run — выводит обнаруженные значения без записи файлов.

Пример вызова

/kbd-init                          # Автоопределение всего
/kbd-init "HotSeaters"             # Явное имя проекта
/kbd-init --force                  # Принудительная перезапись
/kbd-init --dry-run                # Предпросмотр

Когда использовать

Один раз на проект — сразу после клонирования репозитория или перед началом работы с KBD.
После инициализации рекомендуется выполнить /kbd-status, чтобы убедиться, что KBD корректно настроен.
Затем можно запускать /kbd-new-phase <name> для создания первой фазы или /kbd-assess, если фаза уже определена в active_phase.

Важно знать

Навык не изменяет ничего в директории .agent/skills/kbd-process-orchestrator/ — она доступна только для чтения.
Все остальные навыки KBD (например, kbd-process, kbd-status, kbd-new-phase) читают project.json, но никогда его не пишут.
Если в проекте используется VSCode workspace с несколькими папками, kbd-init автоматически распределяет роли (focus, reference, ignore), что позволяет организовать контекстную работу между модулями.
Для корректной работы рекомендуется наличие файлов AGENTS.md, CLAUDE.md или README.md — они дают наиболее точную информацию об идентичности проекта и ограничениях.

Install with one command.

npx skillfish add gqadonis/turboquant-rs kbd-init

Источник: https://mcpmarket.com/tools/skills/kbd-project-orchestrator-init

KBD Project Orchestrator Init

Ключевые возможности

Варианты использования

/kbd-init

What this does

Discovery Algorithm

Step 1: Project Name & Description

Step 2: Technology Stack Detection

Step 3: Build / Test / Lint Commands

Step 4: Spec Paths

Step 5: Constraints

Step 6: VSCode Workspace Discovery

Step 7: Agent Preferences

Output: `.kbd-orchestrator/project.json`

Output: `.kbd-orchestrator/constraints.md`

Idempotency

How to invoke

After Init

Что это

Как работает

Шаг 1: Имя и описание проекта

Шаг 2: Определение технологического стека

Шаг 3: Команды сборки, тестирования, линтинга и разработки

Шаг 4: Пути к спецификациям

Шаг 5: Ограничения (constraints)

Шаг 6: VSCode Workspace

Шаг 7: Предпочтения агентов

Итоговые файлы

Идемпотентность и флаги

Пример вызова

Когда использовать

Важно знать

Какие файлы kbd-init создаёт в моём проекте?

Как kbd-init определяет технологический стек моего проекта?

Могу ли я просмотреть изменения до того, как kbd-init запишет файлы?

Перезапишет ли kbd-init мою существующую конфигурацию?

Комментарии

Ключевые возможности

Варианты использования

/kbd-init

What this does

Discovery Algorithm

Step 1: Project Name & Description

Step 2: Technology Stack Detection

Step 3: Build / Test / Lint Commands

Step 4: Spec Paths

Step 5: Constraints

Step 6: VSCode Workspace Discovery

Step 7: Agent Preferences

Output: .kbd-orchestrator/project.json

Output: .kbd-orchestrator/constraints.md

Idempotency

How to invoke

After Init

Что это

Как работает

Шаг 1: Имя и описание проекта

Шаг 2: Определение технологического стека

Шаг 3: Команды сборки, тестирования, линтинга и разработки

Шаг 4: Пути к спецификациям

Шаг 5: Ограничения (constraints)

Шаг 6: VSCode Workspace

Шаг 7: Предпочтения агентов

Итоговые файлы

Идемпотентность и флаги

Пример вызова

Когда использовать

Важно знать

Какие файлы kbd-init создаёт в моём проекте?

Как kbd-init определяет технологический стек моего проекта?

Могу ли я просмотреть изменения до того, как kbd-init запишет файлы?

Перезапишет ли kbd-init мою существующую конфигурацию?

Комментарии

Output: `.kbd-orchestrator/project.json`

Output: `.kbd-orchestrator/constraints.md`