dd-ai-refactor-workflow

Guides safe legacy code refactoring through characterization tests, staged diagnosis, and CI-verified incremental commits.

Updated Jun 11, 2026
One-click install
npx skills add https://github.com/marcocpt/trae_skills --skill dd-ai-refactor-workflow-marcocpt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dd-ai-refactor-workflow
Source: https://github.com/marcocpt/trae_skills/tree/main/dd-ai-refactor-workflow
Command: npx skills add https://github.com/marcocpt/trae_skills --skill dd-ai-refactor-workflow-marcocpt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Refactoring legacy or tangled code with AI is risky: the AI cannot tell whether strange-looking code is a bug or intentional business logic, and large rewrites cause behavior drift. This Skill enforces a disciplined workflow—understand first, lock behavior with tests, then refactor in small verified steps—so refactoring never silently changes observable behavior. ## Core Features & Use Cases - Four-Phase Linear Process: Documentation and architecture mapping, Characterization Test creation to lock existing behavior, diagnostic refactoring report (God Objects, Long Methods, circular dependencies), and a dependency-ordered roadmap with rollback strategies. - Hard Brake Points & Human Gates: Forces human confirmation when AI cannot distinguish bug from feature, before architecture evolution, before merging dependency-breaking changes with drift risk, and when tests lock in suspected buggy behavior. - Mandatory CI Verification: Every commit must pass remote CI (never local swift test or xcodebuild test), with three parallel review sub-agents checking behavior preservation, hallucinated APIs, fake-green tests, and privacy leaks. - Use Case: You inherit a macOS Xcode project with a 3000-line VisionManager God Object. The Skill walks you through documenting the architecture, writing characterization tests verified in CI, generating a prioritized diagnosis report, then extracting services one small merge-only commit at a time with full CI validation. ## Quick Start Ask the AI to refactor a legacy module using the AI refactoring workflow, starting with behavior-locking characterization tests before any code changes.

Frequently Asked Questions about dd-ai-refactor-workflow

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

FAQPage Schema
How do I refactor legacy code safely with AI?

Follow a four-phase process: document the architecture, lock existing behavior with characterization tests verified in CI, generate a prioritized diagnosis report, then execute small single-purpose commits. Never rewrite everything at once, and confirm with humans when the AI cannot tell a bug from intended business logic.

What is a characterization test in legacy code refactoring?

A characterization test locks the current observable behavior of code before refactoring, even if that behavior looks wrong. Tests are scoped only to the modules being refactored, graded by testability, and must pass in CI rather than just locally before any structural changes begin.

Why can't I use swift test instead of CI for refactoring verification?

swift test only covers the SwiftPM subset of an Xcode project, and local environments differ from CI in signing, SDK, and runner configuration. Behavior preservation is only confirmed when the full CI pipeline passes on the pushed branch.

When should AI stop and ask a human during refactoring?

Human confirmation is required at four brake points: when AI cannot distinguish a bug from a feature, before starting architecture-level evolution, before merging dependency-breaking changes flagged for behavior drift, and when a characterization test locks in suspected buggy behavior.

What happens when CI fails during a refactoring commit?

The workflow automatically pulls CI logs, analyzes the failure, fixes it, and re-runs CI up to three times. If still failing, it escalates with options to reproduce locally for diagnosis only, revert the commit, retry, or stop the refactoring session.

When should I not use this refactoring workflow?

Do not use it for bug fixes, new feature development, or pure documentation changes, which have their own dedicated workflows. It is designed specifically for behavior-preserving structural improvements to existing legacy code.