adversarial-ts-patterns

Adversarial TS Patterns Gate

A design-pattern usage gate for TypeScript and React application code — a pass/fail gate: a single blind reviewer subagent judges the work against this gate's rules with an adversarial mandate, and the work passes only when every rule is PASS or N/A. This skill renders verdicts; it never fixes the work.

The gate judges in both directions. Over-abstraction — Gang of Four and enterprise machinery ported from Java/C# where idiomatic TypeScript reaches for a function, a module, or a tagged union. Under-modeling — implicit state machines whose impossible states compile: boolean-flag lifecycles, effect chains, hand-synced derived state, silent default branches.

When to Apply

• A TypeScript/React diff or feature is about to merge and needs an objective PASS/FAIL on pattern usage, not advisory feedback.
• An agent (Claude, Codex) authored the code and you want an independent check that it is not reproducing Java/C# training-data idioms — Singleton classes, factory hierarchies, repository wrappers, JavaBean accessors.
• A migration from another stack (Java, C#, Angular-style DI) claims completion and the ported architecture needs auditing for layers that lost their justification in TypeScript.
• Component or store state grew organically and you want the implicit-state-machine failure modes (contradictory booleans, effect chains, non-exhaustive matches) caught before they ship.

Do not apply to non-TypeScript codebases (the reviewer prompt's precondition aborts with "GATE NOT APPLICABLE"), or when the user wants explanations and refactors rather than a verdict — that is the job of the curated implementation-design-patterns and implementation-functional-patterns skills. React-specific rules go N/A in non-React TypeScript projects; the rest of the gate works in any TypeScript application.

Review Protocol

Follow these steps exactly — the gate's value is that every review runs the same way.

1. Identify the target. Pin down exactly what is under review (a diff, a set of files, a PR) and note the ref/paths so the review runs against an unambiguous, fixed target. Include the repo root in the target description — the layer-no-single-impl-interface and layer-no-di-container-in-app rules require searching beyond the diff for second implementations and registrations.
2. Load the rules. Read references/_sections.md and every rule file in references/ (all state-*.md, create-*.md, behave-*.md, layer-*.md, react-*.md, oo-*.md files).
3. Compose the reviewer prompt. Fill references/reviewer-prompt.md with the rules and the target. The composed prompt must be fully self-contained — a reviewer sees no conversation history, so nothing may refer to context outside the prompt.
4. Dispatch one blind reviewer. Launch a single Task subagent whose entire input is the composed prompt — no conversation context, no commentary alongside it.
5. Render fail-closed. The reviewer's structured output is the verdict — there is no merge step. Overall verdict is PASS only when every rule is PASS or N/A; any single FAIL fails the gate. Never average, weigh severity, or waive a rule — a "minor" FAIL is a FAIL. If the reviewer returns "GATE NOT APPLICABLE" (not a TypeScript target), stop and report that instead of a verdict.
6. Render the verdict. Fill assets/templates/verdict.md. On FAIL, aggregate the reviewer's "missing for PASS" suggestions into the fix list, each with its location, ordered by category importance. Every rule whose final result is FAIL must appear in the fix list with a change concrete enough to apply as written — if the reviewer's suggestion only restates the violation, derive the fix from the rule's Correct example before rendering.