change-pipeline

Analyze code changes for regression risks and enforce approval gates.

3|Updated Feb 24, 2026
One-click install
npx skills add https://github.com/Doumajnik/template --skill change-pipeline
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: change-pipeline
Source: https://github.com/Doumajnik/template/tree/main/.github/skills/change-pipeline
Command: npx skills add https://github.com/Doumajnik/template --skill change-pipeline

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Modifying existing code carries high risk of unintended regressions, broken dependent functionality, and cascading side effects even for seemingly small changes. This Skill eliminates that risk by enforcing a structured, adversarial pipeline that maps blast radius and validates every change before implementation.

Core Features & Use Cases

  • Mandatory Impact Analysis: Automatically maps all affected files, dependent modules, and potential regression risks before any code is touched.
  • Adversarial Review & Regression Checks: Includes dedicated critique loops and explicit regression checklists to catch breaking changes and unintended side effects.
  • End-to-End Change Governance: Manages the full workflow from initial spec to post-implementation documentation, with mandatory user approval gates and audit trails.
  • Use Case: If you need to refactor a core payment processing module, this Skill ensures all dependent checkout flows, billing integrations, and test suites are validated to prevent payment logic breakage.

Quick Start

Use the change-pipeline skill to update the existing user authentication flow to add multi-factor authentication support without breaking existing login integrations.

Frequently Asked Questions about change-pipeline

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

FAQPage Schema
How do I safely modify existing source code without causing regressions?

To safely modify existing source code without causing regressions, use a structured change pipeline that enforces mandatory impact analysis, adversarial review, and regression checklists before implementation. This maps the blast radius and validates backward compatibility to prevent broken dependent functionality.

What is the best way to refactor a core module and prevent breaking dependent functionality?

The best way to refactor a core module and prevent breaking dependent functionality is to apply an adversarial review pipeline that automatically maps all affected files and dependent modules. This process uses explicit regression checklists and user approval gates to validate changes before they are implemented.

How does impact analysis work for brownfield development feature updates?

Impact analysis for brownfield development feature updates works by automatically mapping all affected files, dependent modules, and potential regression risks before any code is touched. This structured analysis identifies cascading side effects and enforces user approval gates to ensure change safety.

Can I update API signatures in an existing project without breaking backward compatibility?

Yes, you can update API signatures in an existing project without breaking backward compatibility by enforcing a change pipeline with dedicated critique loops and regression checks. This governance workflow validates all dependent integrations and requires explicit user approval before implementation proceeds.

When do I need a structured change pipeline for code alterations?

You need a structured change pipeline for code alterations when modifying existing source code carries a high risk of unintended regressions or cascading side effects. It is essential for brownfield development tasks including feature updates, refactoring, logic adjustments, and API signature changes.

Why does modifying existing code cause unintended side effects and broken functionality?

Modifying existing code causes unintended side effects and broken functionality because even seemingly small changes can have a large blast radius across dependent modules. A change pipeline eliminates this risk by mapping affected files and enforcing regression checklists before implementation begins.