菜单
Migrate legacy monoliths to modern architecture using the Strangler Fig pattern. Outputs migration strategy, routing layer design, feature extraction sequence, and rollback procedures.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/kalilurrahman/kr-claudiator-skills --skill strangler-fig-pattern命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | strangler-fig-pattern |
| description | Migrate legacy monoliths to modern architecture using the Strangler Fig pattern. Outputs migration strategy, routing layer design, feature extraction sequence, and rollback procedures. |
| argument-hint | ["legacy system type","target architecture","team size","migration timeline","risk tolerance"] |
| allowed-tools | Read, Write |
The Strangler Fig pattern migrates a legacy system incrementally by routing new functionality to a new system while the legacy system handles the rest. Over time, the new system absorbs more traffic until the legacy system can be retired. No big-bang rewrite. No parallel operation of two full systems.
# API Gateway routing layer — sits in front of both systems
from fastapi import FastAPI, Request
import httpx
import logging
app = FastAPI()
logger = logging.getLogger()
# Feature flags controlling which system handles each route
ROUTING_CONFIG = {
"/api/v1/orders": {"target": "legacy", "canary_pct": 0},
"/api/v1/products": {"target": "new", "canary_pct": 100}, # Fully migrated
"/api/v1/users": {"target": "canary", "canary_pct": 10}, # 10% to new
"/api/v1/payments": {"target": "legacy", "canary_pct": 0},
"/api/v1/notifications": {"target": "new", "canary_pct": 100}, # Migrated
}
LEGACY_BASE = "http://legacy-monolith:8080"
NEW_BASE = "http://new-services:8080"
@app.api_route("/{path:path}", methods=["GET","POST","PUT","PATCH","DELETE"])
async def route_request(request: Request, path: str):
route_key = f"/{path.split('/')[0]}" if '/' in path else f"/{path}"
config = ROUTING_CONFIG.get(route_key, {"target": "legacy", "canary_pct": 0})
target = _determine_target(config, request)
base = NEW_BASE if target == "new" else LEGACY_BASE
logger.info(f"Routing {request.method} {path} → {target}")
async with httpx.AsyncClient() as client:
resp = await client.request(
method=request.method,
url=f"{base}/{path}",
headers=dict(request.headers),
content=await request.body(),
params=dict(request.query_params),
timeout=30.0,
)
from fastapi.responses import Response
return Response(
content=resp.content,
status_code=resp.status_code,
headers=dict(resp.headers),
media_type=resp.headers.get("content-type"),
)
def _determine_target(config: dict, request: Request) -> str:
if config["target"] == "new": return "new"
if config["target"] == "legacy": return "legacy"
# Canary: route by user_id hash for sticky routing
import hashlib
user_id = request.headers.get("x-user-id", "")
hash_val = int(hashlib.md5(user_id.encode()).hexdigest(), 16) % 100
return "new" if hash_val < config["canary_pct"] else "legacy"
## Feature Extraction: User Profiles
### Pre-extraction
- [ ] Document all legacy endpoints for this feature (GET/PUT /users/*)
- [ ] Identify all DB tables accessed by these endpoints
- [ ] Map all downstream consumers (who calls these endpoints?)
- [ ] Document current behaviour including edge cases and error responses
- [ ] Write characterisation tests against legacy (record expected outputs)
### Build new service
- [ ] New service passes all characterisation tests
- [ ] API contracts match legacy (same request/response shapes)
- [ ] Performance baseline: p99 latency comparable to legacy
- [ ] Feature flags implemented for traffic splitting
### Migration
- [ ] 1% canary — monitor error rate, latency, correctness
- [ ] 10% — run for 24h, compare metrics
- [ ] 50% — run for 48h, full monitoring
- [ ] 100% — monitor legacy for 24h before disabling it
### Post-migration
- [ ] Legacy code path disabled (not deleted yet)
- [ ] DB tables still populated for 30 days (rollback window)
- [ ] Legacy tables retired after 30 days
- [ ] Legacy code deleted
-- Phase 1: Dual writes (new service writes to both DBs)
-- Legacy DB continues to be source of truth
-- Phase 2: New DB becomes source of truth, legacy read from new
-- (via replication or sync job)
-- Phase 3: Legacy DB retired
-- Sync job during migration
INSERT INTO new_db.users (id, email, name, created_at)
SELECT id, email, name, created_at
FROM legacy_db.users
WHERE updated_at > :last_sync_time
ON CONFLICT (id) DO UPDATE SET
email = EXCLUDED.email,
name = EXCLUDED.name,
updated_at = EXCLUDED.updated_at;
| Anti-Pattern | Problem | Fix |
|---|---|---|
| Starting with the hardest feature | Failure early kills confidence and timeline | Start with well-defined, low-risk features |
| No routing layer | Can't incrementally shift traffic | Build the proxy/facade first |
| Big-bang data migration | High risk, long downtime | Dual-write then cut over |
| Skipping characterisation tests | Don't know if new system matches legacy behaviour | Record legacy outputs; test new system against them |
| Deleting legacy too early | No rollback path if new system has bugs | Keep legacy running for 30 days post-migration |
| Migrating shared database tables | Creates tight coupling between old and new | Separate data ownership before migrating logic |
The sections below extend this skill into a complete operating playbook so it can run end-to-end inside Claude Code, CoWork, or any agentic tool without further prompting. Pull only the sections you need for a given engagement.
Before producing any output, the skill confirms:
If any of these are missing, the skill asks targeted clarifying questions before generating output. It never invents constraints the user did not state.
The canonical workflow for Strangler Fig Pattern runs in five stages. Each stage has an explicit exit criterion so the skill knows when to advance.
Stage 1 — Frame. Restate the problem in one paragraph. Name the decision, the deadline, the stakeholders, and the success metric. Surface assumptions explicitly so they can be challenged.
Stage 2 — Diagnose. Inventory the current state with concrete evidence: metrics, quotes, screenshots, configs, tickets. Separate facts from interpretations. Identify the two or three root causes that explain most of the gap, not the long tail of symptoms.
Stage 3 — Design. Generate at least two viable options. For each option, capture: what changes, who owns it, what it costs, what it unblocks, what it risks, and how it could fail. Recommend one with a written rationale.
Stage 4 — Execute. Convert the chosen option into a sequenced plan: milestones, owners, dependencies, gating checks, communication cadence, and rollback triggers. Anything that cannot be assigned an owner and a date is not yet a plan.
Stage 5 — Validate. Define how success will be measured, when the measurement happens, and what action follows each possible result. Schedule the retrospective before the work starts, not after.
Depending on the request, the skill returns one or more of:
Every artifact uses clear headings, short paragraphs, and tables where comparison helps. No filler. No restating the prompt. No hedging language when a recommendation is warranted.
The skill applies the following heuristics when choices are not obvious:
| Anti-pattern | Why it fails | What the skill does instead |
|---|---|---|
| Generic best-practice list with no context | Reader cannot act on it | Tailors recommendations to the stated constraints |
| Recommendation without trade-offs | Hides the cost of being wrong | Names the price paid for the recommendation |
| Plan with no owners or dates | Cannot be executed or tracked | Assigns a named owner and a date to every action |
| Metrics theatre | Measures activity, not outcome | Ties every metric back to the user or business outcome |
| Boil-the-ocean scope | Nothing ships | Cuts scope to the smallest valuable slice |
| Buried recommendation | Reader misses the point | Leads with the recommendation in the first paragraph |
The skill self-checks each output against these gates before returning it:
If any gate fails, the skill rewrites the section before returning it.
Context: Migrate legacy monoliths to modern architecture using the Strangler Fig pattern. Outputs migration strategy, routing layer design, feature extraction sequence,
Frame: the team needs a defensible recommendation within five working days; the audience is a cross-functional steering group; the cost of delay is higher than the cost of being slightly wrong.
Diagnose: the dominant constraint is decision latency, not analytical depth. Existing data is sufficient for a directional call.
Design: two viable options surfaced. Option A optimises for speed and reversibility. Option B optimises for completeness but slips the deadline by two weeks.
Execute: Option A recommended. Plan sequenced into a two-week sprint with named owners, a mid-point checkpoint, and a clear rollback trigger.
Validate: success measured against a single leading indicator at day 30 and a single lagging indicator at day 90. Retrospective scheduled for day 35.
A one-shot artifact rarely changes outcomes. The skill recommends a lightweight cadence to keep the work alive: