preserve-existing-flow

Preserve existing ownership, data flow, and decision paths in brownfield systems.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/UntaDotMy/codex_skills --skill preserve-existing-flow
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: preserve-existing-flow
Source: https://github.com/UntaDotMy/codex_skills/tree/main/preserve-existing-flow
Command: npx skills add https://github.com/UntaDotMy/codex_skills --skill preserve-existing-flow

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Preserve existing flows before brownfield changes by requiring architecture-first understanding and ownership-aware layering of new behavior, preventing direct overwrites of current functionality.

Core Features & Use Cases

  • Layer new behavior beside the current owner path rather than overwriting it.
  • Map and respect ownership boundaries across producers, transport, state, and consumers.
  • Require a concise working brief, evidence, and explicit approval for ownership migration before edits.

Quick Start

Produce a short working brief detailing requested behavior, current flow, owners, evidence needed, and task scope before editing.

Frequently Asked Questions about preserve-existing-flow

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

FAQPage Schema
How do I modify brownfield systems without breaking existing data flow?

Preserving existing flows in brownfield systems requires mapping ownership boundaries across producers, transport, state, and consumers. You must layer new behavior beside the current owner path and obtain explicit approval for ownership migration before making any edits.

What is ownership-aware layering for brownfield code changes?

Ownership-aware layering is an architecture-first approach that maps decision paths and respects boundaries across producers, transport, and state. It requires specifying discovery requirements and validation evidence before layering new behavior into existing queues or state machines.

How do I start preserving existing flows before editing a state machine?

Start by producing a concise working brief detailing the requested behavior, current flow, owners, evidence needed, and task scope. This brief determines whether your task is read-only, review-only, or implementation-approved before any edits to state machines begin.

Can I overwrite current functionality directly in a brownfield codebase?

No, directly overwriting current functionality risks unintended behavioral changes. You must layer new behavior beside the current owner path and require explicit approval for ownership migration before executing any implementation-approved edits on the codebase.

When do I need validation evidence for brownfield transport path changes?

Validation evidence is required whenever changes are layered through current owners in transport paths or queues. You must specify whether the task is read-only, review-only, or implementation-approved, gathering evidence before any edits to prevent risk-management failures.