change-manager

Orchestrates scoped brownfield changes through propose, apply, verify, and archive phases.

Updated Jun 29, 2026
One-click install
npx skills add https://github.com/iJosueeh/amauta --skill change-manager-ijosueeh
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: change-manager
Source: https://github.com/iJosueeh/amauta/tree/main/.opencode/skills/change-manager
Command: npx skills add https://github.com/iJosueeh/amauta --skill change-manager-ijosueeh

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Incremental feature changes to an existing product often lack documented scope, verification evidence, and a clean merge back into the product specification, leading to scope creep and orphaned change folders. ## Core Features & Use Cases - Four-Phase Workflow: Runs propose, apply, verify, and archive phases for one named change under changes/<change-name>/, aligned with OpenSpec-style spec-driven development. - Delta Specs & Templates: Generates proposal.md, specs.md (ADDED/MODIFIED/REMOVED deltas), design.md, tasks.md, and verify.md from templates, then merges deltas into Product-Spec.md at archive time. - Scoped Delegation & Rollback: Delegates implementation to dev-builder with change-scoped tasks only, snapshots files before apply, and auto-restores from snapshot when verification fails. - Use Case: A user wants to add dark mode to an existing product that already has Product-Spec.md. The Skill creates changes/add-dark-mode/ with an IN/OUT scope proposal, coordinates implementation, verifies each acceptance criterion with test evidence, then archives the change and updates the Spec and CHANGELOG. ## Quick Start Ask the assistant to run /change-manager propose add-dark-mode to scaffold a scoped change proposal for your existing product.

Frequently Asked Questions about change-manager

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

FAQPage Schema
How do I manage incremental feature changes in a spec-driven project?▼

Create a named change folder under changes/ containing a proposal, delta specs, design, tasks, and verification artifacts. Run the propose phase to define scope, apply to implement, verify to test acceptance criteria, and archive to merge deltas back into the main specification.

What is the difference between change-manager and product-spec-builder?▼

change-manager handles brownfield, scoped deltas to an existing Product-Spec.md through the changes/ workflow. product-spec-builder creates the initial Product-Spec from scratch or performs wholesale Spec rewrites, and it never creates the changes/ folder.

When should I not use the changes/ workflow?▼

Skip it for first-time product specifications, whole-spec rewrites, bug fixes only, and release packaging. Those cases route to product-spec-builder, bug-fixer, or release-builder respectively, since the changes/ workflow is designed for scoped feature deltas.

What happens if change verification fails?▼

If any acceptance criterion fails and a pre-apply snapshot exists, the workflow auto-restores all changed files from changes/<name>/_snapshot/ and records the failure in verify.md. The change returns to its pre-apply state and cannot be archived until criteria pass or the user explicitly waives.

How does the archive phase prevent spec drift?▼

Archive requires verify.md to pass, then merges the specs.md Delta sections (ADDED/MODIFIED/REMOVED) into Product-Spec.md, updates Product-Spec-CHANGELOG.md, and moves the folder to changes/archive/. This ensures the long-lived Spec stays synchronized with completed changes.