settled-reach/whatsinagame/skill/SKILL.md

name, description, user-invocable, allowed-tools

name	description	user-invocable	allowed-tools
kit-install	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.	true	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/tooling/db/ to the project's db/ directory.
2. Config: Write tooling/db/config.json with the user's service URLs (or sensible defaults).
3. Initialize DB: Run python3 tooling/db/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 tooling/db/ticket --help and tooling/db/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:

   {
     "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.