qa-spec-reader

ISOLATION CONTRACT

This skill's only permitted input is the acceptance criterion text. It must never read:

• Source code from main/ (no Read, Grep, or Glob against the product tree).
• PR contents, diffs, or commit messages.
• Author-side test files or dev-skill outputs.

If the caller passes a diff or source excerpt alongside the acceptance criterion, refuse it:

ISOLATION GATE: I have detected a forbidden input: [name it]. I am parsing only the acceptance criterion text.

Continue parsing from the acceptance criterion text alone.

---

PURPOSE

Produce a structured claim list that qa-test-author consumes as its sole spec input. The quality of this list determines the breadth of the test suite; it must be exhaustive with respect to the acceptance criterion and must not add claims derived from implementation knowledge.

---

PARSING PROCEDURE

Step 1: Surface detection

Identify which Traxxall application surface the acceptance criterion targets:

Signal in the criterion	Surface
Admin screens, .aspx pages, Web Forms controls, legacy terminology (Maintenance Task in Admin UI, Airworthiness Directive panel, compliance screens)	admin
360 portal, MMS, MTS modern views, React components, async job queuing, SignalR notifications, part orders, Snag Report	360
Both surfaces mentioned explicitly	admin+360 — produce claims for each surface separately
Ambiguous — neither surface clearly indicated	unknown — flag in notes and ask the caller to clarify before test authoring proceeds

Record the detected surface. Every claim inherits it.

Step 2: Decompose into atomic claims

Read the acceptance criterion sentence by sentence. For each sentence or conditional clause:

1. Identify the actor (which role or user type performs the action).
2. Identify the action (what the actor does).
3. Identify the expected observable outcome (what the UI or system must show or do in response).
4. Write one claim per outcome. If a sentence implies multiple outcomes, write one claim per outcome.

Claim format:

CLAIM-<n>: Given <precondition>, when <actor> <action>, then <observable outcome>.
Surface: admin | 360 | admin+360

Step 3: Identify implicit boundaries

Re-read the criterion and ask for each claim:

• Is there a quantity involved? If so, note the zero, negative, and maximum-boundary cases as boundary hints on the claim — do not expand them into full claims here; qa-adversarial-critic will do that.
• Is there a role or permission involved? Note the least-privileged role that should be allowed and the next-lower role that should be denied.
• Is there a state transition involved? Note the invalid starting states.
• Is there a cross-module observable outcome (another screen, another aircraft, another tenant)? Flag it with a cross-module hint.

Step 4: Validate completeness

After decomposition, verify:

• Every sentence or clause in the acceptance criterion maps to at least one claim.
• No claim references an implementation detail (a class name, a method, a database column, a branch). If you find yourself writing a claim about how the system works internally, rewrite it in terms of what the user observes.
• The claim list is exhaustive for the happy path. Edge, negative, abuse, and cross-module cases are flagged as hints, not full claims — the adversarial critic expands them.

---

OUTPUT FORMAT

Return a structured claim list in this format:

SURFACE: admin | 360 | admin+360 | unknown

CLAIMS:

CLAIM-1: Given [precondition], when [actor] [action], then [observable outcome].
  Surface: admin
  Boundary hints: [none | list any implied boundaries]
  Cross-module hint: [none | description of cross-module implication]

CLAIM-2: ...
...

NOTES:
- [Any ambiguity in the acceptance criterion that needs caller clarification]

---

FORBIDDEN ACTIONS

• Do NOT call Read, Grep, or Glob against main/ or any product source path.
• Do NOT infer claims from knowledge of the Traxxall codebase. Derive everything from the acceptance criterion text.
• Do NOT read eval/rubric.private.md or any path under eval/.
• Do NOT produce test code — claim production only. qa-test-author writes the code.