refactoring-sql

Refactor procedural SQL into import/logical/final CTE sequences with extracted ground truth for validation.

3|Updated Feb 27, 2026
One-click install
npx skills add https://github.com/accelerate-data/migration-utility --skill refactoring-sql
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: refactoring-sql
Source: https://github.com/accelerate-data/migration-utility/tree/main/skills/refactoring-sql
Command: npx skills add https://github.com/accelerate-data/migration-utility --skill refactoring-sql

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Refactors procedural SQL into a clean import/logical/final CTE sequence, enabling deterministic downstream modeling and safe proof-backed migrations.

Core Features & Use Cases

  • Restructures stored procedures, views, or materialized views into a layered CTE pipeline
  • Preserves ground-truth extracted SQL for semantic validation and auditing
  • Supports a formal refactor workflow: readiness checks, semantic review, and optional comparison

Quick Start

Provide the source SQL for a stored procedure, view, or materialized view to generate extracted and refactored SQL artifacts.

Frequently Asked Questions about refactoring-sql

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

FAQPage Schema
How do I refactor SQL stored procedures into clean, testable CTEs?

Refactoring SQL into testable CTEs restructures procedural logic into an import, logical, and final CTE sequence. This separates extraction ground truth from refactored output, enabling semi-automated validation and safe downstream model generation.

Can I use this SQL refactoring approach on database views and materialized views?

Yes, SQL refactoring applies to stored procedures, views, and materialized views. It restructures these database objects into a layered CTE pipeline, preserving the original extracted SQL for semantic validation and auditing.

What is the best way to separate ground truth SQL from refactored output for migration?

Separating ground truth SQL from refactored output involves structuring queries into import, logical, and final CTE stages. This layered pipeline enables deterministic downstream modeling and proof-backed database migrations.

Does refactoring SQL into CTEs require readiness checks and semantic review?

Yes, the SQL refactoring workflow requires readiness guards, context assembly, and semantic review. These steps validate the extracted ground truth against the refactored CTE sequence, with an optional comparison step if available.

Why do I need to restructure procedural SQL before generating downstream models?

Restructuring procedural SQL is necessary because complex stored procedures lack modularity. Refactoring them into a clean CTE pipeline enables deterministic downstream modeling, safe proof-backed migrations, and semi-automated validation.