I judge code quality by how confidently I can trust a feature today and how easily someone else can change it tomorrow.

That applies whether I accept a suggested method or hand an agent a whole feature. With an agent, I also delegate decisions about where logic belongs, what to reuse, and how to verify the result. Reviewing the code means reviewing those decisions and the evidence behind them.

Over the past year, I’ve turned lessons from recurring mistakes into rules and skills for Uno Platform work. These are the standards I use. The reference matrix at the end lists the skills you can borrow.

Take a form with a Save button. The user fills it out, clicks Save, and sees a confirmation. I want to know what happens when the connection drops or the user clicks twice. I also want someone to find and change its validation rules confidently a month later.

If the form calculates an order total, the agent needs the product’s rules for quantities, discounts, and rounding before it can implement or test them. That’s why uno-write-spec runs before any code. Anything the agent would otherwise assume goes under Unresolved Questions for me to decide.

Reliability belongs in that definition. A failed save should preserve what the user typed and offer a way to recover. A double click should save once. For screens that read or write data, uno-component-states defines loading, empty, and error states. Retry has to work in the running app before the change counts.

I also want help finding failures I’ve missed. uno-break-it gives a separate QA agent scenarios to try in the running app: double-fired navigation, navigating mid-load, a spammed toggle, forced errors, and an older response arriving after a newer one. Each finding gets a severity and a screenshot.

Security is part of the same review. The service should verify that the user is authorized to submit the form, and sensitive data should stay out of logs. The spec’s Architecture Brief records what gets logged, but authorization is something I still review by hand. None of my skills check it yet.

When I read the implementation, I want to follow how the form’s values become a saved record. Names should explain their purpose. I should be able to tell where validation ends and storage begins.

Before changing anything, the agent reads HANDOFF.md, the Git state, and the spec. If a save service already exists, it should use it. Before writing a custom control or helper, or adding a package, it checks what Uno Toolkit and Uno Extensions already provide.

The code should follow the project’s conventions too. If screens share an approach to loading and errors, the next screen should use it. The agent loads the relevant skill and names its chosen pattern in one line so I can review that choice.

A hook called xaml-semantic-lint checks after every edit for departures from those conventions, including hand-drawn cards, code-behind handlers, hard-coded colors, and blocking waits on tasks. Its feedback names each problem and its fix:

xaml-semantic-lint: 2 hit(s) in FooViewModel.cs (PLATFORMLEAK, SYNCWAIT)

- PLATFORMLEAK: platform branch on __ANDROID__ in a model
- SYNCWAIT: blocking wait: Async().Result

PLATFORMLEAK fix: move the branch into a platform service and inject it;
models stay platform-neutral.

SYNCWAIT fix: await the task. If the caller cannot be async
(constructor, property), start the load from a command or MVUX
feed instead of blocking.

Readability still takes judgment. A longer method can be easy to follow; several vaguely named helpers can make the same logic harder to understand. The agent’s explanation helps during review, but the code has to make sense once the chat is gone.

Comments should explain constraints and decisions. I use uno-audit to remove comments that merely narrate the next line and keep the ones that explain why the code works a particular way.

Maintainability becomes concrete when a requirement changes. If the form needs a new validation rule, the next developer or agent should find the existing rules and add it where it belongs.

I probe that before anyone makes the change. In uno-audit, a change-cost probe takes the app’s main feature and three plausible requests. For each, it lists the affected files, identifies the test that would catch a mistake, and gives a verdict: Contained, Scattered, or Unguarded.

Here’s what it revealed in Patina, my public-art conservation app:

The first row exposed a weakness that passing tests had hidden. The rule was correct and tested, but the page and both resource files restated it without checks on that text. Changing the behavior could leave the explanation wrong.

So the review needs to cover every place that describes the rule. Each copy creates another opportunity for drift, and I want to understand why the duplication exists before adding more.

Structural decisions go in the spec with a reason and a trade-off. The handoff skill updates HANDOFF.md after each substantial session so the next session starts with that context.

Workarounds need an explicit removal condition. My uno-scaffolding rule requires a comment such as:

// WORKAROUND(<gotcha name>): <what it works around>; remove when Uno.Sdk > 6.7.30

The next person should know why it exists and when it is safe to remove.

I want to verify a validation rule without launching the app and clicking through screens. I also want to know which checks passed, failed, or couldn’t run.

The build gates in uno-scaffolding accumulate with the scope of the work:

If a check cannot run because, say, a device is unavailable, the agent must report it and explain why. I need to know where confidence ends.

I also check where the expected results came from. If the agent assumes discounts apply before tax and writes tests around that, code and tests agree while both contradict the product. Tests need to reflect an agreed requirement.

For UI changes, uno-verify launches a Debug build through Uno Platform’s app automation server, invokes controls, and reads the visual tree and DataContext after each action. In uno-completeness-audit, anything graded as proven at runtime must name its evidence: an element, a DataContext value, a trace line, or a test.

A stop hook enforces the reporting requirement. In an Uno Platform repository, if the agent claims the work is done or ready to demo without a completeness report newer than the last source commit, the hook stops it. The agent then runs uno-completeness-audit and saves the report, or narrows its claim to match the evidence it has.

A small internal tool can stay simple. A larger app with more teams and integrations needs firmer boundaries.

When an agent proposes an abstraction, I want to know what it makes easier today. Giving a business rule a clear home or making an external dependency testable is useful. Imagined future requirements make a weaker case.

My global rules include a Do Not Overbuild section. They also require the agent to pause for my decision before adding a dependency, changing a data model, or changing a public API. The agent lays out the options, and I choose.

The spec records the trade-offs of choices I accept:

Decision: MVUX for the survey page
Reason:   durable async state with loading, error, and refresh
Tradeoff: {Binding} on the data surface, no compile-time x:Bind checks

My checks get the same scrutiny. A lint rule for x:Bind without a Mode flagged 16 places in one app, and all 16 were correct, so I kept it as a report that does not block. A check needs to earn the interruption it creates.

A long list should stay responsive with realistic data. Memory and network use should be reasonable for the work the app performs.

uno-hill-climb gives a performance agent one metric to improve. It changes one thing per attempt, measures the result, and keeps a change only when the metric improves and screenshots of fixed app states still match within tolerance.

Other skills cover stress cases. uno-completeness-audit binds a 200-row list and a 400-character string to check for clipping and overflow. uno-break-it navigates between two pages 20 times while watching memory. Those checks give me something to inspect beyond a screen that looks fine with a few sample records.

When the next validation request arrives, I want a developer or agent to find the rule, make the change, and show how they checked it. That is the practical test behind all of this.

These checks earned their place by catching my mistakes. Yours will come from the mistakes you keep making. If you want a starting point, the rules and skills are here: github.com/noknowscode/mt-uno-workflow.