Skip to main content

FOR EVERYONE

Scaffold a project — /kit-init

/kit-init is how a project gets its team. You run it once, answer a few friendly questions, and the kit writes a tidy, self-contained .claude/ shaped around the kind of work you do.

What it asks​

When you run /kit-init, it walks you through a short setup:

  • Profile — the starting team (software, content, research, automation, or minimal).
  • Repo — your GitHub repo, so the task workflow has somewhere to live.
  • Board — whether to turn on a GitHub Projects board.
  • Memory — whether to keep a per-project memory (off by default).
  • Language — the language the team communicates in.

Then it scaffolds .claude/ and a CLAUDE.md entry point. Everything after — roles, milestones, plan format — follows from your choices.

Preview before you commit​

You never have to scaffold blind. Ask /kit-init to preview, or run with --dry-run, and it prints exactly which files it would write — and writes nothing.

# Look first, then do it for real
/kit-init --dry-run
/kit-init

Opt-in tool setup​

During setup, /kit-init offers to connect a few tools — and explains each one before touching anything:

  • gh (GitHub CLI) — checks you're logged in, offers to log you in. Powers the task/PR workflow.
  • MemPalace — only if you turn on memory. Registers the memory server (or guides installing it). It stays dormant and never errors until it's present.
  • gws (Google Workspace CLI) — only if you work with Google Docs/Sheets/Slides/Drive/Gmail. Skipped otherwise.

Nothing is installed or authenticated without your say-so.

What lands in your project​

your-project/
  CLAUDE.md              # entry point — points the team at .claude/
  .claude/               # agents · skills · rules · kit.config.json · settings
  docs/plans/            # implementation / ops plans
  scripts/               # kit helpers (labels, milestones, task board, …)
  …your code…

Commit .claude/ and your whole team shares the exact same setup.

One project at a time​

claude-kit is per project. In a workspace or monorepo, run /kit-init in each project rather than once at the root — it detects which situation you're in and recommends accordingly. Why: each project gets its own memory "wing," and its setup travels with its repo. More in Multiple projects.

How it works under the hood
  • The engine. /kit-init runs scripts/init.sh, a plain bash substitution-and-conditional engine. It reads the chosen profiles/*.json, substitutes your project values into the templates/ ({{VARS}}), and resolves conditional blocks — IF:MEMORY, IF:PROJECTS_V2, IF:PLANS, IF:DESIGN — into a fresh .claude/.
  • Flags. --profile <software|content|research|automation|minimal>, --target <dir>, --name, --slug, --repo, --memory <on|off>, --speckit <on|off>, --prepush "<command>", --lang, plus --dry-run (plan only) and --upgrade (the safe merge used by /kit-update).
  • One source of truth. Skills read live values from .claude/kit.config.json at runtime, so the project has a single config the whole team agrees on.
  • Requirements. jq, perl, git, and bash 3.2+. gh (authenticated) for the workflow.

Where to go next​