Engineering Philosophy Adversarial Review
Pressure-test PRs through contrasting engineering philosophies, with evidence-backed findings and a prioritized pre-merge fix list.
Before & after
Same prompt, same agent — the only difference is the skill.
I can do a code review for you. To give you helpful feedback, I'd want to know a bit more about what the middleware does, what tests you have in place, and whether there are any particular concerns you have about it. Are we talking about authentication, authorization, or both? What's the threat model? Have you tested for timing attacks or token validation edge cases? I could walk through it section by section and look for common vulnerabilities, but knowing your specific context would help me focus on the most important risks.
AUTH MIDDLEWARE REVIEW — MULTIPLE PERSPECTIVES
TORVALDS VIEW: Simplicity & Correctness
• Concern: 1,200 lines for middleware (signal: can be halved)
• Verdict: Extract token validation into separate 80-line module
• Question: Why is session state stored in memory? Recovery after crash loses all sessions.
• Recommendation: Serialize to Redis with 1-hour TTL, test cold-start behavior
CARMACK VIEW: Performance & Architecture
• Concern: Token validation runs on every request, no caching
• Verdict: Cache valid tokens for 5 minutes, validate once per batch
• Finding: Timing vulnerability in string comparison (==, not constant-time)
• Impact: Attackers can brute-force tokens character-by-character
JOBS VIEW: User Experience
• Concern: Error messages are overly technical
• Verdict: Replace "JWT decode failed" with "Sign in again" for expired tokens
• Finding: No graceful fallback for downstream service timeout
• Recommendation: Allow "guest" mode if auth service is down (configurable)
BECK VIEW: Testing & Maintainability
• Concern: 0 edge case tests (what if token has no exp field?)
• Verdict: Add test matrix: expired, invalid_signature, missing_claims
• Gap: No test for refresh token rotation after 30 days
REPRO SCRIPT (Run to confirm issues)
```bash
Brute-force timing: time for token in {AAA,AAB,AAC...}; time curl -H "Auth: $token"
```
SHIP BLOCKERS: 2 Critical
1. Timing attack fix (regex to constant-time comparison)
2. Session recovery (add Redis layer)
Suggested: Test both fixes in staging, deploy with feature flagAbout this skill
Your automated review keeps saying "add tests" and "handle errors," but the difficult questions remain: does this abstraction earn its cost, can this state become inconsistent, and will users notice the improvement? This review applies contrasting engineering philosophies to the same change, then turns their strongest objections into specific fixes and explicit tradeoffs.
What it does
- Selects two to four relevant philosophies, such as explicit ownership, minimal mechanisms, measured performance, incremental design, and coherent product behavior.
- Grounds philosophical claims in supplied or verified source material, labeling unsourced interpretations as provisional heuristics.
- Traces failure schedules across concurrent access, partial failures, retries, invalidation, and cleanup.
- Challenges new abstractions and performance claims against simpler alternatives and the actual user requirement.
- Separates defects from conditional risks and architectural preferences, with evidence and a discriminating test for each material objection.
- Resolves disagreements into one or two priority changes, including what evidence would justify keeping the current design.
What you get
A scoped review with code-linked findings, concrete failure scenarios, competing recommendations, and a prioritized pre-merge decision. Quick questions receive a focused answer; larger changes receive the full review.
Best for
Developers and technical leads hardening PRs that change shared state, API behavior, architecture, performance, or user experience after routine review has stopped finding useful issues.
SKILL.md preview
---
name: engineering-philosophy-adversarial-review
description: >-
Pressure-tests code and design changes through contrasting engineering philosophies, grounding each lens in available source material and each finding in a concrete failure scenario or explicit tradeoff. Use when the user says "review this through different engineering philosophies", "my automated reviews keep giving generic advice", "pressure-test this architecture", "what would a simplicity-first reviewer object to?", "harden this PR before I submit it", "challenge this caching design", or "our reviewers disagree about this abstraction".
---
# Engineering Philosophy Adversarial Review
… (sign up to view the full skill)More development skills
View all Development skills →Performance Bottleneck Profiling: Node, Python, Go
Classifies a slowdown, gives exact profiler commands, reads the output, and proves the fix with same-conditions p95/p99 numbers.
Feature Scaffolding with Working Tests
Turn a short feature spec into code, runnable tests, and integration wiring that match your existing project.
Feature Flag Rollouts and Kill Switches
Design staged flag rollouts, verify rollback paths, and audit flag debt with explicit defaults, gates, and retirement plans.
Microcontroller Firmware and RTOS Engineering
Build and debug MCU firmware with bounded ISR/RTOS timing, safe DMA ownership, and measured power budgets.