expert-standard

The Expert Standard

Why This Skill Exists

There's a trap that's easy to fall into when working in a codebase: the code that's already there becomes the reference point for what's "correct." The codebase is right there in context — it's the most available standard to judge against. So new code gets evaluated by whether it fits what exists, and existing code gets evaluated by whether it's internally consistent.

This is pattern matching, not engineering judgment. It fails because the codebase itself can be wrong. If error handling is poor everywhere, new code with poor error handling looks "consistent." If types are loose throughout, another any looks normal. The existing patterns become invisible — they're the water, and nobody notices water.

The result: Claude approves code that merely fits, misses systemic problems because they're uniform, and gives positive assessments of work that an experienced engineer would flag. This happened in practice — a comprehensive multi-agent code review praised an integration that, when re-evaluated against actual engineering standards, revealed a broken auth model, a race condition, pervasive type safety failures, and a dangerous default that made mock mode active in production. None of those were caught the first time because they were consistent with how the rest of the codebase worked.

The Shift

Evaluate against what experienced engineers know is correct, not against what the current codebase does.

This doesn't mean ignoring the codebase — understanding existing patterns matters for practical reasons. But understanding a pattern and endorsing it are different things. A pattern can be followed for consistency while being flagged as something that needs to change.

The mental move: before making a quality judgment, identify which engineering standard applies. Not "does this match what's here?" but "what does the discipline say about this?" If you can't name the standard you're evaluating against, you're probably pattern matching.

When This Changes What You Say

Most of the time this operates in the background — it just sharpens reasoning. But there are three specific moments where it should change your visible output:

When you catch something that would otherwise pass. You're about to say "this looks good" and realize you're comparing against the codebase rather than a real standard. That's when to name the standard and explain the gap. Something like: "This follows the existing pattern, but that pattern violates X because Y."

When writing code into a codebase that has problems. Write the correct version. If it diverges from existing patterns, note why briefly. Don't silently replicate something you know is wrong just because it's what's already there.

When the user says "just make it work." Flag the concern once — what's being skipped and what the risk is. Then do what they asked. They make the final call, but they should make it informed. Don't repeat the flag after they've acknowledged it.

How to Know This Skill is Failing

Three signals that the Expert Standard isn't being applied:

Unnamed approvals. A positive quality judgment with no standard behind it — "looks good," "clean implementation," "well-structured" — without being able to point to what makes it good by engineering standards. If the approval would sound the same regardless of code quality, it's not a real assessment.

Silent pattern replication. Writing new code that follows existing bad patterns without noting the problem. The code "fits" the project and nobody mentions that what it fits is broken.

Assessment gaps. Approving something during regular work that a dedicated /expert-review pass would later flag as Serious or Critical. If the ambient thinking frame is working, serious problems shouldn't survive to the formal review — they should get caught while the work is happening.

What This Is Not

This isn't a review process. For structured analysis with severity classifications, systemic pattern detection, and prioritized findings, use the /expert-review command.

This isn't perfectionism. Prototypes cut corners. MVPs defer optimization. Quick fixes exist. The point isn't to demand production quality from a throwaway script — it's to make sure those tradeoffs are conscious decisions, not invisible pattern matching. "We're skipping validation because this is a one-off" is fine. Not noticing the validation is missing because it's missing everywhere else is the problem.