craigsmitham

I'd really like feedback on the standard/specification. In short, it defines a quality model of quality factors/characteristics (which you can define as security, reliability, etc), requirements (how those qualities are assessed), a customizable rating scale, and "areas" to have different attributes/requirements for different areas of your project (e.g. frontend/backend, tests, specs, etc). That's basically it - and it follows a consistent pattern of how quality models have been practiced for decades. They are simple and powerful, but - until AI - kind of a pain/toil to get started with. Simple but not easy - until now. QUALITY.md + AI makes it easy. However, you still have to put in the work/care/attention to what goes into your QUALITY.md so you can get maximum leverage from it.

No commercial offering associated with this effort. But a lot of potential for others to incorporate the QUALITY.md standard into products that assess/evaluate quality at varying levels of a loop stack.

The agent skill/CLI that's provided generate a quality evaluation report with recommendations for handoff (ideal for loop engineering) is just one example of how the QUALITY.md file can be used.

It's easy to imagine a SaaS that does the same that provides better eval, reporting, and integration capabilities.

No magic. QUALITY.md describes what is unique and valueble to your proejct context that model providers won't have insight into.

THe problem is that humans often don't know - this is as much about encouraging getting the humans aligned as the agents. Completely agree agents really aren't stakeholders. Fine point. I'll update description to clarify ... thank you!

OP here. You're spot on. Trade-offs matter. The trade-offs are implied by the selection of what quality factors/attributes are selected and their requirements. A statement like "performance can take a huge hit at the cost of being dead easy to read and reason about" can sit right there in the QUALITY.md as a comment or in the markdown body.

OData?

I've started and stopped using VS Code multiple times. Each time so far I've given up because of poor vim support - although it is improving. So I end up going back to using VS with the excellent vsvim plugin. Hopefully VS Code can get to parity soon.

This looks promising. I think there is value from separating the spec from the implementation details. Here is a dream workflow:

* version controlled canonical specs and documentation of API using apistudio.io

* use existing Swagger extensions to build out Swagger spec from implementation

* Some tool to automatically compare/verify canonical swagger spec with spec generated by framework plugin

TPL DataFlow is great for orchestrating concurrent computation in individual apps. Orleans is designed to be an application programming framework for the cloud - distributed, fault tolerant, and scalable. Personally, I like how Akka (JVM) builds on top of its actor model to provide dataflow programming. Orleans is not a primitive actor framework like Akka - it does the hard clustering and fault handling for you. Orleans is not a trivial library and introduces a number of constraints on an architecture that leverages it. That being said, it makes getting started much easier, depending on your goal. What is really nice about Orleans, is that the programming model exposed to the programmer is still just the TPL async/await goodness.