REFERENCE
Profiles & configuration
When you run /kit-init, you pick a profile — a role preset that decides which agents, skills, and rules land in your project. After that, everything the kit knows about your project lives in one small file. This page is the map.
The five profiles
A profile is a starting point, not a cage. You can always reshape it later with /kit-customize.
| Profile | Best for | You get |
|---|---|---|
software | Building a product end to end | A full team: PM, Tech Lead, Designer, DevOps, Backend, Frontend, QA, Security — plus the task workflow, design routing, and stack-aware build skills |
content | Writing, publishing, brand work | PM, Editor, Designer, Researcher — with a copywriting skill and the task workflow |
research | Investigation and synthesis | PM, Researcher, Analyst — focused on scope, gather, analyze, report |
automation | n8n / workflow automation | PM, an n8n specialist (with the n8n-* skills and mcp__n8n__* tools), and a generalist |
minimal | A lean, flexible setup | A PM plus one generalist that flexes to any task |
Not sure which to choose? minimal is the gentle entry point, and /kit-update lets you grow into more later. Preview any choice first:
/kit-init --dry-run
What each profile sets up
Every profile defines its own agents, skills, rules, role names, and milestone names. A quick comparison of the rhythm each one assumes:
| Profile | Milestones |
|---|---|
software | Foundation → MVP → Beta → GA |
content | Outline → Draft → Review → Publish |
research | Scope → Gather → Analyze → Report |
automation | Backlog → Building → Live |
minimal | Backlog → Doing → Done |
Your project's settings file
After init, .claude/kit.config.json holds every project-specific value — one source of truth that the kit reads at runtime. You rarely edit it by hand, but here's what each key means.
| Key | What it holds |
|---|---|
project | Your project's name, slug, owner, and language |
profile | Which profile you started from |
roles | The role names in your org (editable) |
github | Repo, owner, and whether the GitHub Projects board is on |
plans | How plans are written — markdown, mdx, or none — and where they live |
memory | Whether MemPalace memory is on, and your project's "wing" |
specKit | Whether spec-driven development is enabled |
prePush | A command to run before git push (blocks the push if it fails) |
annotate | Whether visual UI annotation is wired, plus its framework and backend |
kitVersion | The kit version this project last synced with — powers /kit-update |
skillPrompts | Your remembered answers to skill-gap questions, so the kit won't ask twice |
You commit this file with your team. Settings that can hold secrets stay out of git automatically.
Folder-wide overrides
If one folder holds several projects, you can set shared preferences once. Drop a .claudekit/config.json into a parent folder and it cascades to everything beneath it — like .editorconfig. The nearest folder wins and merges over each project's own config, so shared defaults apply without trampling a project's specific choices.
How it works under the hood
Where settings come from. /kit-init reads the chosen profiles/*.json, substitutes your project values into the templates, resolves conditional blocks (IF:MEMORY, IF:PROJECTS_V2, IF:PLANS, IF:DESIGN), and writes a self-contained .claude/. Skills read live values from .claude/kit.config.json at runtime, so there's one source of truth per project.
Profile JSON shape. Each profile declares agents, skills, rules, roles, milestones, and a defaults block (e.g. plans_format, memory, speckit). Example, from software:
{
"name": "software",
"agents": ["pm", "tech-lead", "designer", "devops", "backend", "frontend", "qa", "security"],
"rules": ["communication-style", "task-management", "plan-output-format", "design-routing", "mempalace", "skill-gaps"],
"milestones": ["Foundation", "MVP", "Beta", "GA"],
"defaults": { "plans_format": "markdown", "memory": "off", "speckit": "off" }
}
KIT_* environment. Project scripts source scripts/lib/kit-config.sh and call load_kit_config, which flattens kit.config.json into environment variables:
| Variable | From |
|---|---|
KIT_VERSION | .kitVersion |
KIT_PROJECT_NAME · KIT_PROJECT_SLUG · KIT_OWNER_NAME · KIT_LANG | .project.* |
KIT_PROFILE | .profile |
KIT_REPO · KIT_OWNER · KIT_PROJECTS_V2 · KIT_PROJECT_NUMBER · KIT_PROJECT_TITLE | .github.* |
KIT_PLANS_FORMAT · KIT_PLANS_DIR | .plans.* |
KIT_MEMORY · KIT_WING | .memory.* |
KIT_SPECKIT | .specKit.enabled |
KIT_ANNOTATE_ENABLED · KIT_ANNOTATE_BACKEND · KIT_ANNOTATE_FRAMEWORK | .annotate.* |
KIT_ROLES · KIT_MILESTONES | .roles[] · .milestones[] (newline-delimited) |
Loading requires jq. If .claude/kit.config.json is missing, it tells you to run /kit-init first.
.claudekit overlays. After loading, load_kit_config walks ancestor directories for .claudekit/config.json files and deep-merges them over the project config (far → near, nearest wins) using jq '.[0] * .[1]'. It re-exports the fields that make sense at folder scope — KIT_LANG, KIT_PLANS_FORMAT, and the KIT_ANNOTATE_* set — and exposes the fully merged result as KIT_EFFECTIVE_CONFIG. Projects with no .claudekit/ behave exactly as before.