updating-a-pipeline-step - SKILL.md Agent Skill

name: updating-a-pipeline-step description: Modify an existing step in a named Superpipelines workflow while preserving contracts and topology continuity. user-invocable: false

Updating a Pipeline Step — Modification Workflow

The Updating a Pipeline Step workflow ensures that modifications to individual components do not break the larger orchestration contract. Impact analysis identifies how I/O schema changes propagate to predecessors and successors, and an audit-and-stage protocol gates all changes before promotion to production paths. The process of verifying that neighbor steps still satisfy (or consume) modified input/output contracts. A modification affecting only a step's logic or tools, with no impact on the topology edges. The automatic update of neighboring steps to accommodate a changed I/O schema.

Workflow Phases

### PHASE 0: PIPELINE & STEP SELECTION - Resolve registries and identify the target pipeline and step via `AskUserQuestion`. - Display step metadata: agent/skill paths, current frontmatter, and declared I/O schemas.

PHASE 1: IMPACT ANALYSIS (4D)

Apply the 4D Method to deconstruct the brief.
Classify the change category: Input Change, Output Change, Internal Change, or Full Contract Change.
Goal: Identify exactly which predecessors or successors are affected by the mutation.

PHASE 2: EDGE RE-VALIDATION

If I/O schemas change, verify that all neighbor steps remain compatible.
Present the impact analysis to the user (e.g., "Updating A's output affects B and C").
Obtain explicit user confirmation before propagating contract changes to neighboring steps.

PHASE 3: ARCHITECTED STAGING

Dispatch pipeline-architect in STEP-UPDATE mode to generate modified artifacts.
All changes MUST be written to {ROOT}/superpipelines/temp/{P}/edit-{ts}/ for staging. NEVER overwrite production files during design.

PHASE 4: DELTA AUDIT

Dispatch pipeline-auditor in DELTA mode on the staged artifacts and neighbor components.
SEV-0 or SEV-1 findings block promotion. Dispatch the Architect to remediate and re-audit until the delta is clear.

PHASE 5: HUMAN APPROVAL & PROMOTION

Present a diff summary, updated topology edges, and audit results for human review (AskUserQuestion).
Upon APPROVE, atomically move staged files to their final absolute paths and update registry.json.
Version Stamp: Update plugin_version in topology.json, the registry entry, and the modified agent's frontmatter to the current superpipelines version.

- NEVER assume an I/O change is "minor"; always run the Phase 2 impact analysis. - ALWAYS use a staging directory (`edit-{ts}/`) for all modifications to allow for safe rollback. - Propagate contract changes to neighbors ONLY after explicit user authorization. - ALWAYS update `plugin_version` in `topology.json`, the registry entry, and modified agent frontmatter to the current superpipelines version when promoting changes.

Red Flags — STOP

"The output schema change is minor — no need to check successors." → STOP. Contract changes propagate; skipping re-validation causes runtime cascading failures.
"I'll skip the human gate; it's just a small logic tweak." → STOP. Small logic changes can have non-obvious impacts on state management or neighbor agents.
"The audit found only SEV-2 issues; good enough." → STOP. SEV-0/1 findings are hard blockers for promotion.

Rationalization Table

Reference Files

sk-pipeline-paths/SKILL.md — Path resolution.
sk-write-review-isolation/SKILL.md — Review loop rules.
adding-a-pipeline-step/SKILL.md — Insertion workflow.
deleting-a-pipeline-step/SKILL.md — Removal workflow.