Passed 22 of 22 test cases with the skill, and 18 of 22 without it.
Without skill82%
With skill100%
Checks it passed that the model alone missed
Requires applying the 5 Whys analysis to determine the root cause before implementing a fix.
Specifies the 3-stage impact analysis procedure composed of Discovery, Understanding, and Identification.
Mandates using the unknown type paired with type guards instead of type assertions like as or the any type.
and 6 more in the full report
4 fixed18 passed either way0 still failing0 broke
Pass-rate lift
+18 pp
Tokens
+77%
Agent turns
0%
Response time
-23%
Model gemini-3.6-flashMeasured 8/18/2026v222 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
We are integrating an experimental web frontend library into our React app and want to establish proper error handling and impact verification before writing code. Please provide a technical design and impact analysis checklist for this integration. The checklist should detail how to handle implementation uncertainty, structure type safety and error fallbacks, and outline the necessary quality check workflow.
What was checked, without and with the skill
Checked
Without skill
With skill
Requires recording certainty metadata including low certainty, exploratory implementation status, and fallback patterns prior to writing implementation code.
Missed
Passed
Directs non-rendering callback or effect operations to be caught at their owning hook, event, or server boundary rather than using React Error Boundaries.
Missed
Passed
Mandates using the unknown type paired with type guards instead of type assertions like as or the any type.
Missed
Passed
Structures the quality check workflow using exactly lint/format, type check, build, and behavior checks as the applicable check categories.
Missed
Passed
case-01 · gemini-3.6-flash · 8/18/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md178 linessingle file
AI Developer Guide - Technical Decision Criteria and Anti-pattern Collection (Frontend)
Value-First Engineering
Explore broadly, then converge on the lowest-lifecycle-cost solution that delivers the required user or maintainer value while keeping the UI correct and maintainable.
Resolve verified problems within confirmed scope or dependencies required for the outcome; report other findings with evidence for a scope decision.
Introduce state, props, variants, abstractions, or speculative edge-case handling when a current outcome, verified constraint, or evidence-backed material risk requires them.
Treat behavior-preserving maintenance inside the confirmed responsibility as current maintainer value when repository evidence shows it reduces change ambiguity, duplicate ownership, defect risk, or future implementation and verification cost without expanding observable product scope.
Technical Anti-patterns (Red Flag Patterns)
Pause the affected decision and review the design when detecting the following patterns:
Code Quality Anti-patterns
Duplicating one UI responsibility across independently maintained components - Review whether the duplicated behavior or contract should have one owner
Multiple responsibilities mixed in a single component - Violates Single Responsibility Principle (SRP)
Defining same content in multiple components - Violates DRY principle
Making changes without checking dependencies - Potential for unexpected impacts
Disabling code with comments - Should use version control
Excessive use of type assertions (as) - Abandoning type safety
Pass-through prop chains that obscure state ownership - Use composition, Context, or the project's state layer when intermediate components only forward values and a broader owner is clearer; retain explicit props when they preserve local ownership and broader state ownership would add coordination while responsibility remains local
Components mixing independently changing responsibilities - Split when rendering, state/data ownership, or reusable/testable behavior forms an independent responsibility; retain cohesive components when splitting would add avoidable prop/state synchronization
Design Anti-patterns
"Make it work for now" thinking - Accumulation of technical debt
Patchwork implementation - Unplanned additions to existing components
Optimistic implementation of uncertain technology - Designing unknown elements assuming "it'll probably work"
Symptomatic fixes - Surface-level fixes that don't solve root causes
Unplanned large-scale changes - Lack of incremental approach
Fallback Design Principles
Core Principle: Fail-Fast
Design philosophy that prioritizes improving primary code reliability over fallback implementations.
Criteria for Fallback Implementation
Fallback rule: Implement a fallback when an accepted requirement, boundary contract, project policy, or Design Doc defines the degraded outcome and recovery owner
Layer Responsibilities:
Rendering failure in a child component subtree, including a hook that throws during render: Use the project's Error Boundary