OpeItcLoc03/skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
4b4339733c418eea35b78c8c25d4bb5d811312b8
skills/skills/project-bootstrap/SKILL.md

34 KiB
Raw Blame History

name, author, version, description
name author version description
project-bootstrap ours 3.0.3 Initializes or upgrades a project in the current folder: git, .gitignore, README.md, .wiki/ using Karpathy's method, .tasks/ for task tracking, AGENTS.md (canon) with skill triggers + CLAUDE.md legacy pointer. Creates remote Gitea repo and syncs projects-meta cache for greenfield projects. Includes the mappa-bootstrap-project module (v3, решение 4 mappa-as-product): mappa MCP connect + mappa-конвенции + методика-install (версия в манифест). Use this skill when the user says "initialize project", "bootstrap", "setup project", "upgrade project", "add wiki", "add tasks", "start project", "set everything up", "create new project", or launches the agent in a new folder and wants a full setup. Trigger even if the user just says "let's start a project" or "set it all up".

Project Bootstrap

Sets up a complete working environment for a monorepo project in one pass. Operates in three modes: greenfield-full (new project + remote create), add-remote (existing git without remote), and upgrade (existing project).

Step 0 — Detect mode

Check what already exists in the current directory:

ls -la
git rev-parse --git-dir 2>/dev/null && echo "git:yes" || echo "git:no"
git remote get-url origin 2>/dev/null && echo "remote:yes" || echo "remote:no"
ls -A 2>/dev/null | grep -q . && echo "empty:no" || echo "empty:yes"
[ -d .wiki ] && echo "wiki:yes" || echo "wiki:no"
[ -d .tasks ] && echo "tasks:yes" || echo "tasks:no"
[ -f CLAUDE.md ] && echo "claude:yes" || echo "claude:no"
[ -f README.md ] && echo "readme:yes" || echo "readme:no"

Determine mode:

  • greenfield-full: git:no + empty:yes — new project, will create remote
  • add-remote: git:yes + remote:no — existing git, offer to create remote
  • upgrade: otherwise — existing project, upgrade only

Show the user a summary in one block — what was found, what will be created:

Mode: greenfield-full (new project + remote create)

Found:   (empty directory)
Create:  git  .wiki  .tasks  AGENTS.md  CLAUDE.md  .gitignore  README.md  remote

Ask one question: "Looks right? Shall we proceed?" — and wait for confirmation. Create nothing before confirmation.

Step 1 — Git

If git is not initialized:

git init

.gitignore

The template assets/.gitignore.template contains two parts:

  1. Standard ignore rules (deps, build, env, IDE, OS, logs).
  2. Meta-isolation block — !-inversions for .claude/, .tasks/, .wiki/, .brainstorm/, .archive/, .mcp/, .mcp.json, MEMORY.md. This block re-enables tracking of agent meta-paths in own repos against the global core.excludesFile rule (~/.config/git/ignore) that hides them from forks of upstream open-source. Without it, the .tasks/, .wiki/, and .claude/ directories created by Steps 3-5 would be invisible to git on machines where the global excludesFile is configured, and the first commit would be empty of agent obvyaska. Full design: workshop wiki concepts/meta-out-of-repo.md (sections "Слой 2" and "Новые проекты").

Two cases:

  • .gitignore does not exist — create from assets/.gitignore.template (block included unconditionally).
  • .gitignore exists — check for the marker line # AI обвеска — слой 2: (substring match, case-sensitive). If absent → append the meta-isolation block (with the marker comment) to the end of the file, prefixed by a blank line if the file does not already end with one. If present → leave the file untouched.

