feat(migrate-eppo): add Eppo migration kit and extract shared core

[fabriziodemaria]

Summary

Adds a /migrate-eppo slash command and skill that mirrors the existing PostHog migration, then refactors both skills to share their Confidence-side conventions.

Two commits, intentionally separable:

1. feat(migrate-eppo) — adds the new command, skill, and updates README/CLAUDE.md.
2. refactor(migrations) — extracts the ~60% of content that was duplicated across both skills into skills/_shared/migration-core.md.

What's new in migrate-eppo

• Same two-phase flow as migrate-posthog (plan flags → plan code → execute, one PR per flag).
• Uses Eppo's REST admin API via curl since Eppo doesn't publish a Claude MCP server. The skill prompts for EPPO_API_KEY, stores it only in the session env, and never echoes it to the plan file.
• Asks the user to pick a source Eppo environment before scanning, since Eppo's flag state is per-environment.
• Eppo-specific operator mapping (ONE_OF, NOT_ONE_OF, MATCHES, GTE, etc.). MATCHES is constrained to ^prefix.* / .*suffix$; arbitrary regex and SemVer comparisons are blocked with explicit guidance for the user.
• Allocation waterfalls preserved as ordered Confidence targeting rules; the execute verification step explicitly resolves a context that misses the first allocation but matches a later one to confirm order.
• Flags disabled in the source environment are migrated at 0% rollout so they can't accidentally activate during migration.

Why the refactor

After adding the Eppo skill, ~60% of content was duplicated across the two skills — including the Confidence targeting payload format that #15 had to fix. Drift across copies makes Confidence-side bug fixes a multi-place chore, and gets worse with each new source platform.

The refactor extracts shared content into skills/_shared/migration-core.md. Each platform skill now starts with a "read core first" instruction and only contains its platform-specific bits: prerequisites, scan logic, randomization mapping, operator table, plan template fields, code-scan patterns, transform rules.

Net effect:

• -28% total lines (1564 deleted, 1134 added across the three files).
• Each platform skill is now ~500 lines instead of ~1100.
• Adding a third source platform (LaunchDarkly, Statsig, GrowthBook, ConfigCat, ...) is now mechanical: copy a platform skill template, fill in the four platform-specific sections.

Pure refactor; no user-facing behavior change. Slash commands, plan-file paths, MCP tool names, and the execute flow are unchanged.

Test plan

End-to-end agent-driven skills don't have an automated test suite. Manual validation tiers:

• Tier 1 — hand-craft a tiny plan file with 2-3 fake flags and run /migrate-eppo execute <plan-file> against a throwaway Confidence client. Covers the riskiest path (createFlag → addTargetingRule → resolveFlag, including waterfall order verification) without needing any Eppo access.
• Tier 2 (optional follow-up) — stand up a tiny local fake Eppo server that returns fixture JSON, point `EPPO_API_KEY` and the base URL at it, run `/migrate-eppo plan flags`. Covers the scan + plan generation path including the operator mapping table.
• Tier 3 (before tagging a release) — manual smoke test against a real Eppo account.
• Regression — run `/migrate-posthog plan flags` end-to-end to confirm the refactor didn't break the existing flow.

Draft because

1. Wanted feedback on the shared-core extraction approach before merging — happy to revert just the refactor commit and ship Eppo support standalone if you'd prefer.
2. Tier 1 manual testing not yet done.
3. Open question: do you want a fixture server (Tier 2) added in this PR or as a follow-up?

Made with Cursor