config-sync

What this skill does

# /configure:config-sync

Extract, compare, and propagate tooling config improvements across FVH repos.

## When to Use This Skill

| Use this skill when... | Use another approach when... |
|------------------------|------------------------------|
| Comparing a workflow/config across all FVH repos | Configuring a single repo's workflow from scratch — use `/configure:workflows` |
| Propagating an improvement from one repo to many | Debugging a failing CI run — use `github-actions-inspection` |
| Identifying which repos have outdated configs | Creating a reusable workflow — use `/configure:reusable-workflows` |
| Extracting novel patterns from a repo to share | Checking a single repo's compliance — use `/configure:status` |

## Context

- Workspace root: `/Users/lgates/repos/ForumViriumHelsinki`
- Repos: !`fd -t d -d 1 . /Users/lgates/repos/ForumViriumHelsinki --exclude .git --exclude node_modules`
- Current directory: !`pwd`

## Parameters

Parse mode and options from command arguments:

### Modes

1. **`extract [repo-name]`** — Identify improvements in a source repo
2. **`diff <file-pattern>`** — Compare a specific config across all repos
3. **`apply <file-pattern> [--from repo] [--to repo1,repo2,...|--all]`** — Propagate config to targets

### Options

- `--from <repo>` — Source repo for apply mode (default: best version detected)
- `--to <repo1,repo2,...>` — Target repos (comma-separated)
- `--all` — Target all repos that have the file
- `--dry-run` — Show what would change without creating branches/PRs (default behavior)
- `--confirm` — Actually create branches and PRs

## Config Categories

Files tracked for cross-repo sync, organized by sync strategy:

### Tier 1: Wholesale (100% identical across repos)

Copy verbatim — no repo-specific variations expected.

| File Pattern | Description |
|-------------|-------------|
| `.github/workflows/claude.yml` | Claude Code workflow |
| `renovate.json` | Renovate dependency updates |

### Tier 2: Parameterized (shared core with known variation points)

Shared structure with specific fields that vary per repo.

| File Pattern | Variation Points |
|-------------|-----------------|
| `.github/workflows/auto-merge-image-updater.yml` | Branch prefix pattern |
| `.github/workflows/release-please.yml` | Publish job, extra steps |
| `.github/workflows/renovate.yml` | Standalone (infrastructure) vs reusable caller (all others) |

### Tier 3: Structural (standard skeleton, project-specific bodies)

Standard recipe/section names must conform; bodies are project-specific.

| File Pattern | Conformance Target |
|-------------|-------------------|
| `justfile` | Standard recipe names from justfile-template conventions |

### Tier 4: Pattern-based (categorized by tech stack)

Group by detected stack, extract general best practices only.

| File Pattern | Stack Detection |
|-------------|----------------|
| `Dockerfile*` | `package.json` → Node, `pyproject.toml` → Python, `go.mod` → Go, `Cargo.toml` → Rust |
| `.github/workflows/container-build.yml` | Same as Dockerfile |

### Tier 5: Reference (compare and report, selective apply)

| File Pattern | Notes |
|-------------|-------|
| `release-please-config.json` | Varies by project type |
| `.release-please-manifest.json` | Version tracking |
| `skaffold.yaml` | Dev environment config |

## Execution

### Extract Mode

**Goal**: Scan a repo and identify improvements that could benefit other repos.

#### Step 1: Identify the source repo

If repo name provided, use `/Users/lgates/repos/ForumViriumHelsinki/<repo-name>`.
Otherwise use the current working directory (must be inside an FVH repo).

#### Step 2: Scan tooling files

Scan for all tracked config categories:

```bash
fd -t f -d 3 '(claude|renovate|auto-merge|release-please|container-build|Dockerfile|justfile|skaffold)' <repo-path>
```

Also check:
- `.github/workflows/*.yml`
- `justfile`
- `Dockerfile*`
- `renovate.json`
- `release-please-config.json`
- `.release-please-manifest.json`
- `skaffold.yaml`

