
running-release-tests
Run automated release testing (UI or API) via the AWS DevOps Agent using a pre-configured test profile. Use when the user wants to validate multi-step workflows, verify features, check for regressions, or test API endpoints. Trigger words include run tests, UAT, test my app, test profile, UI test, API test, automated testing, regression test, QA, end-to-end test, run the QA agent.
- Installs
- 1.4K
- Last 24h
- +9
- Trending rank
- #8985
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/aws/agent-toolkit-for-aws --skill running-release-tests- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads running-release-tests automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Release Testing
AgentSpace routing (SigV4 only): If
list_agent_spacesis available in your tool list and the multi-space orchestration skill has NOT been invoked yet this session, invoke it first to determine whichagent_space_idto use. Then passagent_space_idon all tool calls below. For bearer token auth this is unnecessary — the token is already scoped to one space.
Run automated release testing in the cloud via the AWS DevOps Agent's Release Testing Agent. Supports UI testing (browser-based) and API testing (OpenAPI spec-based). Uses pre-existing test profiles that define target URL, agent type, personas, and credentials.
Input is a test profile — the test profile already contains the target URL, agent type (UI or API), test personas, and credentials. Do NOT ask the user for a URL directly; the URL is defined in the test profile.
Prerequisites
- A pre-existing test profile (Knowledge Item ID like
ki-12345) created from the AWS DevOps Agent console
Gathering test parameters
Before starting any workflow, you MUST gather the following parameters. Do NOT proceed to job creation until answered.
Step 1 — Test profile (required)
Ask the user which test profile to use. The test profile already contains the target URL, agent type (UI or API), test personas, and credentials configuration — these do NOT need to be gathered separately.
Note: A pre-existing test profile is a prerequisite. Test profiles are created using the AWS DevOps Agent console or API, not through this tool. If the user asks whether one can be created here, inform them it must already exist.
Step 2 — Test requirement (optional)
If the user has not already mentioned a test focus, ask:
"Do you have a specific test requirement or focus area? If not, I'll run a full exploratory test."
Wait for the user's response. If they provide one, use it as the test_requirement. If they say no or skip, proceed without it.
IMPORTANT: You MUST wait for the user to respond before proceeding to job creation.
Core workflow
1. Select Agent Space
List available agent spaces:
aws devops-agent list-agent-spaces --region us-east-1
Present the list to the user and ask which agent space they'd like to use. Do NOT proceed until the user has selected one. Use the selected agentSpaceId as SPACE_ID in all subsequent calls.
2. Check tool availability
Verify that the following tools are available: aws_devops_agent__create_release_testing_job, aws_devops_agent__get_task, aws_devops_agent__list_journal_records, aws_devops_agent__get_release_ui_testing_report, aws_devops_agent__get_release_api_testing_report. These tools are NOT deferred/lazy-loaded — if they do not appear in your tool list, they are unavailable. Do NOT search for them via ToolSearch. If any are missing, skip the remaining steps in this section and use the "Fallback (aws-mcp)" path below instead.
3. Start the Job
aws_devops_agent__create_release_testing_job(
test_profile_id="ki-12345",
webhook_event_message="<optional test requirement>"
)
→ {"taskId": "...", "executionId": "...", "status": "started"}
Record the taskId and executionId from the response.
4. Poll for Status
Call aws_devops_agent__get_task(task_id=TASK_ID) every 30 seconds until the status transitions to IN_PROGRESS or a terminal state.
5. Monitor Until Completion
Once IN_PROGRESS, poll for progress in a loop:
- Call
aws_devops_agent__list_journal_records(execution_id=EXEC_ID, order="ASC")to fetch new findings. - Present each record to the user with a friendly progress update.
- Use
next_tokenfrom the response to fetch only new records on subsequent polls. - Wait 20 seconds between each poll iteration.
- Check
aws_devops_agent__get_task(task_id=TASK_ID)periodically — stop when terminal status (COMPLETED,FAILED,CANCELED,TIMED_OUT).
6. Present Results
Once the job reaches a terminal status:
- If
COMPLETED:-
Determine the report type from the test profile's agent type (UI or API). Call
aws_devops_agent__get_release_ui_testing_report(execution_id=EXEC_ID)for UI profiles oraws_devops_agent__get_release_api_testing_report(execution_id=EXEC_ID)for API profiles. -
Write the report contents to a markdown file:
release-testing-report-<YYYY-MM-DD-HHmmss>.md -
Inform the user that the report was saved, including the file path.
-
- If
FAILEDorTIMED_OUT: Present the error information and suggest next steps. - If
CANCELED: Inform the user the job was canceled and no report is available.
Cancelling a job
aws_devops_agent__cancel_release_testing_job(task_id=TASK_ID)
Error handling
- If the task status changes to
FAILED, stop the workflow and report the error. - If the task does not reach
IN_PROGRESSwithin 5 minutes, cancel it usingcancel_release_testing_job. - If any output contains "NoCredentialsError", "ExpiredTokenException", or auth failures, suggest the user refresh their credentials or check the bearer token.
- If throttled (
429orThrottlingException), wait 30 seconds before retrying. After 3 retries, inform the user.
Fallback (aws-mcp)
If the aws-devops-agent remote server is unavailable, use the AWS CLI directly:
Tell the user: "Remote server unavailable — using direct AWS API fallback."
1. Select Agent Space
List available agent spaces:
aws devops-agent list-agent-spaces --region us-east-1
Present the list to the user and ask which agent space they'd like to use. Do NOT proceed until the user has selected one. Use the selected agentSpaceId as SPACE_ID in all subsequent calls.
2. Start the Job
aws devops-agent create-backlog-task \
--agent-space-id SPACE_ID \
--task-type RELEASE_TESTING \
--title 'Release Testing' \
--priority MEDIUM \
--description '{\"testProfileId\": \"<PROFILE_ID>\", \"webhookEventMessage\": \"<REQUIREMENT>\"}' \
--region us-east-1
If the user provided a test requirement, include it as webhookEventMessage. If not, omit the field or leave it empty.
3. Poll for Status
aws devops-agent get-backlog-task \
--agent-space-id SPACE_ID \
--task-id TASK_ID \
--region us-east-1
Poll every 30 seconds until the status transitions to IN_PROGRESS or a terminal state (COMPLETED, FAILED, CANCELED, TIMED_OUT).
4. Monitor Until Completion
Once IN_PROGRESS, poll for progress in a loop:
aws devops-agent list-journal-records \
--agent-space-id SPACE_ID \
--execution-id EXEC_ID \
--order ASC \
--region us-east-1
- Present each record to the user with a friendly progress update.
- Use
next_tokenfrom the response to fetch only new records on subsequent polls. - Wait 20 seconds between each poll iteration.
- Check
get-backlog-taskperiodically — stop when terminal status (COMPLETED,FAILED,CANCELED,TIMED_OUT).
5. Present Results
Once the job reaches a terminal status:
- If
COMPLETED:-
Retrieve the report using the appropriate record type:
- UI testing:
--record-type qa_ui_testing_report - API testing:
--record-type qa_api_testing_report
aws devops-agent list-journal-records \ --agent-space-id SPACE_ID \ --execution-id EXEC_ID \ --record-type qa_ui_testing_report \ --order ASC \ --region us-east-1 - UI testing:
-
Write the report contents to a markdown file:
release-testing-report-<YYYY-MM-DD-HHmmss>.md -
Inform the user that the report was saved, including the file path.
-
- If
FAILEDorTIMED_OUT: Present the error information and suggest next steps. - If
CANCELED: Inform the user the job was canceled and no report is available.
Cancelling (fallback)
aws devops-agent update-backlog-task \
--agent-space-id SPACE_ID \
--task-id TASK_ID \
--task-status CANCELED \
--region us-east-1
FAQ
What does the running-release-tests skill do?
Run automated release testing (UI or API) via the AWS DevOps Agent using a pre-configured test profile. Use when the user wants to validate multi-step workflows, verify features, check for regressions, or test API endpoints. Trigger words include run tests, UAT, test my app, test profile, UI test, API test, automated testing, regression test, QA, end-to-end test, run the QA agent.
How do I install running-release-tests?
Run npx skills add https://github.com/aws/agent-toolkit-for-aws --skill running-release-tests in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/running-release-tests/ (personal) or .claude/skills/running-release-tests/ (project).
Which AI agents can use running-release-tests?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is running-release-tests safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains running-release-tests?
It is published by aws in aws/agent-toolkit-for-aws, and it is an official skill from the maker of the technology it covers. It has 1,447 recorded installs.
More from aws/agent-toolkit-for-aws
aws-iam
aws/agent-toolkit-for-aws
Provides verified corrections for IAM behaviors that AI agents frequently get wrong — policy evaluation edge cases, trust policy gotchas, STS session limits, Organizations quirks, and SAML/MFA specifics. Also provides structured workflows for IAM role management and baseline policy generation from application source code or a Terraform plan JSON. Covers condition operator safety (ForAnyValue/ForAllValues with Null checks), bucket policy deny patterns (VPC endpoint restrictions, org paths), confused deputy protection, and service role creation for AWS services (Glue, CloudTrail, Lambda, ECS, etc.) with aws:SourceAccount/aws:SourceArn trust conditions. Applies when creating IAM roles, writing IAM or bucket policies, generating policies from application source code or a Terraform plan JSON, working with STS, Organizations, or condition operators, or any task needing a service or execution role. Does not cover non-IAM authorization like Cognito user-pool policies or app-level RBAC.
aws-serverless
aws/agent-toolkit-for-aws
Routes serverless requests to a compute form factor and the skill that owns it. Applies first to Lambda, API Gateway, EventBridge, Step Functions and event-driven work while the compute, orchestration or integration choice is open — API backends, webhooks, jobs, cron, queue/stream consumers, durable workflows, event routing, Step Functions vs Durable Functions, and Pipes vs native event source mappings for queues and streams. Decides Event Functions on-demand vs Managed Instances, Web Functions, MicroVMs, EventBridge rules/Scheduler/Pipes/bus, HTTP vs REST API. Owns shared Lambda references (cold starts, SnapStart, concurrency, event sources, function URLs, throttling, troubleshooting). Defers to the specialized skill once a request commits to one form factor or service, or describes its defining feature, even unnamed (durable checkpointing and automatic step retries, Firecracker sandbox, managed instances, Node.js server). Not for EC2, ECS/EKS/Fargate or Amplify hosting.
aws-observability
aws/agent-toolkit-for-aws
Builds, configures, debugs, and optimizes AWS observability - operator-symptom questions and detecting Omni vs classic CloudWatch. CloudWatch on an already-reporting service: Log Insights, metric/composite/anomaly alarms, custom metrics/EMF, dashboards, X-Ray/ADOT tracing, canaries, CloudTrail, Dynamic Instrumentation (live breakpoints/snapshots), the Application Signals service map, and fleet health views. CloudWatch Omni on an existing Space: SQL over logs and traces, PromQL over metrics, Omni dashboards, Omni alerts, context graph for root cause, programmatic/IaC access (API/SDK/CLI/CloudFormation), driving Omni from a coding agent or skills, and evaluating AI agent quality from traces - on-demand and online scoring of live traffic, readback, custom evaluators. For first-time setup - creating an Omni Space, granting access, ingestion, or ADOT instrumentation for Application Signals (ServiceEvents, CI/CD metadata) or Omni - use setting-up-cloudwatch-observability. Not for app logging
aws-cdk
aws/agent-toolkit-for-aws
Authors, deploys, and troubleshoots AWS infrastructure using CDK with TypeScript or Python. Covers best practices, stack architecture, and construct patterns. Applies when writing CDK constructs, bootstrapping environments, running cdk deploy/synth/diff, fixing CDK or CloudFormation errors, planning stack structure, importing existing resources, resolving drift, or refactoring stacks without resource replacement.
aws-containers
aws/agent-toolkit-for-aws
Builds and deploys containerized workloads on Elastic Kubernetes Service (EKS), Elastic Container Service (ECS), Fargate, and ECR (Elastic Container Registry). Covers general EKS knowledge, Karpenter, AWS Load Balancer Controller and leveraging various open source Kubernetes projects with EKS. Covers general ECS knowledge, task definitions, Fargate services, ECS Exec, ECS Express Mode and ECS Managed Instances. Covers general Elastic Beanstalk knowledge, Elastic Beanstalk configuration and platforms supported by Elastic Beanstalk. Covers general ECR knowledge, ECR repository setup and lifecycle policies. Includes recommending, enabling, and reading Amazon ECS Action Logs to troubleshoot control-plane failures (deployment rollback/circuit-breaker, task placement, scaling, task replacement). Applies when deploying, debugging, or optimizing containers on AWS. Should be used instead of relying on internal knowledge for these services.
aws-billing-and-cost-management
aws/agent-toolkit-for-aws
Analyze AWS costs, find savings, manage budgets, evaluate Savings Plans and Reserved Instances, right-size EC2/Lambda/RDS/EBS with Compute Optimizer, look up service pricing, query CUR with Athena, detect cost anomalies, scope costs to billing views, and monitor Free Tier usage. Triggers on: AWS bill, cost analysis, reduce spend, savings plan, reserved instance, right-size, budget alert, cost optimization, pricing, free tier, cost anomaly, CUR, cost audit, billing view, billing view ARN.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work