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>
5.9 KiB
name, description, user-invocable, allowed-tools
| name | description | user-invocable | allowed-tools |
|---|---|---|---|
| kit-update | Check the whatsinagame source repo for updates to skills, agents, patterns, and infrastructure. Use when the user says "check for kit updates", "update kit", "sync kit", "kit update", or invokes /kit-update. Compares installed files against the source repo, shows what changed, and lets the user cherry-pick updates without overwriting local customizations. | true | Bash, Read, Grep, Glob, Write, Edit, AskUserQuestion |
Kit Update — Sync with Source
Check the whatsinagame starter kit repo for updates and selectively apply them to the current project. Respects local customizations — never overwrites without asking.
Prerequisites
The kit source repo must be cloned locally. The path is stored in
.claude/kit-source.json:
{
"source_path": "~/whatsinagame",
"installed_version": "2026-02-18",
"last_checked": "2026-02-18"
}
If this file doesn't exist, ask the user for the path to their whatsinagame clone and create it.
Workflow
1. Locate and update the source repo
# Read the source path
cat .claude/kit-source.json
# Pull latest from remote
cd <source_path> && git pull --ff-only
If the pull fails (no remote, conflicts), warn the user but continue with whatever version is local.
2. Inventory what's installed
Scan the project for kit-managed files:
Static files (deployed as-is, safe to update):
db/schema.sqldb/connectors/sqlite_connector.pydb/connectors/ticketdb/connectors/sprintdb/connectors/decisions_sync.pydb/connectors/qdrant_connector.py- All shell wrappers in
db/connectors/
Adapted files (customized during init, update with care):
.claude/skills/*/SKILL.md— skill definitions.claude/agents/*.md— agent personalitiesCLAUDE.md,TEAM.md,Makefile,DEVOPS.mddecisions/README.md.claude/settings.json
3. Compare versions
For each category, compare the installed version against the source:
Static files: Direct diff against static/ in the source repo.
diff -u db/connectors/ticket <source_path>/static/db/connectors/ticket
Skills: Compare the installed skill's SKILL.md against the source template. Use semantic comparison — check for:
- New workflow steps added to the source
- New reference files in the source that don't exist locally
- Changed YAML frontmatter (new triggers, tool changes)
Agents: Check if the source has new archetypes that don't exist locally. Don't diff existing agents — those were intentionally customized.
New files: Check if the source repo has files that don't exist in the project at all (new skills, new agent archetypes, new reference docs).
4. Categorize changes
Group findings into three categories:
Safe to auto-update (static infrastructure):
- DB connectors with bug fixes or new features
- Shell wrappers
- Schema migrations (additive only — new tables/indexes)
Review recommended (adapted templates):
- Skills with new workflow steps or improved patterns
- Reference docs with expanded guidance
New additions (not yet installed):
- New skill templates added to the source kit
- New agent archetypes
- New reference documents
5. Present to user
## Kit Update — {date}
Source: {source_path} (last commit: {hash} {date})
Installed: {installed_version}
### Safe Updates (auto-apply recommended)
| File | Change | Source Date |
|------|--------|-------------|
| db/connectors/ticket | Bug fix: handle empty sprint list | 2026-03-01 |
| db/connectors/sprint | New command: sprint archive | 2026-03-01 |
### Skill Improvements (review diff)
| Skill | Change |
|-------|--------|
| pr-review | New: stakeholder persona reviewers for UX changes |
| git-commit | Improved: better scope detection from file paths |
### New Additions (not yet installed)
| Type | Name | Description |
|------|------|-------------|
| skill | incident-response | Post-incident review and timeline generator |
| agent | data-engineer | Data pipeline specialist archetype |
| reference | accessibility-guide.md | Accessibility review checklist |
6. Apply updates
Use AskUserQuestion to let the user choose:
- Apply all safe updates — overwrites static files with source versions
- Review skill improvements — show diffs one by one, let user accept/skip each
- Install new additions — for each new item, adapt it for the project (same as init-team Step 4)
- Skip — just report, don't change anything
For each applied update:
- Read the source version
- For static files: overwrite directly
- For skills: show the diff, apply if approved, preserve local customizations
- For new additions: run the adaptation logic (read template, rewrite for project context)
7. Record the update
Update .claude/kit-source.json with the new check date:
{
"source_path": "~/whatsinagame",
"installed_version": "2026-03-15",
"last_checked": "2026-03-15"
}
Schema Migrations
When db/schema.sql has changed in the source, the update must be additive:
- New tables: run the CREATE TABLE IF NOT EXISTS statements
- New indexes: run the CREATE INDEX IF NOT EXISTS statements
- Column additions: NOT supported automatically — flag for manual review
Compare schemas:
diff <(sqlite3 "" ".read <source>/static/db/schema.sql" ".schema") \
<(db/connectors/sqlite-query "SELECT sql FROM sqlite_master ORDER BY name")
If new tables or indexes are detected, offer to run db/connectors/sqlite-init
to apply them (it uses IF NOT EXISTS, so it's safe to re-run).
Tips
- Run periodically: Check for updates at the start of each sprint or monthly
- Changelog: The source repo's CHANGELOG.md describes what changed and why
- Breaking changes: If the source repo has a BREAKING section in its changelog, flag it prominently
- Fork-friendly: If the user has forked the kit, they can set
source_pathto their fork