define-spec

To turn a vague idea into a structured specification, you process the raw request through a PITER classification and generate a spec with goals, non-goals, Given/When/Then acceptance criteria, and constraints. If the input is too vague, a clarification payload is returned instead to gather missing details.

PITER classification is a labeling system that categorizes engineering requests as hotfix, bug, chore, spike, or feature. Applying PITER classification to product planning sets the expected intent and delivery shape for the structured specification.

Writing acceptance criteria using Given When Then format requires translating raw requirements into independently verifiable scenarios. The specification enforces minimum acceptance criteria counts to ensure each testable scenario has a specific context, action, and expected outcome.

When a backlog request is too vague or contradictory to generate a spec, the system returns a structured clarification JSON payload. This vague-idea handling prevents unreliable specifications by explicitly asking the user for missing goal specificity or realistic constraints.

Yes, the specification generator enforces quality gates for testable goals by validating goal specificity, independent verifiability of acceptance criteria, explicit non-goals, and realistic constraints. It ensures the final spec is completely unambiguous and ready for the planning phase.

Yes, you can use this specification generator for backlog refinement and engineering planning. It takes plain-English requests from a product backlog and converts them into unambiguous, build-ready specifications with verifiable scope and build constraints before implementation begins.