Claude-native starter kit that bootstraps multi-agent team infrastructure for any project. Clone once, install as a global skill, run /kit-install in any project directory. Includes: - 3-tier profile system (minimal/standard/full: 3-12 agents) - 16 agent archetype templates with personality spectrum - 18 skill templates using domain-action naming convention - Stakeholder persona panel for workshops and PR reviews - SQLite ticketing DB with CLI tools (config-based DB paths) - Decision tracking, sprint lifecycle, workshop orchestration - Multi-git-host support (GitHub, Gitea, GitLab) - /kit-update skill for syncing with source repo evolution - Naming theme support for agent identity/flavor - Smoke tests for all three profile tiers Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
182 lines
10 KiB
Markdown
182 lines
10 KiB
Markdown
---
|
|
name: kit-install
|
|
description: >
|
|
Bootstrap multi-agent team infrastructure for any project. Use when
|
|
starting a new project, adding team infrastructure, or running /kit-install.
|
|
Detects tech stack, asks about team composition, and deploys adapted
|
|
templates — agents, skills, DB, decisions, and workflows. For updating
|
|
an existing installation, use /kit-update instead.
|
|
user-invocable: true
|
|
allowed-tools: Bash, Read, Grep, Glob, Write, Edit, AskUserQuestion
|
|
---
|
|
|
|
# /kit-install — Multi-Agent Team Bootstrap
|
|
|
|
You are the kit installer. Your job is to bootstrap multi-agent team infrastructure for the user's project. Follow these five steps exactly.
|
|
|
|
## Step 1: Detect Context
|
|
|
|
Scan the project root for tech stack indicators. Read any files you find (don't guess — read them):
|
|
|
|
- `package.json` — Node.js/TypeScript project. Note framework (React, Next.js, Express, etc.)
|
|
- `Cargo.toml` — Rust project. Note workspace members, key dependencies (bevy, actix, tokio, etc.)
|
|
- `project.godot` — Godot project. Note Godot version from the file.
|
|
- `pyproject.toml` or `setup.py` — Python project. Note framework (Django, FastAPI, Flask, etc.)
|
|
- `go.mod` — Go project. Note module path and key dependencies.
|
|
- `pom.xml` or `build.gradle` — Java/Kotlin project. Note framework (Spring, Quarkus, etc.)
|
|
- `*.sln` or `*.csproj` — .NET project. Note framework version.
|
|
- `Makefile`, `CMakeLists.txt` — C/C++ project.
|
|
- `mix.exs` — Elixir project.
|
|
- `Gemfile` — Ruby project.
|
|
|
|
Also detect:
|
|
- **Git remote**: Run `git remote -v` to determine the host (GitHub, Gitea, GitLab, Bitbucket, or other). This determines which CLI patterns to use.
|
|
- **Existing `.claude/` directory**: If one exists, note what's already present. The installer should augment, not overwrite.
|
|
- **Existing `CLAUDE.md`**: If present, the installer should merge new instructions into it rather than replacing it.
|
|
- **Monorepo structure**: Check for workspace files, multiple package.json files, or other signs of a monorepo.
|
|
|
|
Summarize what you found before proceeding.
|
|
|
|
## Step 2: Ask User
|
|
|
|
Use AskUserQuestion to gather project preferences. Ask these questions (combine into as few AskUserQuestion calls as possible):
|
|
|
|
**Question 1: Profile**
|
|
- **minimal** (Recommended for solo/small projects) — 3 agents (architect, project-manager, qa-engineer), basic skills (git-commit, skill-create), CLAUDE.md + settings.json + Makefile
|
|
- **standard** — 6 agents, ticketing DB + CLIs, decisions tracking, git hooks, 8 skills
|
|
- **full** — 11 agents, Qdrant semantic search, briefings, sprints, workshops, 17 skills
|
|
|
|
**Question 2: Project identity**
|
|
Ask for project name and a one-line description. Suggest defaults based on the git remote or directory name.
|
|
|
|
**Question 3: Team composition**
|
|
Based on the detected tech stack and chosen profile, suggest which archetypes to include. Show the list from `references/archetype-gallery.md` filtered to the chosen profile's agent count. Let the user swap archetypes.
|
|
|
|
**Question 4: Stakeholder personas** (standard/full only)
|
|
Suggest personas relevant to the detected project type. Let the user customize.
|
|
|
|
**Question 5: Git host**
|
|
Confirm the detected git host. Ask for any required credentials/flags:
|
|
- GitHub: usually no extra config needed
|
|
- Gitea: needs `--login`, `--repo`, `--output simple` flags
|
|
- GitLab: usually no extra config needed
|
|
|
|
**Question 6: Worktree vs single-branch** (standard/full only)
|
|
- Single-branch (Recommended for most projects) — all work on feature branches from main
|
|
- Worktree — multiple long-lived branches, each in its own worktree directory
|
|
|
|
**Question 7: Naming theme** (optional, all profiles)
|
|
Ask the user if they want a naming theme for their agents. This adds personality and makes the team memorable. Suggest themes based on the project domain:
|
|
- **Literature**: Characters from a favorite book series (e.g., The Settled Reach uses Peter F. Hamilton's Commonwealth characters)
|
|
- **Mythology**: Greek gods, Norse mythology, Egyptian pantheon
|
|
- **Science**: Famous scientists, elements, constellations
|
|
- **Music**: Composers, instruments, genres
|
|
- **Nature**: Trees, rivers, mountains, animals
|
|
- **None**: Use the archetype names directly (architect, qa-engineer, etc.)
|
|
|
|
If the user chooses a theme, rename each agent file and adapt the personality to include a thematic connection. For example, if the theme is "Greek mythology" and the architect archetype becomes "athena", the personality intro might reference Athena's wisdom and strategic thinking.
|
|
|
|
**Question 8: Services** (full only)
|
|
- Qdrant URL (or skip for grep-only document search)
|
|
- Ollama URL and embedding model (or skip)
|
|
|
|
## Step 3: Deploy Static Files
|
|
|
|
Copy static infrastructure files from the kit's `static/` directory:
|
|
|
|
1. **Database**: Copy `static/db/schema.sql` and `static/db/connectors/` to the project's `db/` directory.
|
|
2. **Config**: Write `db/connectors/config.json` with the user's service URLs (or sensible defaults).
|
|
3. **Initialize DB**: Run `python3 db/connectors/sqlite_connector.py init` (or equivalent) to create the SQLite database.
|
|
4. **Git hooks** (standard/full): Read the hook templates from `templates/.config/hooks/` and adapt for the project.
|
|
5. **Makefile**: If no Makefile exists, write one with standard targets (build, test, lint, format, clean, help). Adapt targets to the detected tech stack.
|
|
|
|
Do NOT copy files blindly. Read each static file first and confirm it's appropriate for the target project.
|
|
|
|
## Step 4: Adapt and Write Templates
|
|
|
|
This is the critical step. For each template file, you must:
|
|
1. **Read** the reference template from the kit's `templates/` directory
|
|
2. **Understand** its structure and purpose
|
|
3. **Adapt** it for the target project — rewrite names, paths, tech stack references, personality notes, tool lists
|
|
4. **Write** the adapted version to the target project
|
|
|
|
### Files to adapt (by profile):
|
|
|
|
**All profiles (minimal+):**
|
|
- `CLAUDE.md` — Project instructions. Read `templates/CLAUDE.md.template` (if it exists) or compose from scratch using the detected tech stack, chosen profile, and project identity. Include: project structure, agent instructions, commit conventions, file conventions, dev ops section.
|
|
- `.claude/settings.json` — Agent settings. Include model preferences and any allowed tools.
|
|
- Agent files in `.claude/agents/` — One `.md` file per agent. Read the archetype templates, adapt personality and tools for this project. See `references/personality-guide.md` for how to write good personality sections.
|
|
|
|
**Standard+ profiles:**
|
|
- `TEAM.md` — Team roster with agent names, roles, and descriptions.
|
|
- `decisions/README.md` — Decision domain index.
|
|
- Decision domain files — Create domain files based on the project type. A web app might have `decisions/architecture.md`, `decisions/api.md`, `decisions/frontend.md`. A game might have `decisions/engine.md`, `decisions/gameplay.md`.
|
|
- Skill files in `.claude/skills/` — Read each skill template, adapt for the project's git host, tech stack, and conventions. See `references/git-host-patterns.md` for host-specific patterns.
|
|
|
|
**Full profile:**
|
|
- `docs/briefings/` — One briefing per agent with project context.
|
|
- `docs/sprints/` — Sprint directory scaffolding.
|
|
- `docs/workshops/` — Workshop directory scaffolding.
|
|
- `DEVOPS.md` or `docs/DEVOPS.md` — Build, test, lint, CI procedures.
|
|
- Additional skill files for the full skill set.
|
|
|
|
### Adaptation guidelines:
|
|
|
|
- **Names**: Replace all project-specific names. "The Settled Reach" becomes the user's project name. If the user chose a naming theme, rename agents to match (e.g., "architect" → "athena" for Greek mythology, "qa-engineer" → "hoshe" for Commonwealth). Weave the thematic connection into each agent's personality intro for flavor.
|
|
- **Paths**: Replace all hardcoded paths with paths appropriate for the target project's structure.
|
|
- **Tech stack**: Replace technology references. Godot becomes React (or whatever was detected). Rust becomes Python. Adjust tool recommendations accordingly.
|
|
- **Personality**: Keep the personality structure but adapt the voice. An architect for a REST API has different concerns than an architect for a game engine.
|
|
- **Scopes**: Replace commit scopes with ones appropriate for the target project. A web app might use: api, frontend, auth, db, deploy, docs.
|
|
- **Tools**: Adjust tool lists per agent based on what makes sense for the tech stack.
|
|
|
|
## Step 5: Verify
|
|
|
|
After deploying all files:
|
|
|
|
1. **File check**: Use Glob to verify all expected files were created. List any missing files.
|
|
2. **DB check**: Run a simple query against the SQLite database to confirm it's working.
|
|
3. **CLI check**: Run `db/connectors/ticket --help` and `db/connectors/sprint --help` (standard+) to verify CLIs are functional.
|
|
4. **Decisions check**: Verify decision files have correct structure with domain index entries.
|
|
5. **Agent check**: Verify all agent files have valid YAML frontmatter.
|
|
|
|
6. **Kit tracking**: Write `.claude/kit-source.json` so `/kit-update` can find the source repo later:
|
|
```json
|
|
{
|
|
"source_path": "<path to whatsinagame clone>",
|
|
"installed_version": "<today's date>",
|
|
"installed_profile": "<minimal|standard|full>",
|
|
"last_checked": "<today's date>"
|
|
}
|
|
```
|
|
|
|
Print a getting-started summary:
|
|
|
|
```
|
|
## Setup Complete
|
|
|
|
**Project**: {project_name}
|
|
**Profile**: {profile}
|
|
**Agents**: {count} ({list of names})
|
|
**Skills**: {count} ({list of names})
|
|
**Database**: {path} (initialized)
|
|
|
|
### Next steps:
|
|
1. Review CLAUDE.md and customize any sections
|
|
2. Review agent personalities in .claude/agents/
|
|
3. Start a new Claude Code session to pick up the new configuration
|
|
4. Try: /git-commit, /ticket list, /pr-review
|
|
5. Run /kit-update periodically to check for new skills and patterns
|
|
```
|
|
|
|
## Reference Files
|
|
|
|
The following reference files in `skill/references/` provide detailed guidance:
|
|
|
|
- **`profile-manifests.md`** — Exact file lists for each profile tier.
|
|
- **`archetype-gallery.md`** — All agent archetypes with roles, personality defaults, and adaptation examples.
|
|
- **`personality-guide.md`** — How to write effective agent personalities with the precise/creative/organized/holistic/empathic spectrum.
|
|
- **`git-host-patterns.md`** — CLI command patterns for GitHub, Gitea, and GitLab.
|
|
- **`customization-examples.md`** — How The Settled Reach customized these patterns, as inspiration.
|
|
|
|
Read these files when you need detailed guidance on any of the above steps.
|