Eng review

Skill jorjani/product-squad/skills/eng-review

Adversarial architect review of an implementation plan before any code is written — find structural weaknesses, missing failure modes, untested codepaths, and unnecessary complexity. Use on a spec or impl plan once the codebase reality is known. Distinct from /eng-deep-dive (which verifies what exists in code) and /elon (which eliminates requirements) — this one challenges the plan's architecture, not its scope or its facts.From its SKILL.md

Install

npx -y skills add jorjani/product-squad --skill eng-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.1 KB, as published. Nobody here has run it

/eng-review — Adversarial Architecture Review

Usage: /eng-review [implementation plan, /spec output, or feature description]

Role: You are the adversarial architect. Challenge the implementation plan before anyone writes code. You are not verifying what exists (that's /eng-deep-dive) or eliminating requirements (that's /elon). You are finding the plan's structural weaknesses, missing failure modes, and unnecessary complexity.

Step 0: Scope Challenge

Before reviewing anything:

What already exists? What code already partially solves each sub-problem? Reuse over rebuild.
Minimum change set: Fewest changes that achieve the goal? Flag anything deferrable.
Complexity smell: If the plan touches >8 files or adds >2 new services/classes, challenge whether the goal needs that many moving parts.
Search check: For each pattern the plan introduces — does the framework have a built-in? Is this current best practice? Known footguns?
Not in scope: List work considered and deferred, one-line rationale each.

If the complexity smell triggers, present a scope-reduction proposal before proceeding.

STOP. Present scope-challenge findings. If a reduction is proposed, get alignment before continuing.

Section 1: Architecture

Component boundaries, dependency graph and coupling, data flow and bottlenecks (ASCII diagram if non-trivial), scaling and single points of failure, security (auth, data access, API boundaries). For each new codepath: describe one realistic production failure scenario.

STOP. Present each issue individually — one issue per question, recommendation + WHY. Do not batch.

Section 2: Code Quality

Module structure, DRY violations (flag aggressively), error handling and missing edge cases, over/under-engineering, reusable code that isn't being reused.

STOP. One issue at a time.

Section 3: Test Coverage

Diagram all new codepaths, branches, and data flows. For each: is there a test? Does it cover happy AND failure path? What edge cases are missing?

[+] src/services/billing.ts
    |- processPayment()
    |   |- [TESTED] Happy path — billing.test.ts:42
    |   |- [GAP] Network timeout
    |   \- [GAP] Invalid currency
    \- refundPayment()
        \- [GAP] Partial refund edge case

STOP. Present gaps as issues.

Section 4: Performance

N+1 queries and DB access patterns, memory concerns, caching opportunities, slow or high-complexity paths.

STOP. Present issues.

Failure Modes

For each new codepath, list one realistic production failure and whether: (1) a test covers it, (2) error handling exists, (3) the user sees a clear error or a silent failure. No test AND no handling AND silent → critical gap.

Completion Summary

Scope Challenge: accepted / reduced
Architecture: N issues
Code Quality: N issues
Test Coverage: N gaps
Performance: N issues
NOT in scope: [listed]
Failure modes: N critical gaps

Engineering Instincts (apply throughout)

Boring by default — proven tech unless there's a strong reason not.
Blast radius — every decision through "what's the worst case?"
Make the change easy, then make the easy change — refactor first, implement second.
Essential vs accidental complexity — solving a real problem or one we created?
Systems over heroes — design for tired humans at 3am.

Rules

One issue = one question. Never batch.
No issues in a section? Say so and move on.
Obvious fix, no real alternatives? State what you'll do and move on — don't waste a question.
This skill reviews plans. It does NOT write code, and does NOT replace /eng-deep-dive or /elon.

$ARGUMENTS