Assertion Expander
Augments thin Gherkin Then-clauses with the additional assertions implied by the requirement: response codes, side-effects, audit log entries, downstream events.
When this skill fires
·A scenario's Then clause is suspiciously short (one or two assertions on what looks like a multi-side-effect operation)
·An engineer asks: "what else should this scenario check?"
·Step Definition Generator sees a Then that doesn't cover all the contracts in the requirement
What gets expanded
For an action like"the user submits the login form", the requirement implies:
·HTTP status code (200 on success, 401 on failure)
·Session token issuance
·failed_attempts counter increment on failure
·Audit log entry (user.login.success or user.login.failure)
·Downstream event emitted to the analytics pipeline
·Email notification on lockout
A thin Gherkin spec might only cover the first one or two.Assertion Expander adds the rest.
Sources of truth
The expander draws on three sources, in priority order:
1. The requirement text itself — anything explicitly stated must be asserted
2. The intent graph fromRequirement Parser — every "side effect" becomes an assertion
3. Domain priors — for known domains (auth, payments), the expander knows the canonical assertion set
Conservative by default
→The expander never adds assertions that aren't grounded in one of the three sources. It will not invent assertions just to pad the test.
If a thin Then clause turns out to be intentional ("we don't care about audit logs in this scenario"), the engineer can mark it @thin and the expander will skip it.
What it produces
An updated Gherkin scenario with additional And clauses:
`Then the response status is 200`
`And a session token is issued`
`And the user.login.success audit event is recorded`
`And the analytics login event is emitted within 100ms`
`And the failed_attempts counter is reset to 0`
Each new assertion is annotated with its source (requirement / intent-graph / domain-prior) so the engineer can review the reasoning.
Example: from thin to complete
Before:
`Then the user is logged in`
After:
`Then the response status is 200 [requirement]`
`And a session token is issued in an HttpOnly cookie [domain-prior:auth]`
`And the user.login.success audit event includes the source IP [requirement]`
`And the failed_attempts counter for the account is reset to 0 [intent-graph]`