project-harness-bootstrap

name	project-harness-bootstrap
description	Use when starting work in a project repository that has no agent harness or an incomplete one (no root AGENTS.md canon, no .harness/ directory, no gates, no harness.lock), when a SessionStart hook reports a missing or outdated harness, or when the owner asks to set a project up for agent-driven development. Detect what exists, interview the owner, deploy the harness from the brain package, verify it, record it.
related_skills	["coding-task-pipeline","project-task-report"]

Project Harness Bootstrap

Правило владельца (2026-07-19): у каждого проекта свой полноценный харнес поверх общего глобального. Агент, начавший работу в репозитории без харнеса, сначала строит харнес вместе с владельцем и только потом ведёт задачу через него. Молча работать без харнеса нельзя.

Харнес больше не копипастится с эталонного проекта. Он разворачивается из версионируемого пакета harness/ в мозге, и расхождение проекта с пакетом считается механически. Это и есть разница с прошлой версией скилла.

Глобальный контракт остаётся каноном: проектный адаптер переопределяет маршруты (трекер, базовая ветка, команды, CI), но не ослабляет ядро coding-task-pipeline (изоляция, TDD, независимое ревью, свежая верификация, отчёт владельцу, мерж по его команде).

Шаг 0. Посмотреть, что уже есть

Проверяй, не предполагай. Расположение пакета получай через harness/bin/brain-root, не хардкодом пути.

BRAIN=$("$HOME/.claude/hooks/harness-detect.sh" >/dev/null 2>&1; \
        for c in "$AGENT_BRAIN" "$HOME/dev/brain" "$HOME/brain"; do \
          [ -n "$c" ] && [ -f "$c/AGENTS.md" ] && echo "$c" && break; done)
python3 "$BRAIN/harness/bin/harness" diff <repo>

Три исхода:

• харнеса нет — идём дальше по этому скиллу;
• дрейф — харнес есть, но отстал: покажи владельцу вывод diff и предложи harness update, полный bootstrap не нужен;
• совпадает с пакетом — ничего не строим, идём работать.

Никогда не пересобирай молча то, что уже стоит.

Шаг 1. Интервью с владельцем

Спроси один раз, одним компактным списком, и только то, чего нельзя вычитать из репозитория. Выведенные факты подтверждай, а не переспрашивай открытым вопросом.

• что за проект и стадия (активная разработка, поддержка, эксперимент);
• стек и версии (предзаполни из манифестов и лок-файлов);
• точные команды: setup, run, test, lint, build;
• базовая ветка и политика мержа (по умолчанию: агент доводит до merge-ready, мерж командует владелец);
• трекер: свой трекер проекта, задачи мозга, или пока никакого;
• границы: что можно всегда, что спросить сначала, что не трогать;
• маршрут деплоя или релиза и доступ к проду, если он есть;
• Definition of Done для типичной задачи.

Шаг 2. Выбрать стеки

Первый стек основной: только он даёт stack.sh с проверками. Остальные добавляют правила.

Признак в репозитории	Стек
*.csproj, *.sln	dotnet
next.config.*	next (плюс web)
package.json + tsconfig.json	node (плюс web, если есть UI)
pyproject.toml, requirements.txt	python
go.mod	go
уроки, видео, доски, вики, проза	content

web это оверлей поверх основного стека, а не самостоятельный стек: он добавляет правила маршрутизации фронтенд-скиллов.

Шаг 3. Развернуть

python3 "$BRAIN/harness/bin/harness" init <repo> --stack <основной> [--stack web] \
        --base-branch <ветка>

Что появится: .harness/ (гейты, правила, stack.sh, deny-commands.txt, harness.lock), AGENTS.md и CLAUDE.md, обвязка .claude/settings.json и .codex/hooks.json, симлинки .claude/skills и .agents/skills на канонический .harness/skills, запись .task-contract.json в .gitignore.

Дальше заполни плейсхолдеры {{...}} в AGENTS.md по ответам из интервью. Пустой плейсхолдер лучше выдуманного факта: если чего-то не знаешь, спроси, а не сочиняй.

Проектную специфику добавляй правильным слоем:

• правило, полезное только этому репозиторию → новый файл в .harness/rules/ с paths:;
• правило, полезное всем проектам стека → в пакет, harness/stacks/<стек>/rules/, с бампом VERSION;
• проектный скилл → .harness/skills/<имя>/SKILL.md, строка в skills/REGISTRY.md мозга;
• запрещённая команда → строка в .harness/deny-commands.txt.

Шаг 4. Проверить до первого использования

Не отчитывайся о готовности, пока не увидел это своими глазами:

• прогнать каждую команду, записанную в AGENTS.md, по одному разу; сломанные починить или честно пометить;
• уронить stop-гейт намеренно (сломанный файл в грязном дереве) и убедиться, что он не даёт завершить ход;
• дёрнуть запрещённую команду и убедиться, что pre-bash-guard её блокирует;
• тронуть файл, подпадающий под правило, и убедиться, что rules-inject подставил правило;
• harness diff <repo> показывает совпадение с пакетом.

Шаг 5. Зарегистрировать

python3 "$BRAIN/harness/bin/harness" scan --register <repo> --stack <стек> --tracker <трекер>

Плюс запись в мозге: строка проекта в memory/projects.md и страница wiki/<project>.md с [[wikilinks]]. Отметь там, где проект осознанно расходится с общим контрактом и почему. Сам харнес живёт в репозитории проекта; мозг лишь помнит, что он есть.

По манифесту потом ходит ежедневный проход: harness diff по каждому проекту, задача в tasks/inbox на каждый найденный дрейф.

Адаптеры рантаймов

Гейты общие и лежат в .harness/gates/. Рантайм отвечает только за маршрутизацию событий.

	Claude Code	Codex
канон	CLAUDE.md мостом на AGENTS.md	AGENTS.md читается нативно
хуки	.claude/settings.json	.codex/hooks.json
таймаут	миллисекунды	секунды
скиллы	.claude/skills → .harness/skills	.agents/skills → .harness/skills

Большой канон у Codex упирается в лимит суммарного размера AGENTS.md: держи корень в 150-250 строк, детали уноси в .harness/rules/ и скиллы, при необходимости подними project_doc_max_bytes.