AIO Test Case Creator.
An LLM skill that takes a manual test-case draft and outputs a publish-ready entry for the AIO test pool. Title format, preconditions, step grammar, expected results, variables, tags — normalized against a 1,891-case rulebook before anything reaches the suite.
Manual test cases were inconsistent. The pool became un-queryable.
1,891 test cases. Six engineers writing them. Three years of accumulated drift. The result was a test pool you couldn't query — the tag eSIM sometimes meant SIM type, sometimes meant flow, sometimes was missing entirely. Step format varied case-by-case. Variables were sometimes $EMAIL_ID, sometimes $email, sometimes literal "testuser@example.com".
That cost us in two ways:
- Manual QA couldn't filter to "show me everything that touches checkout on Family Line" without reading 200 titles.
- Automation engineers couldn't reliably pull a case from the pool and execute it without a 10-minute "what does this even mean" review.
Two incidents in 2025 made this concrete: a batch-update script silently dropped data fields from 14 cases (TC-18 incident), and another lost jiraRequirementIDs on 9 cases (TC-16). The cost wasn't the bug — it was the fact that nobody noticed for three weeks.
Codify the rules. Run drafts through an LLM that knows them.
I wrote a 1,658-line Test Case Writing Guidelines v2.0 derived from MVNE-TC-1 and a full sweep of the existing 1,891 cases. That document is the system prompt for the skill — every rule that ever bit us is in there, with examples.
Then I wrapped it in an LLM skill that does five things in sequence on any draft:
-
Validate critical fields
If the draft is missing
jiraRequirementIDs,data, orjiraComponentIDswhen it shouldn't be, reject before normalizing. -
Normalize the title
Strip redundant tags. Add
[Page Name]for atomic,[Flow][Line][SIM]for flows. Drop default-implied tags (Single Line, Owner, eSIM only if it's not the differentiator). -
Rewrite preconditions to the structured format
Force
State:,Flow Complete:, line config,$URLvariables. pSIM cases get an explicit line spec. -
Fix step grammar
UI elements in
"double quotes". Variables in$CAPS. Action verbs (Click, Enter, Select). One action per step — split combined ones. "Navigates to" not "redirects to." -
Tag and categorize
Set
Case Category,Type,Priorityfrom the decision tree. Output 3–10 search-friendly tags. Choose folder path from the canonical hierarchy. -
Diff & explain
Output what changed and why. The QA author approves before publish — the skill is an assistant, not an autonomous editor.
A real draft, normalized.
Title: Buy eSIM Description: Test buy flow Pre-condition: User on home page Steps: 1. Go to home 2. Click buy plan 3. Enter all info: name, email, zip 4. Submit the form Expected Result: 1. Page loads 2. Goes to plans 3. Info entered 4. Order placed and success and dashboard Tags: test,flow,esim Case Category: Flow Priority: Critical
Title: [Buy Flow][Single Line] User can buy an eSIM Description: Verify that the user is able to buy an eSIM with Single Line Pre-condition: State: User is on $URL Steps: 1. Navigate to Home Page 2. Click "Buy a Plan" button 3. Enter $EMAIL_ID in "Email Address" field 4. Enter $ZIP_CODE in "ZIP Code" field 5. Click "Submit Order" button Expected Result: 1. User is redirected to $URL/ page 2. User navigates to $URL/plans page 3. $EMAIL_ID is populated in "Email Address" field 4. $ZIP_CODE is populated in "ZIP Code" field 5. "Order Confirmation" page is displayed Tags: Buy Flow,eSIM,Single Line,New Number Case Category: Flow Type: Positive Priority: Critical Line: Single Line Folder: SmartlessMobile - Web -> Flows -> BuyFlow -> eSIM -> Single Line
Every rule has an origin story.
The skill's rulebook isn't an abstract style guide. Each rule traces back to a real production incident.
data fields from 14 cases. The skill now refuses to output a step that has $VARIABLES without a matching data entry.
jiraRequirementIDs is in the validation pre-flight; if it's there on input, it's there on output.
Line: Single Line | pSIM | Not Activated when SIM is non-default.
16 fields normalized in one pass.
One command from anywhere.
// from Jira ticket, Slack, or the AIO browser extension /aio-tcc normalize > reading draft from clipboard... > validating critical fields... PASS > normalizing title... applied 2 rules > rewriting preconditions... applied 3 rules > fixing step grammar... applied 9 rules, split 1 combined step > categorizing & tagging... Flow / Positive / Critical > selecting folder... SmartlessMobile - Web -> Flows -> BuyFlow -> eSIM -> Single Line > diff ready · review at: aio.lotusflare.internal/draft/MVNE-TC-1893 ✓ ready to publish
How it's wired.
jiraRequirementIDs, data, jiraComponentIDs before any normalization runs. Missing required fields → reject with a clear error. Prevents silent data loss (TC-16/TC-18 incidents).
$CAPS), step atomicity verified, tags de-duped, folder path resolved from the canonical hierarchy.
Status: Draft and go through the standard AIO review flow before promotion to the live suite. Full traceability preserved.