evolve

Identify design pressures and generate minimal boundary moves with migration plans.

8|Updated Feb 2, 2026
One-click install
npx skills add https://github.com/usurobor/cnos --skill evolve-usurobor
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: evolve
Source: https://github.com/usurobor/cnos/tree/main/src/packages/cnos.eng/skills/eng/evolve
Command: npx skills add https://github.com/usurobor/cnos --skill evolve-usurobor

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Reduce repeated future incoherence by guiding architecture evolution.

Core Features & Use Cases

  • Identify recurring design pressures and challenge assumptions.
  • Generate and compare multiple boundary moves (delete, split, invert, isolate, platformize, externalize) and select the smallest coherent option.
  • Define migration plans, invariants, leverage, and provide clear guidance for long-term coherence.

Quick Start

Analyze the current architecture to surface a recurring pressure and propose the smallest boundary move with a migration plan.

Frequently Asked Questions about evolve

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

FAQPage Schema
How do I reduce recurring design pressure and incoherence in software architecture?

Architecture evolution is the process of guiding structural changes to reduce repeated future incoherence by identifying pressure points, challenging assumptions, and selecting the smallest boundary move to ensure long-term stability.

What are boundary moves in architecture refactoring and when do I need them?

Architecture refactoring boundary moves are structural changes like delete, split, invert, isolate, platformize, or externalize. You need them when facing recurring design pressure and frequent boundary changes across project lifecycles.

How do I plan a system migration when inverting or splitting architectural boundaries?

To plan a system migration when inverting or splitting boundaries, you select the smallest coherent boundary move, then document the specific migration plans alongside required invariants and expected leverage.

What is the best way to challenge assumptions before refactoring a system architecture?

The best way to challenge assumptions before refactoring is to analyze the current architecture to surface recurring design pressures, then evaluate if proposed boundary moves actually address the core edits causing future toil.

Can I apply architecture evolution to systems facing frequent boundary changes across multiple teams?

Yes, you can apply architecture evolution to systems facing frequent boundary changes across teams and project lifecycles. It specifically guides structural changes to reduce repeated incoherence and core edits in these environments.