Requirement Specification

To turn vague feature requests into testable acceptance criteria, you apply Socratic questioning to surface hidden assumptions and structure them into Given-When-Then specifications. This captures scope, edge cases, and non-functional requirements during the planning stage.

The Given-When-Then format structures requirement specifications by defining a precondition (Given), an action (When), and an expected outcome (Then). It is used to transform ambiguous user requests into precise, testable criteria for software development tasks.

To identify hidden assumptions and edge cases during feature planning, generate targeted clarification questions using Socratic questioning. This surfaces implicit expectations early, preventing costly misunderstandings before they propagate downstream in the development cycle.

Yes, you can use structured specifications to feed downstream software development agents like Worker or Inspector. Providing clear Given-When-Then specifications enables reliable task decomposition and quality gating for automated development workflows.

You need to write acceptance criteria for non-functional requirements whenever a feature involves scope, dependencies, or constraints like rate limiting. Capturing these alongside functional edge cases ensures downstream agents receive a complete, testable specification.