Skip to content

kbot-ships/engop-system

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

16 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Execution Operating System


What is this

A lightweight framework for engineering teams that want to stop building plausible things that aren't the customer thing.

The core idea: make intent testable before you build, so rework becomes the exception.


The problem: avoidable churn

Teams build features where the interface or contract intent was ambiguous:

  • Dashboard that exposed raw data, but users needed actionable insights
  • Powerful API with 20 endpoints, but the UI only needed 3 operations
  • Feature X implemented, but customer actually needed Feature Y

Not pervasive, but completely avoidable. The cost is engineering time spent building the right thing twice.


The model: contract-first

Contract-first = UX flow and API contract reviewed together before build starts.

Intent → Design → Contract → Delivery

Four layers. Nothing novel. The key constraint: the contract (UX flow + API surface) is reviewed as a unit before build starts.

Ticket → UX mock + API contract → Build and review → Outcome

If the mock or contract is missing, you build plausible outcomes that aren't the customer outcome. This chain prevents that.


What's in this repo

Folder What it is Start here if...
templates/ Fill-in-the-blank artifacts for your next feature You want to use the framework today
case-studies/ Walkthroughs of the process applied to real features You want to see what good looks like
automation/ Blueprint + reference implementation for ticket gatekeeping You want to build enforcement tooling
decisions/ Decision template for adopting the framework You're leading adoption for your team

Templates

Template Purpose When to use
PRD-lite One-page problem/solution/criteria Before design starts
Design note Technical approach, API impacts, data model, security Before coding starts
UX mock Screen layout + user journey + API surface Before coding starts

Each template includes a filled-in example so you can see what good looks like.


Tooling

This framework defines what to do. PRDEngine automates the hardest part: generating the right-sized requirements artifact from a feature description.

Template PRDEngine tier Output
PRD-lite Lightweight ~1 page scope with problem, criteria, and non-goals
Design note Standard ~3-5 pages with API design, data model, security
UX mock Comprehensive+ ~8-15 pages with user personas, cross-service impact

The ticket gatekeeping bot can invoke PRDEngine to auto-generate these stubs when work starts -- enforcement and artifact creation in one step.


How to get started

If you're an engineer: Copy a template for your next feature. Start with the PRD-lite if requirements feel ambiguous, or the design note if you're about to write code.

If you're a tech lead: Read the case studies to see contract-first applied end-to-end -- with a UI and without one. Then review the decision template with your team.

If you're building tooling: The ticket gatekeeping blueprint has the design and a reference implementation you can fork. It enforces this framework at the ticket system level.


About

Execution Operating System - Intent → Contract → Delivery

Topics

Resources

License

Contributing

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages