---
name: consistency-critique
description: "Compare two or more analogous operational web-app modules to find structural capability drift, identify an evidence-based golden path, and define a coherent target contract and migration sequence. Use when the user explicitly invokes $consistency-critique; explicit invocation is required. Do not invoke when the request is for marketing, e-commerce, editorial, a single-feature audit, implementation, visual taste critique, generic code review, or refactoring without product-behavior comparison."
license: MIT
disable-model-invocation: true
---

# Consistency Critique

**Explicit invocation only.** Continue only when the user invoked this skill through the client's native explicit syntax, such as `$consistency-critique`, `/consistency-critique`, or a namespaced plugin command. Otherwise stop and explain that this broad read-only comparison must be requested explicitly.

Compare analogous modules by user capability and system behavior, not superficial component similarity.

## Boundaries

- Require at least two meaningfully analogous modules or resources. With only one, stop and recommend `$completeness-audit` when that skill is available.
- Limit v0.1 to operational apps such as admin systems, CRMs, internal tools, and SaaS operations; do not compare marketing, e-commerce, or editorial product design with this catalog.
- Remain read-only. Produce a target standard and migration plan, never the refactor itself.
- Report in chat. Write an artifact only when the user explicitly asks for one.
- Preserve intentional domain differences. Consistency is valuable only where actors, risks, scale, and tasks are genuinely comparable.
- Browser use is optional. Mark unobserved rendered differences `manual-review`.

## Load the right guidance

Read [the capability catalog](references/capability-catalog.md), [the evidence model](references/evidence-model.md), and [the comparison contract](references/comparison-report.md). If the modules use React, Next.js, shadcn/ui, TanStack Table, tRPC, or Prisma, also read [the React/Next comparison reference](references/react-next.md).

## Workflow

1. **Define comparability.** Name the modules, shared jobs, actors, data-shape differences, scale, risks, and boundaries. Exclude differences justified by domain semantics.
2. **Collect equivalent evidence.** Trace the same capability areas in every module from UI entry point through data and authorization boundaries. Do not compare one module's rendered screen with another module's server code.
3. **Use bounded delegation only when useful.** For a broad comparison and when subagents are available, use 2-4 read-only subagents with exclusive module or capability ownership. Prohibit nested delegation, give every agent the same evidence schema, and normalize results centrally. Otherwise compare in one agent.
4. **Build the capability matrix.** Require positive evidence that a capability applies to the compared jobs before it enters the matrix. Use `covered`, `confirmed-gap`, or `manual-review` for each applicable module/capability cell. Keep unmet catalog triggers out of the matrix; record only exclusions that explain an apparent drift or prevent a concrete scope mistake. Give every confirmed finding a rule ID, severity, confidence, file/line evidence, impact, authority, recommendation, and verification path.
5. **Identify the golden path.** Select the strongest evidenced existing pattern, not automatically the newest or largest module. If no module is sound end to end, define a composite target and say so.
6. **Explain structural causes.** Distinguish one-off omissions from causes such as divergent query contracts, duplicated resource shells, scattered state ownership, inconsistent permission boundaries, or missing shared primitives.
7. **Define the target contract.** Use `present`, `include`, `defer`, `not-applicable`, and `needs-decision`. Preserve the collection invariant:

   `displayed rows = paginate(sort(filter(complete reachable dataset)))`

8. **Sequence migration batches.** Order real changes by correctness/security risk, dependency, user value, and rollout safety. Give observable exit criteria and regression boundaries. When no migration is justified, say so and emit no no-op batch. Do not implement a batch without a separate approved build request.

## Exit conditions

Finish with a normalized capability matrix, a defensible golden path or explicit composite target, evidence-backed root causes, a target contract, prioritized migration batches, and named `manual-review` scenarios.