# Kiro Migration Master

## Description
Orchestrates a verified, capability-parity laptop-to-laptop migration of an AWS Windows user's Kiro + Quick environment. Detects prerequisites, captures state with a per-artifact hash manifest + a pre-registered recall probe set, transports, applies adaptively (never clobbering newer-and-working files), validates against the manifest + recall probes (NOT counts), applies the WSL memory-graph durability fix (recovery-runbook first), and sequences FIDO2/Midway auth last. The Kiro half of a dual-skill pair — hands the Quick-specific domain (scheduled agents, ACP config, permissions) to the `quick-migration-companion` skill. Independently usable without the companion.

## Trigger Phrases
- "migrate my laptop"
- "set up Kiro on my new laptop"
- "migrate Kiro to new machine"
- "run the laptop migration capability"
- "restore my environment after a laptop upgrade"

## Depends On
- execute_pwsh (system-wide ops + reaching ~/.kiro)
- memory-graph MCP (Kiro operational knowledge store)
- a browser/Playwright MCP (only for Midway-gated tool validation, optional)

## Context
Born from a real four-agent migration where "complete" was declared on file PRESENCE and counts while learned nuance silently did not transfer. North star: prove the new machine can DO everything the old one could, verified by a hashed manifest + recall probes + behavior — not by artifact presence. Full background, the by-model knowledge base, and distribution live in `SEAMLESS-LAPTOP-MIGRATION-CAPABILITY.md`.

### Anti-Patterns This Skill Prevents
1. Verifying by file/entity counts instead of capability parity (manifest diff + recall + behavior).
2. Trusting "cloud-synced" on faith (skills can sync as stubs; memory needs recall-testing).
3. node_modules-excluding exports silently dropping `.kiro/steering`, `.kiro/settings`, hooks, WSL artifacts.
4. Over-broad secret filters dropping real source (e.g. UI `tokens.ts`).
5. Running `mwinit --fido2` preemptively instead of trying the cached session first.
6. Assuming hardware behavior (FIDO2/USB) is identical across make/model — verify per model.
7. Improvising validation after the fact — probes must be pre-registered while the source is alive.
8. Repointing/overwriting before a recovery runbook exists.

