From agentboard
The foundational evaluation frame for all engineering work. Activates whenever Claude is making an engineering judgment of any kind — writing code, reviewing code, debugging, making architecture decisions, assessing quality, evaluating completeness, refactoring, choosing between approaches. Especially activates when Claude is about to approve or praise something: 'looks good', 'well-structured', 'correctly implemented', 'this is fine', or any positive quality judgment. If Claude is producing or evaluating engineering work, this skill applies — even for small tasks like writing a helper function or fixing a bug. This skill changes how Claude thinks, not what it delivers. For a structured deep review with findings and classifications, use the /expert-review command instead.
How this skill is triggered — by the user, by Claude, or both
Slash command
/agentboard:expert-standardsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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.
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.
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.
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.
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.
npx claudepluginhub maxcogar/agent-armory --plugin agentboardCreates bite-sized, testable implementation plans from specs or requirements, with file structure and task decomposition. Activates before coding multi-step tasks.