Superior Logic

Keep correctness visible from input to observable outcome. Fit the solution to the repository's existing architecture and update every affected side of a contract together.

Use superior-code-review instead when the primary outcome is findings on a diff, commit, branch, pull request, or working tree. Use this skill for a focused domain-logic review or for implementing confirmed behavioral changes.

Model the behavior

Before choosing code, identify:

• trusted and untrusted inputs;
• outputs and observable side effects;
• invariants and authorization rules;
• consumers and compatibility constraints;
• expected failure, retry, duplication, ordering, and concurrency conditions.

State a material assumption only when code and documentation cannot establish it. Ask the user when competing answers would change the product contract.

Read references/contract-evolution-and-workflows.md when changing a shared API, event, file format, client/server contract, state machine, or multi-step workflow that can span versions, retries, or partial deployment.