| name | input-sources |
| description | Multi-source input handling for manual test case generation. Use when the input is NOT a Jira Story ID — covers User Stories, Business Flows/Processes, Use Cases, and REST API endpoint specifications. Covers input type detection, requirements extraction, reference ID generation, and test derivation rules for each source type. |
| user-invocable | false |
Input Sources Reference
Step 0: Input Type Detection
Before any other step, classify the user's input as one of:
| Input Type | Detection Signal |
|---|
| Jira Story | Alphanumeric ID matching pattern [A-Z]+-\d+ (e.g., PS-12345, PROJ-99) |
| User Story | Contains "As a [role], I want to [action]" or "As a [role] I can [action]" |
| Business Flow | Step-by-step process description: numbered steps, swimlane descriptions, process narratives |
| Use Case | Structured with Actor, Preconditions, Main Flow, Alternative Flows, Exceptions |
| API Specification | Contains HTTP method (GET/POST/PUT/PATCH/DELETE), endpoint path, request/response schema or payload |
| Mixed / Freeform | Combination of above, or plain description of a feature/requirement |
If ambiguous, ask the user: "Is this a Jira Story ID, User Story, Business Flow, Use Case, or API Specification? Or paste all context and I will classify it."
Reference ID Generation (Non-Jira Sources)
Since there is no Jira key, derive a reference ID for artifact paths and test case IDs:
| Source Type | Reference ID Pattern | Example |
|---|
| User Story | US-<slug> (2-4 word slug from title) | US-EMPLOYEE-EXPORT |
| Business Flow | BF-<slug> | BF-ORDER-CHECKOUT |
| Use Case | UC-<slug> | UC-LOGIN-FLOW |
| API Endpoint | API-<METHOD>-<resource> | API-POST-PAYMENTS |
| Freeform | FT-<slug> | FT-SEARCH-FILTER |
Slug rules: uppercase, hyphens only, max 3 segments, derived from the feature name.
Source-Specific Extraction Rules
1. User Story
Format: As a [role], I want to [action] so that [benefit]
Extract:
- Actor: the role (Admin, Employee, Guest, API Consumer...)
- Goal: the action they want to perform
- Value: the benefit/reason
- Implicit ACs: derive from the goal — every distinct outcome the user expects constitutes an implicit acceptance criterion
Test Derivation:
- Positive: User completes the action successfully
- Negative: User lacks permission, provides invalid input, or prerequisites are unmet
- Boundary: Apply BVA/EP to any quantities, limits, or field constraints implied by the story
- Edge: Multiple roles, concurrent actions, empty states
Example:
"As an Admin, I want to export employee history as a CSV so that I can archive records"
Implicit ACs → export triggers download, file is valid CSV, contains all expected fields, handles 0 records, handles large datasets.
2. Business Flow / Process
Format: Numbered steps, swimlane descriptions, or process narratives describing how a system or business process works.
Extract:
- Entry Point: What triggers the flow
- Steps: Each step is a potential state or transition → test case candidate
- Branch Points: Decision nodes (if/else, approval/rejection) → test for each branch
- Exit Points: Normal completion, error termination, timeout
- Actors: Who performs each step
Test Derivation:
- Positive: Happy path — all steps succeed in sequence
- Negative: Each branch point's failure/rejection path
- Edge: Skip a step, return to a previous step, concurrent actors, timeout at each step
- State Transition: Use State Transition technique for each decision node
Example flow:
- User submits form → 2. System validates → 3. Manager approves → 4. System sends confirmation
Test cases: successful submission, validation failure, manager rejects, system confirmation failure, duplicate submission.
3. Use Case
Format: Structured with Actor, Preconditions, Main Flow (numbered steps), Alternative Flows, and Exception Flows.
Extract:
- Actor(s): Primary and secondary actors
- Preconditions: Map directly to GIVEN steps
- Main Flow: Generates the primary Positive test case (Use Case Testing technique)
- Alternative Flows: Each generates one additional Positive or Boundary test case
- Exception Flows: Each generates one Negative test case
Test Derivation:
- One test case per main flow
- One test case per alternative flow (alternate success paths)
- One test case per exception flow (error/failure paths)
- Additional boundary cases for any data constraints mentioned
Technique: Use Case Testing for main/alternative flows; Error Guessing for exception flows.
4. REST API Endpoint Specification
Extract from the spec:
- HTTP Method + Endpoint path (e.g.,
POST /api/v1/payments)
- Request schema: required fields, optional fields, field types and constraints
- Response schemas: 200/201 (success), 400 (validation error), 401/403 (auth), 404 (not found), 409 (conflict), 500 (server error)
- Authentication: Bearer token, API key, session
- Business rules embedded in the spec description
Test Derivation:
| Test Category | Coverage |
|---|
| Happy Path | Valid request with all required fields → expected 2xx response |
| Optional Fields | Request with only required fields (no optional) → valid 2xx |
| Field Validation | Missing required field → 400 with appropriate error message |
| Field Validation | Invalid type/format per field → 400 with field-specific error |
| Boundary Values | Min/max values for numeric and string length fields |
| Authentication | No token / expired token / invalid token → 401 |
| Authorization | Valid token but insufficient permissions → 403 |
| Not Found | Valid request for non-existent resource → 404 |
| Conflict/Duplicate | Creating duplicate resource → 409 (if applicable) |
| Edge Cases | Empty arrays, null optional fields, Unicode in string fields |
Technique Mapping:
- Required field tests → Input Field Validation
- Numeric range/length tests → BVA + EP
- Multiple field combinations → Decision Table (if business rules combine fields)
- Status transitions (e.g., order states) → State Transition
BDD Structure for API Tests:
GIVEN A valid authentication token is available
AND The API endpoint POST /api/v1/payments is accessible
WHEN A POST request is sent with [describe payload]
THEN The response status code is [expected code]
AND The response body contains [expected fields/values]
AND [Additional assertions on headers or side effects]
5. Mixed / Freeform Input
When the user provides a feature description without clear structure:
- Identify distinct functional requirements (what the system must do)
- Identify any constraints or rules (limits, permissions, states)
- Treat each functional requirement as an implicit AC
- Apply the same derivation rules as User Story above
AC Numbering for Non-Jira Sources
Since there is no customfield_14400, derive AC numbers from the extracted requirements:
- Number sequentially: AC-1, AC-2, AC-3...
- Each distinct functional requirement or testable behavior = one AC
- Document the extracted ACs in the test case file header under "Derived Requirements"
Feature Toggle Handling for Non-Jira Sources
- If the spec/story mentions a feature flag or toggle → include it in GIVEN and create a toggle-OFF test case
- If no toggle is mentioned → omit toggle test case; note in the file header:
Feature Toggle State : N/A
Header Adaptation for Non-Jira Sources
Use the non-Jira header variant from the test-case-template skill:
| Field | Jira Source | Non-Jira Source |
|---|
| Story ID & Title | Jira key + summary | Reference ID + derived title |
| Value Stream | customfield_22200 | User-provided or "N/A" |
| Subvalue Stream | customfield_22201 | User-provided or "N/A" |
| Portfolio Team | customfield_15604 | User-provided or "N/A" |
| Story Description | Rewrite from Jira description | Rewrite from provided input |
| Derived Requirements | Not needed | List of extracted ACs |
