Canned Prompts (Staged Workflow)
The plugin includes four staged canned prompts that guide you through a structured API change-detection, impact analysis, and healing workflow. Each stage produces output that feeds directly into the next, giving you a checkpoint to review before proceeding.
Use this workflow when you want a clear, auditable record of what changed, what was affected, and what was fixed.
The four stages
Prompt name | Stage | Purpose | Required arguments |
|---|---|---|---|
| 1 of 4 | Lists all projects and their APIs in the ReadyAPI workspace. Run this first to identify the exact project and API name needed for Stage 2. | None |
| 2 of 4 | Fetches the current spec stored in ReadyAPI for a given project and API. Displays a brief summary - title, version, and endpoint count - as a confirmation checkpoint. |
|
| 3 of 4 | Runs the full spec diff and test-impact analysis. Reports spec changes (added, removed, and modified endpoints, with breaking changes highlighted) and impacted tests grouped by breaking vs. non-breaking. |
|
| 4 of 4 | Applies fixes to all impacted test steps in a single batch, re-runs the suite, and confirms all tests pass. Stops and reports if no impacted tests are found. | Same elicitation as |
Running the workflow
Stage 1 - Discover your workspace
Run discover_workspace with no arguments. The prompt returns a list of all projects and their imported APIs. Use this output to confirm the exact projectName and apiName values you need for Stage 2.
Stage 2 - Fetch the existing spec
Run fetch_existing_spec with your projectName and apiName. The prompt retrieves the current spec from ReadyAPI and displays a short summary. Confirm the title and version match what you expect before continuing.
Note
Stage 2 is optional in many cases. The Stage 3 and Stage 4 prompts use analyze_api_impact, which automatically resolves the current spec from the project. Run Stage 2 when you want to manually verify the spec version before proceeding.
Stage 3 - Analyze impact
Run analyze_api_impact with your apiName, the current spec (oldSpec), the new spec (newSpec), and the source type (newSpecSourceType). The prompt returns:
A spec diff showing added, removed, and modified endpoints, with breaking changes flagged.
A test impact report listing affected test steps grouped by suite and case.
Per-step healing advice for each impacted step.
Review this output carefully before proceeding to Stage 4. Breaking changes are highlighted separately from non-breaking changes.
For supported newSpecSourceType values, see Spec source types.
Stage 4 - Heal impacted tests
Run heal_impacted_tests. The prompt executes the following pipeline:
Calls
analyze_api_impactto retrieve the current impact data.Presents a Healing Plan table showing each impacted test step, its suite and case, the affected endpoint, and the changes to apply. If no tests are impacted, the prompt stops here and reports that no action is needed.
Calls
rest_test_step_updateonce for each impacted test step, passing the parameter changes, request body changes, and assertion changes mapped from theanalyze_api_impactoutput.Presents a Results table showing applied changes, skipped changes, and the reason for each skip. Confirms whether the project was saved.
Note
For any step where
healingAction: MANUAL_REVIEWis returned, the fix cannot be applied automatically. Intervention in ReadyAPI is required for those steps before re-running. Seerest_test_step_updatefor full details on healing actions.
Spec source types
The newSpecSourceType parameter in Stages 3 and 4 accepts the following values:
Value | Description |
|---|---|
| Remote URL pointing to a Swagger or OpenAPI definition |
| Absolute path to a local OpenAPI/Swagger file (JSON or YAML) |
| Inline JSON or YAML spec content provided directly in the prompt |