settled-reach/whatsinagame/templates/.claude/skills/kit-update/SKILL.md

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.sql
• tooling/db/sqlite_connector.py
• tooling/db/ticket
• tooling/db/sprint
• tooling/db/decisions_sync.py
• tooling/db/qdrant_connector.py
• All shell wrappers in tooling/db/

Adapted files (customized during init, update with care):

• .claude/skills/*/SKILL.md — skill definitions
• .claude/agents/*.md — agent personalities
• CLAUDE.md, TEAM.md, Makefile, DEVOPS.md
• decisions/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 tooling/db/ticket <source_path>/static/tooling/db/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 |
|------|--------|-------------|
| tooling/db/ticket | Bug fix: handle empty sprint list | 2026-03-01 |
| tooling/db/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:

1. Read the source version
2. For static files: overwrite directly
3. For skills: show the diff, apply if approved, preserve local customizations
4. 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") \
     <(tooling/db/sqlite-query "SELECT sql FROM sqlite_master ORDER BY name")

If new tables or indexes are detected, offer to run tooling/db/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_path to their fork