Assumption-first planning and design gap analysis. Use when user is in PLANNING mode, explicitly asks to plan or discuss, asks for a gap analysis / design review / stress-test of a spec or design document, or when agent faces open decisions — including headless tasks where the deliverable is proposals and open questions as files. Instead of interrogating the user, the agent proposes concrete tagged answers in small verify-style rounds (or directly in the output documents when no user is in the loop), surfaces contradictions as questions, and asks only the questions that genuinely fork the design.
78
91%
Does it follow best practices?
Impact
56%
1.05xAverage score across 1 eval scenario
Passed
No known issues
The engineering team has drafted a design document for the Notification Delivery System — a service that fans out event-driven notifications across email, push, and SMS channels using Kafka, third-party adapters, and a Postgres delivery ledger.
The design covers the happy path in detail, but before the team commits to implementation a senior reviewer has flagged that the document is underspecified in places. The reviewer wants a thorough gap analysis carried out on the design before any code is written. This means working through the cases the happy-path narrative skips over — unusual inputs, failures, timing edge cases — and producing concrete proposals to fill the gaps, along with a record of anything that needs the team to weigh in before it can be resolved.
The design file is at inputs/system-design.md. The inputs/ directory also contains other project records.
Produce three output files:
stress-test-scenarios.md — A document listing at least 4 specific scenarios you worked through to probe the design. For each one, describe what happens using the actual components from the design and identify where the design leaves the behavior unspecified or where two parts of the design give conflicting answers.
gap-proposals.md — Concrete proposals to fill the gaps you found. Each proposal should say exactly what the system will do — not general intentions. Include any notes on how proposals relate to each other.
open-questions.md — Gaps that cannot be resolved without a team decision. Keep entries brief — one line per item.