principle-outcome-oriented-execution

Guides planned rewrites and migrations toward verified end-state architectures over transitional stability.

136|8|Updated May 9, 2026
One-click install
npx skills add https://github.com/Sma1lboy/rove --skill principle-outcome-oriented-execution-sma1lboy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-outcome-oriented-execution
Source: https://github.com/Sma1lboy/rove/tree/main/.agents/skills/pstack/skills/principle-outcome-oriented-execution
Command: npx skills add https://github.com/Sma1lboy/rove --skill principle-outcome-oriented-execution-sma1lboy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Planned rewrites and migrations often accumulate throwaway compatibility code because teams try to keep every intermediate state fully stable, turning temporary scaffolding into long-lived technical debt. ## Core Features & Use Cases - End-State Prioritization: Converges work on the intended target architecture instead of preserving smooth intermediate states. - Scoped Breakage Policy: Permits intermediate breakage only when it is planned, scoped, and reversible, with explicit declarations of where it is acceptable. - Verification Boundaries: Requires full static and runtime verification at plan completion before declaring the work done. - Use Case: During a multi-phase migration from a legacy module to a new architecture, apply this principle to delete old code paths directly rather than writing adapter layers, then run full verification at the final phase boundary. ## Quick Start Apply the outcome-oriented execution principle to plan this migration so we converge on the target architecture with verification at each phase boundary.

Frequently Asked Questions about principle-outcome-oriented-execution

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

FAQPage Schema
How do I plan a code migration without building throwaway compatibility layers?▼

Converge directly on the target architecture and accept planned, scoped, reversible intermediate breakage instead of writing adapter code. Declare where breakage is acceptable and run full verification at the final phase boundary.

When should I use outcome-oriented execution during a rewrite?▼

Use it for planned rewrites and migrations that have explicit phase boundaries. It is designed for work where keeping every intermediate step stable would create temporary compatibility code that becomes long-lived debt.

Is it acceptable to break the build during a phased migration?▼

Intermediate breakage is acceptable only when it is planned, scoped, and reversible. You must declare where temporary breakage is acceptable and keep high-signal checks running for actively touched areas.

What verification is required before declaring a migration done?▼

Full static and runtime verification at plan completion is required before declaring the work done. Final verification is mandatory regardless of how intermediate phases were handled.

When should I not use outcome-oriented execution?▼

Avoid it for work without explicit phase boundaries or where intermediate states must remain continuously stable, such as live production systems serving traffic during incremental changes. It is scoped to planned rewrites and migrations.