The block is scoped to own projects. The bootstrap skill currently has no fork-of-upstream mode (greenfield-full creates a brand-new Gitea repo; add-remote and upgrade operate on the user's own repos), so the block is applied unconditionally in all current modes. If a fork-bootstrap mode is ever added, the block must be omitted there — putting !.claude/ etc. into a fork's .gitignore would diverge from upstream's ignore rules.

Step 1.5 — Remote create (greenfield-full / add-remote modes)

Only in greenfield-full or add-remote mode. Skip for upgrade mode.

Prerequisites

Read ~/.config/projects-mcp/auth.toml to get Gitea credentials:

# POSIX (Linux/macOS/git-bash):
source ~/.config/projects-mcp/auth.toml 2>/dev/null || true
# Windows PowerShell:
Get-Content ~/.config/projects-mcp/auth.toml | Select-String "base_url|token"

If auth file missing → stop and tell the user (нужны Gitea-креды; скил setup-projects-meta удалён 2026-08-25).

Validate project name

Current folder name becomes the repo name. Must be:

  • Latin only — a-z, 0-9, hyphens
  • kebab-case — lowercase, hyphens between words
  • Not a duplicate — check via Gitea API
PROJECT_NAME=$(basename "$PWD")
# Validate: only latin alnum + hyphen, no leading/trailing hyphen
echo "$PROJECT_NAME" | grep -qE '^[a-z0-9]+(-[a-z0-9]+)*$' || {
    echo "❌ Invalid project name: '$PROJECT_NAME'. Use latin kebab-case (e.g. 'my-project')."
    exit 1
}

Create repo via Gitea API

# Extract base_url and token from auth.toml (POSIX):
BASE_URL=$(grep "^base_url" ~/.config/projects-mcp/auth.toml | cut -d'"' -f2)
TOKEN=$(grep "^token" ~/.config/projects-mcp/auth.toml | cut -d'"' -f2)

# Create repo:
curl -X POST "$BASE_URL/api/v1/user/repos?token=$TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"name\":\"$PROJECT_NAME\",\"private\":false,\"auto_init\":false}"

On failure → stop and show error. Duplicate name = suggest rename or delete existing.

Add remote and push

git remote add origin "$BASE_URL/$USER/$PROJECT_NAME.git"
git branch -M master
git push -u origin master

For add-remote mode (git exists, push local commits after adding remote):

git push -u origin master  # or main if that's the current branch

Step 2 — README.md

If it does not exist — create a minimal one:

# <project folder name>

## About
<!-- Describe the project here -->

## Quick start
<!-- Instructions for running the project -->

If it exists — leave it untouched.

Step 3 — вики (mappa, решение 14/15)

Канал — mappa: вики проекта = сущности type=wiki в сервисе (решения 14/15: мета в сервисе). Ничего файлового создавать не нужно; операции — using-wiki v2 (mappa wiki-тулы). Файловый .wiki/ — только для проектов вне mappa (легаси): layout по Karpathy (gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). setup-wiki умер (нечего настраивать) — при необходимости создания страниц используй wiki.create под лизом (см. using-wiki).

.wiki/
  CLAUDE.md          ← schema: project-specific wiki conventions
  index.md           ← catalog of all pages (by type), updated on every ingest
  log.md             ← append-only op log: ## [YYYY-MM-DD] op | desc
  overview.md        ← single human-readable project overview
  raw/
    README.md        ← raw/ is immutable; this file documents that
  entities/          ← entity pages (people, services, modules) — empty .gitkeep
  concepts/          ← concept / design decision pages — empty .gitkeep
  packages/          ← package pages — empty .gitkeep
  summaries/         ← one summary per ingested source (LLM, raw_path) — empty .gitkeep

Page-level workflow (ingest, query, lint) and file formats are owned by the wiki-maintainer skill. Bootstrap only lays the skeleton; the skill takes over from there.

.wiki/CLAUDE.md (schema)

# Wiki Schema — <project name>

Project-specific wiki conventions. Read this before any wiki operation.

This wiki follows Karpathy's LLM Wiki pattern:
**https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f**

The `wiki-maintainer` skill enforces the workflow and file formats. This
file overrides the skill where they conflict.

## Page types

- `entities/` — discrete things the project tracks (people, services, modules).
- `concepts/` — recurring ideas, design decisions, gotchas.
- `packages/` — code packages this project produces or consumes.
- `summaries/` — one summary page per ingested external doc; frontmatter carries `ingested:` and `raw_path:`.
- `overview.md` — single project-wide overview.

## Naming

- `kebab-case.md`, **Latin only**. Transliterate Cyrillic in filenames; keep the original title in the H1 + frontmatter.

## Domain conventions

<!-- Fill in as the project takes shape — what counts as an entity here, which packages exist, naming idioms specific to this codebase. -->

.wiki/index.md

# Wiki Index

Catalog of all wiki pages. One line per page, organized by type. The agent updates this on every ingest.

## Overview

- [overview.md](overview.md) — project overview

## Entities

<!-- (none yet) -->

## Concepts

<!-- (none yet) -->

## Packages

<!-- (none yet) -->

## Sources

<!-- (none yet) -->

.wiki/log.md

# Wiki Log

Append-only operation log. One entry per operation. Format:

\`\`\`
## [YYYY-MM-DD] <op> | <one-line description>
\`\`\`

Operations: `init`, `ingest`, `query`, `lint`, `refactor`, `decision`.

Parseable: `grep "^## \[" .wiki/log.md | tail -20`.

---

## [<today's date>] init | bootstrap empty wiki via project-bootstrap

.wiki/overview.md

# <project name> — overview

<!-- Replace with a high-level description: what this project does, who it's for, the main components. -->

.wiki/raw/README.md

# Raw Sources

**Immutable.** Read, never edit. The only allowed modification is appending a `> Status:` blockquote when the user explicitly asks for a status audit.

Place raw inputs here — articles, transcripts, PDFs, screenshots — exactly as they came in. The agent reads from `raw/`, writes summaries into `../summaries/`, and never modifies raw files.

For large or path-sensitive sources that live outside the repo, register them here:

\`\`\`
- short-name → /absolute/path/to/source
\`\`\`

The empty subdirectories (entities/, concepts/, packages/, summaries/) each get a .gitkeep so git tracks them.

Step 4 — таски (mappa, решение 14/15)

Канал — mappa: борд проекта = сущности type=task в сервисе (решения 14/15: мета в сервисе). Ничего файлового создавать не нужно; операции — using-tasks v2 (mappa task-тулы). Файловый .tasks/ — только для проектов вне mappa (легаси: STATUS.md + per-task файлы). setup-tasks умер (нечего настраивать) — таски создаются через task_create под лизом (см. using-tasks/task-format).

Step 5 — AGENTS.md (canon) + CLAUDE.md pointer

Canon is AGENTS.md (cross-agent standard: pi prefers AGENTS.md over CLAUDE.md when both exist — confirmed in pi's resource-loader; Claude Code reads AGENTS.md as fallback). CLAUDE.md is a legacy pointer file for tooling that looks for it by name. Both files are always written together; the canon content lives only in AGENTS.md.

Three paths, picked by file presence:

Init (neither file exists)

Create AGENTS.md from assets/AGENTS.md.template (canon content). Substitute the platform line on non-Windows hosts (we're on Linux / we're on macOS instead of we're on Windows). Then write the CLAUDE.md pointer:

# CLAUDE.md — legacy pointer

Canon is `AGENTS.md`. Read `AGENTS.md` — it contains all project instructions.

Migrate (CLAUDE.md exists, AGENTS.md does not)

The project predates the AGENTS.md canon. Offer to migrate: git mv CLAUDE.md AGENTS.md, fix the first-line header if it was # CLAUDE.md, then write the CLAUDE.md pointer. Ask one question — "Migrate CLAUDE.md → AGENTS.md?" — and wait for confirmation. On confirm, proceed to the Upgrade merge below.

Upgrade (AGENTS.md exists) — idempotent merge

Treat the template as the canonical trigger set and reconcile the existing file against it. Re-runs are no-ops once the file is in canon.

  1. Read the existing AGENTS.md.
  2. For each non-empty, non-comment line in the template, decide whether it's already present:
    • Trigger lines (everything except the platform line) — present iff any existing line, after trim + tolower, contains the template line's trigger text. Substring match, not equality — tolerates user rewording or trailing punctuation.
    • Platform line (we're on Windows) — present iff any existing line matches we're on (windows|linux|macos) case-insensitively. If the user pinned a different platform on purpose, leave it alone. Only append the host-appropriate platform line when none of the three is present.
  3. Collect missing lines. If none → print AGENTS.md already canon — no changes and skip to Step 5.5.
  4. Show the user the diff (N lines, exact text to append) and ask one question: "Append these N missing canonical triggers to the end of AGENTS.md?" Wait for explicit confirmation before writing.
  5. On confirm: append a single newline (if the file doesn't end with one) and then the missing lines, one per line. Don't rewrite the file — only append. Don't reorder existing lines. Don't dedupe within the existing file.
  6. Ensure the CLAUDE.md pointer exists; if missing, write it.

Template contents (assets/AGENTS.md.template — source of truth):

# AGENTS.md
# Agent instructions. Each line is a trigger for an installed skill.

talk like a caveman
use project wiki
use task management system
check across all projects
pull remote before work
follow project discipline
follow tdd-criteria
delegate to interns when allowed
recommend, don't menu
we're on Windows

The check across all projects trigger activates the mappa tooling (mcp__mappa__*) — cross-project boards, shared wiki and the project registry live in mappa. The file-based projects-meta-mcp and its skills (using-projects-meta, setup-projects-meta, meta-host-routing, setup-wiki, setup-tasks) were removed 2026-08-25; the shared projects-wiki files are stubs «не читать, не править» — канон mappa shared-scope.

The pull remote before work line activates the pulling-before-work skill, which runs one git pull --ff-only at session start (and on explicit re-sync requests like "sync"). It's a no-op outside git repos and skips with a one-line warning if the working tree is dirty, HEAD is detached, or the branch has no upstream — never auto-merges, stashes, or pushes. Install the skill on the host if pulling-before-work is not in ~/.claude/skills/; otherwise the trigger is silently dead like any other absent skill.

The follow project discipline line activates the project-discipline skill, which codifies four cross-project rules: (1) project AGENTS.md / CLAUDE.md / .wiki/CLAUDE.md / .tasks/ override defaults from any other skill; (2) all work on master/main, no feature branches without explicit user approval; (3) version bump on every edit of versioned artifacts per semver, recorded in commit; (4) commit freely, push only after explicit per-session approval. Install the skill on the host if project-discipline is not in ~/.claude/skills/; otherwise the trigger is silently dead like any other absent skill.

The follow tdd-criteria line activates the tdd-criteria skill, which enforces test-driven development by default with four bright-line carve-outs (visual CSS, spike exploration, oneshot scripts, pure wrappers) and four anti-loophole rules (including test-immutability: modifying assertions requires a [test-modify: ...] marker in the commit subject). Full rationale at .wiki/concepts/tdd-criteria-design.md in the skills repo. Install the skill on the host if tdd-criteria is not in ~/.claude/skills/; otherwise the trigger is silently dead like any other absent skill.

The delegate to interns when allowed line activates the using-interns skill, which lets Claude offload predictable bulk I/O and summarization tasks (reading 3+ files, distilling long transcripts) to cheap intern LLMs via the local interns MCP server (mcp__interns__bulk_text_read, mcp__interns__transcript_distill, etc.) — saves Anthropic quota at ~125× the per-call cost reduction on bulk reads. Per-session permission grant mirrors project-discipline Rule 4: ask-mode default, conversational grant / revoke, always-ask paths for .env / secrets / keys / SSH credentials even with an active grant, session-end reset. The skill is a no-op until the interns MCP server is registered — install via setup-interns on a fresh machine if mcp__interns__* tools are missing. Full design at .wiki/concepts/interns-design.md in the skills repo.

The recommend, don't menu line activates the recommend-dont-menu skill, which replaces the default brainstorming behavior: in design discussions, architecture reviews, or "what should we do" questions, the agent gives one argued recommendation with explicit trade-offs, not a multiple-choice menu. User instructions always take precedence over skill defaults. Install the skill on the host if recommend-dont-menu is not in ~/.claude/skills/; otherwise the trigger is silently dead like any other absent skill.

The we're on Windows line activates the active-platform skill and pins the project's default platform to Windows / PowerShell — so generated commands and README quick-starts use PS-native syntax. Bootstrapping on a Linux or macOS host? Substitute we're on Linux or we're on macOS instead.

Step 5.5 — Bootstrap manifest

Write .wiki/concepts/bootstrap-manifest.md. The manifest records which skills (and at which versions) initialized this project's .wiki/ and .tasks/ layout, so layout drift between projects bootstrapped at different times is debuggable.

Read each delegated skill's SKILL.md frontmatter to pick up the live version: value (don't hardcode):

---
title: Bootstrap Manifest
type: concept
updated: <today's date>
generator: project-bootstrap@<version>
---

# Bootstrap Manifest

Skills used to initialize this project's `.wiki/` and `.tasks/` layout, with their versions at install time.

| Skill | Version | Role |
|---|---|---|
| `project-bootstrap` | <version> | orchestrator |
| `project-discipline` | <version> | cross-project policy |
| `setup-interns` | <version> | interns MCP server install (one-time, per machine) |
| `using-interns` | <version> | interns runtime policy + per-session permission grant |
| `mappa-*` (методика, модуль 5.7) | <version of reference-package skills> | mappa-циклы: session-orient / task-work / knowledge / messaging / delegation / brainstorm-promote / closing-ritual |

Модуль `mappa-bootstrap-project` (решение 4 mappa-as-product) фиксирует
версию методики в этой строке — читать `version:` из frontmatter каждого
mappa-скилла, не хардкодить. Если пакет не установлен — `unknown` (видно
в депс-чеке 5.6).

This file is overwritten if `project-bootstrap` is re-run on the same project. For history, use `git log .wiki/concepts/bootstrap-manifest.md`.

If a delegated setup-skill is unavailable on this machine (e.g. user installed only a subset), record the missing skill as unknown in the version column so the gap is visible.

Step 5.6 — Skill dependencies check (chat-only, never auto-install)

The AGENTS.md template just written contains canonical trigger lines. Each one is a no-op unless the corresponding skill or plugin is installed on the host. On a fresh machine these are often absent, and the user won't know the trigger is silently dead. Detect what's missing on this machine and print one informational block in chat — never write into any project file, never auto-install.

Trigger → fulfiller map

Source of truth for this map is the canonical assets/AGENTS.md.template. When a new trigger is added there, also add a row here in the same commit. Mismatch between template and map → silent gaps in the recommendation.

Trigger line in AGENTS.md Fulfiller Kind Detection path Install command
talk like a caveman caveman skill ~/.claude/skills/caveman/SKILL.md bash scripts/install.sh caveman
use project wiki using-wiki skill ~/.claude/skills/using-wiki/SKILL.md bash scripts/install.sh using-wiki
use task management system using-tasks skill ~/.claude/skills/using-tasks/SKILL.md bash scripts/install.sh using-tasks
check across all projects mappa (mcp__mappa__*) MCP mcpServers.mappa in ~/.claude.json —
pull remote before work pulling-before-work skill ~/.claude/skills/pulling-before-work/SKILL.md bash scripts/install.sh pulling-before-work
session handoff: read on start, write on end session-handoff skill ~/.claude/skills/session-handoff/SKILL.md bash scripts/install.sh session-handoff
follow project discipline project-discipline skill ~/.claude/skills/project-discipline/SKILL.md bash scripts/install.sh project-discipline
follow tdd-criteria tdd-criteria skill ~/.claude/skills/tdd-criteria/SKILL.md bash scripts/install.sh tdd-criteria
delegate to interns when allowed using-interns skill ~/.claude/skills/using-interns/SKILL.md bash scripts/install.sh using-interns
recommend, don't menu recommend-dont-menu skill ~/.claude/skills/recommend-dont-menu/SKILL.md bash scripts/install.sh recommend-dont-menu
use project wiki mappa-knowledge skill ~/.claude/skills/mappa-knowledge/SKILL.md bash scripts/install.sh mappa-knowledge
use task management system mappa-task-work skill ~/.claude/skills/mappa-task-work/SKILL.md bash scripts/install.sh mappa-task-work
inbox monitor: raise on start mappa-session-orient skill ~/.claude/skills/mappa-session-orient/SKILL.md bash scripts/install.sh mappa-session-orient
we're on Windows / we're on Linux / we're on macOS active-platform skill ~/.claude/skills/active-platform/SKILL.md bash scripts/install.sh active-platform

Algorithm

  1. Read the project's AGENTS.md (just-written or pre-existing). Extract every non-empty, non-comment line — these are the active triggers for THIS project. The user may have removed canonical lines on purpose; respect that — only check what's actually in the file.

  2. Match each line against the trigger column above using trim + tolower substring (same matching as Step 5 idempotent merge). Lines that don't match any row are user-custom — skip silently. The platform line matches the active-platform row regardless of which platform is pinned.

  3. For each matched canonical line, check the detection path:

    • kind: skill → does ~/.claude/skills/<name>/SKILL.md or ~/.agents/skills/<name>/SKILL.md exist? (Skill installs can land in either host path — scripts/install.sh writes ~/.claude/skills/, a manual/alternate install may use ~/.agents/skills/; a skill present in either path fulfills the trigger. Same two-path rule as Step 5.7.3.)
    • kind: plugin → does ~/.claude/plugins/installed_plugins.json contain the plugin key under plugins? (Treat malformed JSON as "missing" and continue — don't crash the bootstrap over a detection edge case.)

  4. Collect every fulfiller that's missing. Two outcomes:

    • All present — print one line:

      ✅ all skill dependencies satisfied — every AGENTS.md trigger has its fulfiller on this host.

      Skip to Step 6.

    • Some missing — print one block in chat exactly once. Do not write it into any project file:

      ℹ️  Recommended: install the following to fulfill AGENTS.md triggers

The triggers below are present in AGENTS.md but their fulfillers are
missing on this machine — they're silently no-ops until installed:

  trigger                                  fulfiller (kind)
  <trigger-line>                           <fulfiller> (<kind>)
  <trigger-line>                           <fulfiller> (<kind>)
  …

Install (run inside Claude Code or terminal):
  <install command 1>
  <install command 2>
  …

After install + (for plugins) a Claude Code restart, the triggers pick
them up.

Notes

  • MCP-server-backed skills (using-context7, using-projects-meta, using-interns) — only the using-X policy skill is checked here. If the MCP isn't registered, the using-X Prerequisites pointer fires setup-X at first use; bootstrap doesn't duplicate that detection.
  • The ~/.claude/skills/ and ~/.claude/plugins/ paths resolve identically on Windows / Linux / macOS — ~ works under git-bash too.
  • Detection paths (unified with Step 5.7.3): a kind: skill fulfiller is considered present if its SKILL.md exists in ~/.claude/skills/<name>/ OR ~/.agents/skills/<name>/. The dependency tables below list the canonical install path (~/.claude/skills/, what scripts/install.sh writes); detection itself accepts both.
  • Hard rule — never auto-install. Slash commands aren't callable from a skill, and silently mutating user-level skill / plugin state without consent is overreach. The recommendation is informational. The user can install some / all / none of the recommendations, or remove canonical lines from AGENTS.md to lean the project's trigger set down.

Step 5.7 — mappa-bootstrap-project (модуль, решение 4 mappa-as-product)

Спека: .wiki/concepts/mappa-as-product.md (wiki:2672), решение 4. Модуль вызывается project-bootstrap'ом как шаг в режимах greenfield-full и upgrade. Скоуп: connect (MCP) + mappa-конвенции в AGENTS.md (idempotent merge) + методика-install (пакет из репо, версия в манифест) + manifest/deps-check.

5.7.1 — Connect (MCP)

Проверить, что mappa MCP-сервер зарегистрирован на этой машине. Канон — ~/.claude.json → mcpServers.mappa (stdio: node <repo>/dist/src/mcp-entry.js, env MAPPA_CORE_URL + MAPPA_API_TOKEN). pi-рантайм читает ту же регистрацию через MCP-адаптер.

# POSIX / Windows (git-bash):
python -c "import json; d=json.load(open('$HOME/.claude.json')); print('mappa' in d.get('mcpServers', {}))"

  • Зарегистрирован → пропустить, идти к 5.7.2.

  • Не зарегистрирован → печать одного информационного блока (НЕ авто-инсталл, то же правило что 5.6):

    ℹ️  mappa MCP не зарегистрирован (~/.claude.json mcpServers.mappa отсутствует).
    Установка: собери репо mappa (npm run build) и добавь в mcpServers:
    { "type": "stdio", "command": "node",
      "args": ["<mappa-repo>/dist/src/mcp-entry.js"],
      "env": { "MAPPA_CORE_URL": "...", "MAPPA_API_TOKEN": "..." } }
    Секреты — из pass (см. secret:<path> реф-стиль, wiki:2672 решение 11).

    mappa-конвенции в AGENTS.md (5.7.2) можно добавлять и без MCP-регистрации — триггеры будут ждать установки сервера (как любой absent-скилл).

5.7.2 — mappa-конвенции в AGENTS.md (idempotent merge)

mappa-специфичные триггеры уже в каноне шаблона (Step 5) — inbox monitor: raise on start, use project wiki, use task management system. Это не отдельный merge: существующая идемпотентная машинерия Step 5 покрывает их. Модуль только верифицирует: после Step 5 убедиться, что строки на месте (та же substring-проверка что в Step 5 upgrade-merge). Если пользователь сознательно убрал их из AGENTS.md — не возвращать (уважать выбор).

5.7.3 — методика-install (пакет из репо, версия в манифест)

Методика = reference-пакет (wiki:2672 решение 3/6): plain skills живут в репо skills (scripts/install.sh <name>...). project-bootstrap НЕ хранит тела — только указывает на пакет.

  1. Определить список mappa-циклов: mappa-session-orient, mappa-task-work, mappa-knowledge, mappa-messaging, mappa-delegation, mappa-brainstorm-promote, mappa-closing-ritual.
  2. Проверить установку по правилу детекта Step 5.6 (оба пути: ~/.claude/skills/ и ~/.agents/skills/)? → да: пропустить (upgrade-императив не дублировать).
  3. Нет → печать информационного блока (НЕ авто-инсталл, правило 5.6):
ℹ️  Методика mappa не установлена. Установка:
    git clone <skills-repo> && scripts/install.sh mappa-session-orient mappa-task-work ...
  1. Версия методики фиксируется в bootstrap-manifest (5.7.4): читать SKILL.md frontmatter каждого mappa-скилла (version:), не хардкодить.

5.7.4 — manifest/deps-check

Манифест (Step 5.5) дополняется строкой методики — версия = версия reference-пакета (репо skills, version из frontmatter скиллов). Добавить в таблицу манифеста:

Skill Version Role
mappa-bootstrap-project (модуль) connect + конвенции + методика-install

Deps-check (Step 5.6): mappa-триггеры (inbox monitor: raise on start, use project wiki, use task management system) маппятся на fulfiller'ы:

Trigger line Fulfiller Kind Detection
use project wiki mappa-knowledge skill ~/.claude/skills/mappa-knowledge/SKILL.md
use task management system mappa-task-work skill ~/.claude/skills/mappa-task-work/SKILL.md
inbox monitor: raise on start mappa-session-orient skill ~/.claude/skills/mappa-session-orient/SKILL.md

Недостающие mappa-скиллы → в блок рекомендаций 5.6 (тем же форматом).

Step 6 — Commit

git add .
git commit -m "chore: bootstrap project structure"

If the repo already had commits — commit only the files just created:

git add .wiki/ .tasks/ AGENTS.md CLAUDE.md .gitignore README.md
git commit -m "chore: upgrade project structure"

Step 7 — Summary

Print a final report:

✅ Done! Created:
  .wiki/          — project wiki (Karpathy method)
  .tasks/         — task tracking system
  AGENTS.md     — skill triggers (canon)
  CLAUDE.md     — legacy pointer
  .gitignore      — standard template
  README.md       — starter file
  remote          — Gitea repo created and pushed
  mappa           — mappa-bootstrap-project: connect + конвенции + методика (модуль 5.7)

Skipped (already existed):
  git             — left untouched

Next step: describe the project in README.md and start your first task —
say "use task management system".

For greenfield-full mode, append to summary:

Remote: <Gitea URL>

Step 8 — mappa registry (greenfield-full mode)

Only in greenfield-full mode. Register the new project in mappa (mcp__mappa__projects_register) so it becomes visible in the registry.

# POSIX:
node ~/projects/.common/lib/projects-meta-mcp/dist/sync.js

# Windows PowerShell:
node ~/projects/.common/lib/projects-meta-mcp/dist/sync.js

Verify the project is now visible:

# Via MCP (if available in current session):
# mcp__projects-meta__meta_status

# Or manually check the cache file exists:
ls -la ~/projects/.common/lib/projects-meta-mcp/cache/projects.json

If the sync script doesn't exist → skip with informational message:

ℹ️  projects-meta sync script not found at ~/projects/.common/lib/projects-meta-mcp/dist/sync.js
    Run /setup-projects-meta to install it. The new repo is already created in Gitea.

Step 9 — Address book registration

Register the new project in the inter-session address book so other agents can write letters to it (inter-session-messaging skill).

The address book lives in the shared wiki clone: ~/projects/.wiki/concepts/projects-address-book.md — a markdown table with columns адрес (папка) | qualified | роль. The address is the folder name as is; the qualified name comes from the remote just created.

  1. Read the current table from ~/projects/.wiki/concepts/projects-address-book.md.
  2. Append a row: 
    | <folder-name> | <owner>/<repo> | <role> |
    <folder-name> is the local folder name as-is (e.g. .common, books); <owner>/<repo> is the qualified Gitea name from the remote; <role> — short description (boss-zone, ops, infra, app, …).
  3. Do not overwrite existing rows — append only, keep the table sorted.
  4. Commit + push the shared wiki repo (~/projects/.wiki).

If the file doesn't exist yet (book not bootstrapped) → create it with the canonical header and this project as the first row, then push.

Rules

  • Never overwrite existing files without explicit user confirmation
  • Always show the plan first — one question, one confirmation
  • Never invent details — if the project already exists, read what's there
  • Commit only what was just created — do not touch the rest of the file tree
  • Commit automatically after each successful step, no extra questions
  • Push only after explicit user confirmation — ask "Push to remote?" and wait for "yes"
Reference in New Issue View Git Blame Copy Permalink