principle-outcome-oriented-execution
cursor/plugins
Prioritize end-state correctness over intermediate stability during planned rewrites and migrations.
What is principle-outcome-oriented-execution?
A principle for managing large refactors and migrations by accepting planned intermediate breakage in exchange for cleaner target architecture. Use this when you have explicit phase boundaries and can verify correctness at completion, rather than maintaining throwaway compatibility code throughout the transition.
- Converge directly on target architecture without preserving smooth intermediate states
- Accept planned, scoped breakage during migration phases
- Eliminate temporary compatibility code that becomes long-lived technical debt
- Declare explicit verification boundaries for correctness checks
- Maintain high-signal checks in actively touched areas during migration
How to install principle-outcome-oriented-execution
npx skills add https://github.com/cursor/plugins --skill principle-outcome-oriented-executionHow to use principle-outcome-oriented-execution
- 1.Define explicit phase boundaries for your migration or rewrite
- 2.Declare which areas will have temporary breakage and when
- 3.Keep high-signal checks active for code being actively modified
- 4.Plan full static and runtime verification at each phase boundary
- 5.Execute phases in order, verifying correctness at completion rather than maintaining intermediate stability
Use cases
- Large codebase rewrites with clear target architecture
- Database schema migrations with phase-based cutover
- API version migrations where old and new cannot coexist cleanly
- Module restructuring that requires temporary import breakage
- Framework or dependency upgrades requiring structural changes
- Engineering leads planning major refactors
- Architects designing migration strategies
- Teams managing planned system rewrites
- Developers executing multi-phase technical migrations
principle-outcome-oriented-execution FAQ
Use it for planned, scoped rewrites and migrations with explicit phase boundaries where you can verify correctness at completion. Avoid it for ongoing production systems where intermediate stability is required.
Declare the breakage scope upfront, set a clear deadline for the phase, and require full verification (static and runtime checks) before moving to the next phase.
Breakage in areas actively being migrated, within declared phase boundaries, that is reversible and planned. Not acceptable: silent data corruption, unplanned outages, or changes to stable APIs.
This requires explicit planning, phase boundaries, and verification checkpoints. 'Move fast' is uncontrolled; outcome-oriented execution is disciplined convergence on a target state.
Full instructions (SKILL.md)
Source of truth, from cursor/plugins.
name: principle-outcome-oriented-execution description: "Apply during planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture; don't preserve smooth intermediate states with throwaway compatibility code." disable-model-invocation: true
Outcome-Oriented Execution
Optimize for the intended, verifiable end state rather than preserving smooth intermediate states.
Why: Keeping every intermediate step fully stable often creates temporary compatibility code that becomes long-lived debt. Converge on the target architecture and prove correctness at explicit verification boundaries.
Core rule:
- Prioritize end-state integrity over transitional stability
- Intermediate breakage is acceptable when it is planned, scoped, and reversible
Guardrails:
- Use this for planned rewrites and migrations with explicit phase boundaries
- Declare where temporary breakage is acceptable
- Keep high-signal checks for actively touched areas while migrating
- Require full static and runtime verification at plan completion
Related skills
More from cursor/plugins and the wider catalog.
principle-prove-it-works
Verify task completion by checking real artifacts, not proxies or self-reports.
principle-redesign-from-first-principles
Redesign existing systems as if new requirements were foundational, not bolted-on.
principle-separate-before-serializing-shared-state
Eliminate concurrent write conflicts by separating mutable state before applying serialization.
principle-sequence-verifiable-units
Break multi-step work into small verifiable units, sequence commits to prove the logic to reviewers.
principle-subtract-before-you-add
Remove complexity first—delete dead code and redundancy before adding features or refactoring.
principle-type-system-discipline
Apply type-system discipline to eliminate impossible states and catch bugs at compile time.