[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FTB8PSEVXHW4VGAJ2AKYT":3,"skill-same:01M70FTB8PSEVXHW4VGAJ2AKYT":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M70FTB8PSEVXHW4VGAJ2AKYT","strangler-fig",null,"Use when breaking up a god class, extracting responsibilities from an oversized module, incrementally replacing legacy code, or when old and new must coexist during a refactor — symptoms include classes over 500 lines, modules with mixed concerns, or \"we can't rewrite this all at once\"","donovan-yohan\u002Fchalk-bag","donovan-yohan","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F34756395?v=4","01M70FT5BEGGVXHAPFPX5QXMFE","Donovan Yohan","01M70FT5C3E7MJD3WMA44MQSJE",1,"MIT","https:\u002F\u002Fgithub.com\u002Fdonovan-yohan\u002Fchalk-bag\u002Fblob\u002Fmaster\u002Fplugins\u002Fharness\u002Fskills\u002Fstrangler-fig\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"strangler fig","fig","refactor","at","legacy code","with","can","code","rewrite","when","Legacy","use","module","oversized","up","extracting","modules","2026-11-10 10:12:30",false,"---\nname: strangler-fig\ndescription: Use when breaking up a god class, extracting responsibilities from an oversized module, incrementally replacing legacy code, or when old and new must coexist during a refactor — symptoms include classes over 500 lines, modules with mixed concerns, or \"we can't rewrite this all at once\"\n---\n\n# Strangler Fig Refactoring\n\nDecompose an incremental refactoring into production-safe goals using the Strangler Fig pattern — build new alongside old, redirect traffic, then remove legacy. Informed by Martin Fowler's StranglerFigApplication and Shopify's incremental migration approach.\n\n## When to Use\n\n- Extracting responsibilities from a God Object or oversized module\n- Replacing a legacy component without big-bang rewrite\n- Any refactor where old and new must coexist during transition\n- Classes over 500 lines with multiple distinct responsibilities\n- \"We can't rewrite this all at once\" situations\n\n## Workflow\n\nExecute three phases interactively with the user:\n\n### Phase 1: Identify Extraction Target\n\n1. Ask what code to refactor — the oversized class, tangled module, or legacy component\n2. Read the target code and map its responsibilities (list each distinct responsibility)\n3. Classify the refactor type:\n   - **Backend service extraction** — persistent state involved, data migration likely needed\n   - **Frontend component extraction** — UI\u002Fstate extraction, typically no database migration\n   - **Pure code extraction** — logic extraction only, no persistent state changes\n   - **Mixed** — evaluate based on which responsibilities involve persistent state\n4. Ask which responsibilities to extract, or recommend based on cohesion analysis\n\n### Phase 2: Dependency & Seam Analysis\n\n1. Trace consumers — who calls, imports, or depends on the extraction target\n2. Trace dependencies — what the target depends on (other modules, DB, external services)\n3. Identify seams — natural boundaries where old and new systems can coexist\n4. Assess risk:\n   - Blast radius — how many callers\u002Fmodules are affected\n   - Data consistency risk — are there shared mutable state or transactions\n   - Rollback complexity — how easy is it to undo each step\n5. Determine if persistent state is involved (indicates data migration goals will be needed)\n\n### Phase 3: Decompose into Production-Safe Goals\n\nUse strangler fig thinking and the dependency analysis from Phase 2 to identify natural goal boundaries. Each goal must be safe to merge to production independently.\n\n**Grouping heuristic**: combine steps that cannot be independently verified or deployed into a single goal. A goal is the smallest unit of work that is safe to ship alone.\n\n**Production-safety criteria** — a goal is production-safe if it meets at least one:\n- Protected by a feature flag (default off)\n- Unconsumed scaffolding (new code exists but nothing calls it yet)\n- Additive-only change (no existing behavior is altered or removed)\n- Safe deletion (removing code with verified zero consumers)\n\nFor each goal, provide:\n- **Concrete mapping**: specific files, classes, tables, or components involved\n- **Rollback note**: how to reverse this goal if problems arise\n- **Merge criteria**: what must be true before this goal's PR is considered ready (advisory, for human reviewers)\n\n**Output format:**\n\nGoals table:\n\n| # | Goal | Description | Depends On | Production Safety |\n|---|------|-------------|------------|-------------------|\n| 1 | `kebab-goal-name` | What this goal accomplishes | — | Additive-only \u002F Feature flag \u002F etc. |\n| 2 | `kebab-goal-name` | What this goal accomplishes | Goal 1 | Unconsumed scaffolding |\n| … | … | … | … | … |\n\n**Execution Order**: Describe which goals are sequential and which can be parallelized. Goals with no shared dependency can be worked in parallel by separate engineers or teams.\n\n**Merge Criteria**: For each goal, document what reviewers should verify before merging. This is advisory guidance for human reviewers — not an automated gate.\n\n## Reference Framework\n\nThe 7 strangler fig steps are a reference framework for analysis during Phases 2-3. They help identify what work needs to happen but do not dictate goal boundaries. The agent groups these into production-safe goals based on the project's actual needs.\n\n| Step | What | Applies When |\n|------|------|-------------|\n| 1. Define new interface | Create the new module\u002Fclass\u002Fcomponent with extracted responsibilities | Always |\n| 2. Redirect consumers | Update callers\u002Fimporters to use the new interface | Always |\n| 3. Establish new data source | Create new storage (DB table, state store, context, cache) | Persistent state involved |\n| 4. Dual writes | Write to both old and new sources simultaneously for consistency | Persistent state involved |\n| 5. Backfill | Migrate existing data from old source to new | Historical data exists |\n| 6. Switch reads | Move read operations from old source to new | Persistent state involved |\n| 7. Remove legacy | Delete old code, old storage, old dependencies | Always |\n\nFor detailed examples per refactor type, read the reference file at:\n`plugins\u002Fharness\u002Fskills\u002Fstrangler-fig\u002Freferences\u002Fsteps-by-context.md`\n\nFor common merge criteria patterns and observation strategies, read:\n`plugins\u002Fharness\u002Fskills\u002Fstrangler-fig\u002Freferences\u002Fgate-patterns.md`\n\n## Output\n\nProduce a goal dependency graph and per-goal summaries as structured content. Do NOT save files — the invoking command (`\u002Fharness:refactor`) handles document creation.\n\n## Key Principles\n\n- **Reversibility is the core value** — every goal (except final deletion goals) should be reversible\n- **Transitional architecture is acceptable** — temporary code enabling coexistence is not waste, it's risk reduction\n- **Goals have explicit dependencies** — each goal declares what must be merged before it begins\n- **Merge criteria document deployment readiness** — they are advisory checkpoints, not automated gates\n- **Goal count and scope varies by refactor** — a simple extraction might be 2 goals; a complex service split might be 8\n\n## Common Mistakes\n\n| Mistake | Why It's Dangerous | Fix |\n|---------|-------------------|-----|\n| Scoping a goal that isn't production-safe to merge independently | If the PR breaks prod when merged alone, it's not a valid goal boundary | Restructure: add a feature flag, split further, or make the change additive-only |\n| Making goals too granular (15 PRs for a simple extraction) | Review fatigue, coordination overhead, unclear progress | Combine steps that can't be independently verified into a single goal |\n| Making goals too coarse (one mega-PR) | Defeats the purpose of incremental safety; hard to review and impossible to roll back cleanly | Split at seams where production safety is naturally maintained |\n| Not documenting rollback for each goal | You won't remember how to undo under incident pressure | Every goal needs a rollback note written before implementation |\n| Not identifying which goals can parallelize | Missed opportunity to reduce calendar time | Explicitly map which goals have no shared dependency and can run in parallel |\n\n## Red Flags — STOP and Reassess\n\n- \"This goal's PR would break prod if merged alone\" — the goal scope is wrong; restructure it\n- \"We need all goals merged simultaneously\" — goals aren't independent enough; find a way to sequence them safely\n- \"Skip the merge criteria, it obviously works\" — verify anyway; obvious things fail silently in production\n- \"Let's just do it all in one PR\" — defeats the purpose of incremental safety and eliminates the ability to roll back individual changes\n\n**All of these mean: revisit goal boundaries, restore production safety, then proceed.**\n","# Strangler Fig Refactoring\n\nDecompose an incremental refactoring into production-safe goals using the Strangler Fig pattern — build new alongside old, redirect traffic, then remove legacy. Informed by Martin Fowler's StranglerFigApplication and Shopify's incremental migration approach.\n\n## When to Use\n\n- Extracting responsibilities from a God Object or oversized module\n- Replacing a legacy component without big-bang rewrite\n- Any refactor where old and new must coexist during transition\n- Classes over 500 lines with multiple distinct responsibilities\n- \"We can't rewrite this all at once\" situations\n\n## Workflow\n\nExecute three phases interactively with the user:\n\n### Phase 1: Identify Extraction Target\n\n1. Ask what code to refactor — the oversized class, tangled module, or legacy component\n2. Read the target code and map its responsibilities (list each distinct responsibility)\n3. Classify the refactor type:\n   - **Backend service extraction** — persistent state involved, data migration likely needed\n   - **Frontend component extraction** — UI\u002Fstate extraction, typically no database migration\n   - **Pure code extraction** — logic extraction only, no persistent state changes\n   - **Mixed** — evaluate based on which responsibilities involve persistent state\n4. Ask which responsibilities to extract, or recommend based on cohesion analysis\n\n### Phase 2: Dependency & Seam Analysis\n\n1. Trace consumers — who calls, imports, or depends on the extraction target\n2. Trace dependencies — what the target depends on (other modules, DB, external services)\n3. Identify seams — natural boundaries where old and new systems can coexist\n4. Assess risk:\n   - Blast radius — how many callers\u002Fmodules are affected\n   - Data consistency risk — are there shared mutable state or transactions\n   - Rollback complexity — how easy is it to undo each step\n5. Determine if persistent state is involved (indicates data migration goals will be needed)\n\n### Phase 3: Decompose into Production-Safe Goals\n\nUse strangler fig thinking and the dependency analysis from Phase 2 to identify natural goal boundaries. Each goal must be safe to merge to production independently.\n\n**Grouping heuristic**: combine steps that cannot be independently verified or deployed into a single goal. A goal is the smallest unit of work that is safe to ship alone.\n\n**Production-safety criteria** — a goal is production-safe if it meets at least one:\n- Protected by a feature flag (default off)\n- Unconsumed scaffolding (new code exists but nothing calls it yet)\n- Additive-only change (no existing behavior is altered or removed)\n- Safe deletion (removing code with verified zero consumers)\n\nFor each goal, provide:\n- **Concrete mapping**: specific files, classes, tables, or components involved\n- **Rollback note**: how to reverse this goal if problems arise\n- **Merge criteria**: what must be true before this goal's PR is considered ready (advisory, for human reviewers)\n\n**Output format:**\n\nGoals table:\n\n| # | Goal | Description | Depends On | Production Safety |\n|---|------|-------------|------------|-------------------|\n| 1 | `kebab-goal-name` | What this goal accomplishes | — | Additive-only \u002F Feature flag \u002F etc. |\n| 2 | `kebab-goal-name` | What this goal accomplishes | Goal 1 | Unconsumed scaffolding |\n| … | … | … | … | … |\n\n**Execution Order**: Describe which goals are sequential and which can be parallelized. Goals with no shared dependency can be worked in parallel by separate engineers or teams.\n\n**Merge Criteria**: For each goal, document what reviewers should verify before merging. This is advisory guidance for human reviewers — not an automated gate.\n\n## Reference Framework\n\nThe 7 strangler fig steps are a reference framework for analysis during Phases 2-3. They help identify what work needs to happen but do not dictate goal boundaries. The agent groups these into production-safe goals based on the project's actual needs.\n\n| Step | What | Applies When |\n|------|------|-------------|\n| 1. Define new interface | Create the new module\u002Fclass\u002Fcomponent with extracted responsibilities | Always |\n| 2. Redirect consumers | Update callers\u002Fimporters to use the new interface | Always |\n| 3. Establish new data source | Create new storage (DB table, state store, context, cache) | Persistent state involved |\n| 4. Dual writes | Write to both old and new sources simultaneously for consistency | Persistent state involved |\n| 5. Backfill | Migrate existing data from old source to new | Historical data exists |\n| 6. Switch reads | Move read operations from old source to new | Persistent state involved |\n| 7. Remove legacy | Delete old code, old storage, old dependencies | Always |\n\nFor detailed examples per refactor type, read the reference file at:\n`plugins\u002Fharness\u002Fskills\u002Fstrangler-fig\u002Freferences\u002Fsteps-by-context.md`\n\nFor common merge criteria patterns and observation strategies, read:\n`plugins\u002Fharness\u002Fskills\u002Fstrangler-fig\u002Freferences\u002Fgate-patterns.md`\n\n## Output\n\nProduce a goal dependency graph and per-goal summaries as structured content. Do NOT save files — the invoking command (`\u002Fharness:refactor`) handles document creation.\n\n## Key Principles\n\n- **Reversibility is the core value** — every goal (except final deletion goals) should be reversible\n- **Transitional architecture is acceptable** — temporary code enabling coexistence is not waste, it's risk reduction\n- **Goals have explicit dependencies** — each goal declares what must be merged before it begins\n- **Merge criteria document deployment readiness** — they are advisory checkpoints, not automated gates\n- **Goal count and scope varies by refactor** — a simple extraction might be 2 goals; a complex service split might be 8\n\n## Common Mistakes\n\n| Mistake | Why It's Dangerous | Fix |\n|---------|-------------------|-----|\n| Scoping a goal that isn't production-safe to merge independently | If the PR breaks prod when merged alone, it's not a valid goal boundary | Restructure: add a feature flag, split further, or make the change additive-only |\n| Making goals too granular (15 PRs for a simple extraction) | Review fatigue, coordination overhead, unclear progress | Combine steps that can't be independently verified into a single goal |\n| Making goals too coarse (one mega-PR) | Defeats the purpose of incremental safety; hard to review and impossible to roll back cleanly | Split at seams where production safety is naturally maintained |\n| Not documenting rollback for each goal | You won't remember how to undo under incident pressure | Every goal needs a rollback note written before implementation |\n| Not identifying which goals can parallelize | Missed opportunity to reduce calendar time | Explicitly map which goals have no shared dependency and can run in parallel |\n\n## Red Flags — STOP and Reassess\n\n- \"This goal's PR would break prod if merged alone\" — the goal scope is wrong; restructure it\n- \"We need all goals merged simultaneously\" — goals aren't independent enough; find a way to sequence them safely\n- \"Skip the merge criteria, it obviously works\" — verify anyway; obvious things fail silently in production\n- \"Let's just do it all in one PR\" — defeats the purpose of incremental safety and eliminates the ability to roll back individual changes\n\n**All of these mean: revisit goal boundaries, restore production safety, then proceed.**\n",{"name":5,"description":7},"master","2ff0f5c67a13541a23f2cf901dff323bdb8c11fc","plugins\u002Fharness\u002Fskills\u002Fstrangler-fig",0,"https:\u002F\u002Fgithub.com\u002Fdonovan-yohan\u002Fchalk-bag","https:\u002F\u002Fgithub.com\u002Fdonovan-yohan","http:\u002F\u002Fdonovanyohan.com","Promise nothing, deliver less","2026-07-18 09:22:00",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add donovan-yohan\u002Fchalk-bag --skill strangler-fig",{"tool":56,"command":57},"bunx","bunx skills add donovan-yohan\u002Fchalk-bag --skill strangler-fig",{"tool":59,"command":60},"pnpm","pnpm dlx skills add donovan-yohan\u002Fchalk-bag --skill strangler-fig","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdonovan-yohan\u002Fchalk-bag\u002Fblob\u002Fmaster\u002Fplugins\u002Fharness\u002Fskills\u002Fstrangler-fig\u002FSKILL.md",true,[64,70],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Fgate-patterns.md","REFERENCE","参考文档",8269,"https:\u002F\u002Fgithub.com\u002Fdonovan-yohan\u002Fchalk-bag\u002Fblob\u002Fmaster\u002Fplugins\u002Fharness\u002Fskills\u002Fstrangler-fig\u002Freferences\u002Fgate-patterns.md",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fsteps-by-context.md",11459,"https:\u002F\u002Fgithub.com\u002Fdonovan-yohan\u002Fchalk-bag\u002Fblob\u002Fmaster\u002Fplugins\u002Fharness\u002Fskills\u002Fstrangler-fig\u002Freferences\u002Fsteps-by-context.md",[75],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":86,"publishedAt":36},"01M70FT9G10WPQBYAZ2MEMY4HC","example-skill","Use when you need a concrete example chalkbag skill bundle","https:\u002F\u002Fgithub.com\u002Fdonovan-yohan\u002Fchalk-bag\u002Fblob\u002Fmaster\u002Fchalkbag\u002Ftemplates\u002F.chalk\u002Fskills\u002Fexample-skill\u002FSKILL.md",[81],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[87,88,30,28,89,90],"example","example skill","you","bundle"]