On-demandOn-demand: invoked explicitly — never occupies your agent's context until called.
◆Coding pack
Last verified 8/16/2026
What it changes
Passed 21 of 22 test cases with the skill, and 15 of 22 without it.
Without skill68%
With skill95%
Checks it passed that the model alone missed
Separates read DTOs from write aggregates.
Structures the migration roadmap into four distinct phases.
Specifies schema integrity tests during database refactoring.
and 6 more in the full report
6 fixed15 passed either way1 still failing0 broke
Pass-rate lift
+27 pp
Tokens
+48%
Agent turns
0%
Response time
-17%
Model gemini-3.6-flashMeasured 8/16/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 6
Prompt
We have a massive e-commerce monolith where domain logic is entangled across modules and database tables. We need to refactor this application using Domain-Driven Design principles without breaking live traffic. Please generate a detailed, phase-by-phase refactoring roadmap for our system. Your response should outline pre-refactoring evaluation criteria, a structured sequence of migration phases from initial discovery through service extraction, recommended strategic integration patterns, and a matrix of automated metrics and testing approaches to safeguard each step.
What was checked, without and with the skill
Checked
Without skill
With skill
Evaluates business value, risk, and cost prior to refactoring.
Missed
Passed
Structures the migration roadmap into four distinct phases.
Missed
Passed
Specifies characterization tests using Feathers technique as the legacy safety net.
Missed
Passed
case-01 · gemini-3.6-flash · 8/16/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md180 linessingle file
Legacy Refactoring with DDD
Refactoring legacy systems using Domain-Driven Design as the strategic compass. DDD tells you WHERE and WHY to refactor; traditional techniques (progressive-refactoring, mikado-method) tell you HOW.
Principle: "Start simple, grow big" -- incremental steps tested at each stage.
Decision Framework: Before Refactoring
Ask three questions before any DDD refactoring:
Business value: what business outcome does refactoring this area enable?
Risk: what breaks if we refactor vs. if we do not?
Cost: time, effort, disruption -- is it justified?
When NOT to Refactor
System scheduled for replacement
Stable system with no new development
Cost exceeds benefit
Team lacks DDD experience with no learning budget
Domain is genuinely simple (CRUD-dominated)
Cynefin-Refactoring Mapping
Cynefin Domain
Refactoring Approach
Clear
Apply established patterns directly; standard refactoring catalogs
Complicated
Analyze with experts, then apply patterns; multiple valid solutions
Complex
Probe with safe-to-fail experiments; EventStorming to discover patterns
Chaotic
Act first to stabilize, then refactor; emergency patches acceptable
Confusion
Gather information before deciding; avoid premature refactoring
Migration Methodology (4 Phases)
Phase 1: Understand and Stabilize
Run EventStorming to map current system (Big Picture)
Assess complexity using Cynefin framework
Write characterization tests for critical paths (Feathers technique)
Identify bounded contexts in existing codebase via language divergence
Phase 2: Modularize the Monolith
Introduce module structure aligned with bounded contexts