ddd

Guides incremental legacy code improvement through analyze, preserve, and improve cycles.

111|73|Updated Mar 20, 2026
One-click install
npx skills add https://github.com/autopus-ai/autopus-adk --skill ddd-autopus-ai
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ddd
Source: https://github.com/autopus-ai/autopus-adk/tree/main/.omp/skills/ddd
Command: npx skills add https://github.com/autopus-ai/autopus-adk --skill ddd-autopus-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Modifying legacy code without breaking existing behavior is risky, especially when callers, side effects, and edge cases are poorly documented. This Skill provides a disciplined methodology for analyzing current behavior, locking it in with characterization tests, and improving the code in small, verifiable steps. ## Core Features & Use Cases - ANALYZE-PRESERVE-IMPROVE Cycle: A structured three-phase workflow that requires understanding callers, side effects, and existing tests before any change, then pinning behavior with characterization tests before refactoring. - Safe Migration Patterns: Applies the Strangler Fig pattern and Branch by Abstraction to replace legacy implementations incrementally without breaking dependents. - Concrete Guardrails: Enforces rules such as no interface changes without tests, transformations under 50 lines, and @AX:ANCHOR tags for functions with fan_in >= 3. - Use Case: When asked to refactor a legacy Go function used across many modules, the Skill first documents current behavior with characterization tests, then improves the code in small steps while keeping all existing tests green. ## Quick Start Use the ddd skill to refactor this legacy function while preserving its existing behavior and adding characterization tests first.

Frequently Asked Questions about ddd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor legacy code without breaking existing behavior?▼

Follow the analyze-preserve-improve cycle: first understand callers, side effects, and existing tests, then write characterization tests that pin current behavior, and finally improve the code in small steps under 50 lines with tests run after each change.

What is a characterization test and when should I write one?▼

A characterization test documents the current behavior of legacy code exactly as it is, regardless of whether that behavior is correct. Write one before any refactoring so you can verify that behavior stays identical after your changes.

How do I replace a legacy implementation using the Strangler Fig pattern?▼

Run the new implementation alongside the old one, gradually shift traffic or callers to the new version, and remove the old implementation only after the replacement is fully validated. This avoids a risky big-bang rewrite.

What is the difference between Strangler Fig and Branch by Abstraction?▼

Strangler Fig replaces functionality by routing traffic to a new implementation over time, while Branch by Abstraction extracts an interface first, then swaps implementations via dependency injection. Both enable incremental replacement without breaking dependents.

When should I not change an existing function signature?▼

Never change an existing function signature without tests covering its callers, especially when fan_in is high. Instead, add a new function alongside the old one and migrate callers incrementally, tagging high-fan-in functions with @AX:ANCHOR.