#### Step 3: Compare against workspace patterns

For each file found:

1. **Wholesale tier**: Hash the file content and compare against the most common version across all repos. Report if this repo has a newer/different version.
2. **Parameterized tier**: Extract the shared core (strip known variation points) and compare structure.
3. **Structural tier (justfile)**: Check for standard recipes (`default`, `help`, `dev`, `build`, `clean`, `lint`, `format`, `format-check`, `test`, `pre-commit`, `ci`). Report missing standard recipes and non-standard names (e.g., `check` instead of `lint`).
4. **Pattern-based tier**: Detect tech stack, then check for best practices:
   - Pinned base images (not `latest`)
   - `.dockerignore` present
   - Multi-stage builds
   - Non-root user
   - SHA-pinned GitHub Actions
   - SBOM/provenance attestation
5. **Reference tier**: Note divergences from the most common configuration.

#### Step 4: Generate extract report

```
Config Extract Report: <repo-name>
====================================

Wholesale Configs:
  claude.yml       ✅ Matches canonical (sha: abc123)
  renovate.json    ⚠️  Differs from canonical — newer features detected

Parameterized Configs:
  auto-merge-image-updater.yml  ✅ Core matches, variation: branch-prefix=argocd
  release-please.yml            ⚠️  Has publish job (novel improvement)

Structural (Justfile):
  Standard recipes: 8/11 present
  Missing: format-check, pre-commit, ci
  Non-standard names: none

Pattern-based (Dockerfile):
  Stack: Python
  ✅ Pinned base image (python:3.12-slim)
  ✅ Multi-stage build
  ⚠️  Missing .dockerignore
  ✅ Non-root user

Potential Improvements to Propagate:
  1. renovate.json — has newer schedule config
  2. release-please.yml — publish job pattern
```

### Diff Mode

**Goal**: Compare a specific file across all FVH repos.

#### Step 1: Resolve file pattern

Interpret the file pattern argument:
- Full path: `.github/workflows/claude.yml`
- Short name: `claude.yml` → search in `.github/workflows/`
- Glob: `*.yml` → match all workflows

#### Step 2: Find the file across repos

```bash
fd -t f '<pattern>' /Users/lgates/repos/ForumViriumHelsinki --max-depth 4
```

#### Step 3: Group by content hash

For each found file, compute a content hash:

```bash
shasum -a 256 <file>
```

Group files by identical hash. Sort groups by size (largest first = most common version).

#### Step 4: Identify the "best" version

Heuristics for selecting the canonical version:
1. Most common hash (majority rules)
2. If tie: most recently modified
3. If tie: from `infrastructure` repo (reference repo)

#### Step 5: Generate diff report

```
Config Diff: .github/workflows/claude.yml
==========================================

Group 1 (canonical) — 18 repos [sha: abc123]:
  citylogger, CycleRoutePlanner, FVHIoT-python, ...

Group 2 — 2 repos [sha: def456]:
  theme-management, OLMap
  Differences from canonical:
    - Line 12: uses different action version
    - Line 25: extra step for Node setup

Not present in (5 repos):
  infrastructure, helm-webapp, terraform-modules, ...

Recommendation: Update Group 2 repos to match canonical.
```

For small files (< 100 lines), show an inline unified diff between the canonical and each outlier group.

### Apply Mode

**Goal**: Propagate a config file from source to target repos.

#### Step 1: Determine source

- If `--from` specified, use that repo's version
- Otherwise, run diff mode internally to find the canonical version

#### Step 2: Determine targets

- If `--to` specified, use those repos
- If `--all`, use all repos that currently have the file (excluding source)
- Otherwise, ask the user which repos to target

#### Step 3: Determine sync strategy by tier

**Wholesale**: Copy file verbatim to targets.

**Parameterized**: Copy file but preserve known variation points:
- `auto-merge-image-updater.yml`: preserve `BRANCH_PREFIX` value
- `release-please.yml`: preserve extra publish/deploy jobs

**Structural (justfi