Product

External / Ask review

Define behavioral specifications and acceptance criteria

Hats
2
Review Agents
2
Review
External, ask
Unit Types
Product
Inputs
Inception, Design, Design

Dependencies

Inceptiondiscovery
Designdesign-brief
Designdesign-tokens

Hat Sequence

1

Product Owner

Focus: Define user stories, prioritize features, make scope decisions, and specify acceptance criteria from the user's perspective. Think in terms of what users do and see, not how the system implements it.

Produces: Prioritized user stories with acceptance criteria, each testable via a specific scenario.

Reads: discovery and design-tokens via the unit's ## References section.

Anti-patterns (RFC 2119):

  • The agent MUST NOT write implementation details instead of user behavior ("use a Redis cache" vs. "page loads in under 2 seconds")
  • The agent MUST NOT skip edge cases and error scenarios
  • The agent MUST define what "done" looks like from the user's perspective
  • The agent MUST NOT prioritize by implementation ease instead of user value
  • The agent MUST NOT write acceptance criteria that cannot be verified with a test
2

Specification Writer

Focus: Write behavioral specs (given/when/then), define data contracts (API schemas, database models), and specify API contracts (endpoints, methods, request/response shapes). Precision matters — ambiguity in specs becomes bugs in code.

Produces: Behavioral specification and data contracts.

Reads: Product owner's stories, discovery via the unit's ## References section.

Anti-patterns (RFC 2119):

  • The agent MUST NOT write specs that describe implementation rather than behavior
  • The agent MUST NOT leave contracts ambiguous ("returns data" instead of specifying the schema)
  • The agent MUST specify error responses alongside success responses
  • The agent MUST NOT define happy path only without error scenarios
  • The agent MUST NOT use inconsistent naming between spec and data contracts

Review Agents

Completeness

Mandate: The agent MUST verify behavioral specifications and data contracts fully cover the intent with no ambiguous or missing scenarios.

Check:

  • The agent MUST verify that every user-facing flow has defined happy path, error states, and edge cases
  • The agent MUST verify that data contracts specify all fields, types, nullability, and validation rules
  • The agent MUST verify that acceptance criteria are specific enough to write tests against — no subjective judgments
  • The agent MUST verify that no feature described in the intent is missing from the behavioral spec

Feasibility

Mandate: The agent MUST challenge whether the specified behavior is implementable within the technical constraints.

Check:

  • The agent MUST verify that specified response times and performance targets are realistic given the data model and infrastructure
  • The agent MUST verify that data contracts are compatible with existing schemas (no breaking changes without migration plan)
  • The agent MUST verify that edge cases have defined behavior, not just "handle gracefully"
  • The agent MUST verify that no specification assumes capabilities that would require unreasonable effort to build

Product

Criteria Guidance

Good criteria examples:

  • "Behavioral spec covers happy path and at least 3 error scenarios per user flow"
  • "Data contracts define request/response schemas with field types, required/optional, and validation rules"
  • "Each acceptance criterion is testable with a specific scenario (Given X, When Y, Then Z)"

Bad criteria examples:

  • "Specs are written"
  • "API is specified"
  • "Criteria are clear"

Completion Signal (RFC 2119)

Behavioral spec MUST exist with user flows and error scenarios. Data contracts MUST define all API schemas with field types and validation rules. Every acceptance criterion MUST have a testable given/when/then scenario. Product owner MUST have approved scope.