### Key Facts
- `.kiro` global config lives at `C:\Users\{user}\.kiro\` (steering, settings/mcp.json, hooks). File tools may be workspace-sandboxed — use `execute_pwsh` to reach it.
- Memory-graph: `MEMORY_FILE_PATH` does NOT propagate through `wsl.exe -> bash -ic`; inline `export ... &&` ahead of `node`, store OUTSIDE node_modules.
- WSL MCPs launch via `wsl.exe -d AmazonWSL -- bash -ic "..."` with env vars inlined.
- The source-state manifest (per-artifact SHA-256 + size + mtime) and the recall probe set are ground truth — and only exist if captured BEFORE the source is decommissioned.
- Fill the by-model TO row from a live `Win32_*` probe, never by inference.

## Design Rules (apply across all steps)
- **Independence:** usable without the Quick companion (and vice versa). Degrade gracefully at Step 0.
- **Idempotency:** every phase is safe to re-run; migrations get interrupted. Never clobber newer-and-working.
- **Recovery-before-repoint:** before any repoint or destructive step, snapshot + write a self-contained recovery runbook FIRST.

## Workflow Steps

### Step 0: Prerequisite Gate — graceful degradation (AGENTIC)
Detect Kiro and/or Quick, then branch: **has-neither** -> guide install of whichever the user wants; **has-one** -> deliver that side's full value, offer the other; **has-both** -> full dual flow (hand the Quick side to `quick-migration-companion`). Confirm before proceeding.

### Step 1: Capture + emit the manifest & probe set (AGENTIC, old machine — HARD GATE)
While the source is still alive (no ground truth after decommission):
- Hardware portrait (`Win32_ComputerSystem`/`Win32_Processor`/`Win32_OperatingSystem`).
- The authoritative **source-state manifest**: per-artifact SHA-256 + size + mtime for project trees, `.kiro/` (steering/settings/hooks), WSL dotfiles + the memory-graph store.
- A **pre-registered recall probe set**: `query -> expected-content-at-high-relevance` pairs drawn from real knowledge (e.g. "memory-graph persistence fix" -> MEMORY_FILE_PATH-doesn't-propagate root cause).
- Skip log AND copy-failure log so nothing drops silently.

### Step 2: Transport (DETERMINISTIC)
Bundle to OneDrive `Documents/Kiro-Migration/` (or USB), self-contained: scripts + runbook + store snapshot + manifest + probe set. Respect the ~20 MB Quick Agent-Space upload cap (split or Slack fallback; 50 MB Slack/WSL download cap).

### Step 3: Adaptive Apply (AGENTIC, new machine)
Install into real homes. Before overwriting any destination file, run a functional check (JSON parses / `.ps1` AST-parses / `.py` compiles / `bash -n`). NEVER clobber a file that is newer AND passes its check; flag newer-but-broken for review. Re-runnable.

### Step 4: Validate — manifest diff + recall probes, NOT counts (AGENTIC)
- Files: **diff live state against the source-state manifest**. Any artifact missing or smaller-than-manifest = a drop to fix (catches the skills 20-51% content loss deterministically, across skills + steering + configs at once).
- Memory graph: run the **pre-registered recall probes** (the exact queries from Step 1); score pass/fail at high relevance. Do NOT certify on entity/relation count — counts are what failed on 2026-05-30.
- Fail criterion: ANY missing-vs-manifest, stub, or failed probe = NOT complete.

### Step 5: Memory-Graph Durability Fix — recovery runbook FIRST (DETERMINISTIC)
Snapshot the store + write a self-contained recovery runbook BEFORE touching anything. Then copy the store to a durable path OUTSIDE node_modules, edit mcp.json memory-graph args to inline `export MEMORY_FILE_PATH=<durable path> &&` before `node`, reconnect, and verify by mutation (durable store mtime moves; old node_modules default freezes).

### Step 6: Hand to Quick Companion (HANDOFF)
Trigger `quick-migration-companion` for scheduled-agent recreation (SFDC-write agents in PROMPT mode), tool-permission matching, ACP config (absolute binary paths), Quick Suite Spaces, and `monthly-memory-export`. Coordinate via the shared `Kiro/LaptopMigration/` folder. Skipped cleanly if Quick isn't in scope (Step 0).

### Step 7: Auth / FIDO2 — LAST (AGENTIC)
Cached-session-first: reconnect Midway MCPs and probe with a REAL call (e.g. slack list_my_channels, an aws-sentral query) — trust green checkmarks, not `mwinit -s`. Only on a real auth failure: `mwinit --fido2` on Windows -> copy cookie to WSL -> reconnect. Then the optional Quick<->Kiro monthly memory-sync loop is live (fileCreated ingest hook on `quick-memory-export-*.md`).

## Resources
- Capability file (authoritative background + by-model KB + distribution): `SEAMLESS-LAPTOP-MIGRATION-CAPABILITY.md`
- Companion skill: `quick-migration-companion` (Quick domain)
- Shared coordination folder: `C:\Users\{user}\Kiro\LaptopMigration\`
- Reference artifacts from this migration: `SOURCE-STATE.json` (manifest exemplar) + the memory-graph recovery runbook, both in OneDrive `Documents/Kiro-Migration/`.

## Notes
- Kiro half of a dual-skill pair (John's Phase-2 decision); Quick owns scheduled agents, permissions, ACP, Spaces, sync-agent setup.
- The two skills communicate via the shared filesystem and the coordination email thread, and each works standalone.
- Distribution: Skills Files Library SharePoint (primary) + scripts/runbook kit (fallback) + wiki index (discovery).
- Always verify by CAPABILITY PARITY (manifest diff + recall + behavior), never by artifact presence or counts.