{"id":14766,"plugin_id":"plugin_asdk_app_6aa2109570b0819194170aae3449f6fb","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:10:07.877Z","digest":"e412530e90577b75c990dc04eb79203b11c8c66930b2b38e671e33d598af4b9f","against":null,"payload":{"name":"load-test","description":"Author and verify a Loadster load test end to end. Write a script, validate and play it, build a load test scenario, and hand off for launch. Use when the user wants to load test, stress test, or performance test a site or API with Loadster, or asks for a Loadster script.","included_files":[{"relative_path":"references/script-types.md","size_in_bytes":6054}],"skill_md_contents":"---\nname: load-test\ndescription: Author and verify a Loadster load test end to end. Write a script, validate and play it, build a load test scenario, and hand off for launch. Use when the user wants to load test, stress test, or performance test a site or API with Loadster, or asks for a Loadster script.\n---\n\n# Building a load test in Loadster\n\nLoadster runs load tests from scripts. A script describes what one bot does; a scenario says how many bots run it,\nfrom where, and for how long. Your job is to get a verified script and a ready scenario into the user's project.\nLaunching the full test is the user's job, on purpose, and no tool lets you do it.\n\n## Before you write anything\n\n1. **Confirm authorization.** The target must be a system the user owns or is authorized to test. If that isn't\n   clear from context, ask. Loadster's terms require it and you shouldn't assume it.\n2. **Pick the project.** Call `list_projects` and use the one the user names. If they're experimenting, suggest a\n   separate project so the agent's work doesn't mix with the team's real tests.\n3. **Read the documentation for the script type you're about to use.** Call `get_documentation` for the relevant\n   topics before authoring. The server's `instructions` say the same thing, and it matters: the script formats have\n   details you will get wrong from memory.\n4. **Choose the script type.** Read [references/script-types.md](references/script-types.md) for the decision\n   table and the documentation topic keys for each type. In short:\n   - **Protocol Bots** (HTTP-level) for APIs, simple sites, and high bot counts at low cost.\n   - **Browser Bots** (real Chrome, step-based) for websites and web apps where you want realistic client-side\n     behavior without writing code.\n   - **Playwright Test** scripts (code-first JavaScript) when the user already has Playwright tests or wants full\n     control.\n   Use `list_command_types` and `get_command_schema` for Protocol and Browser Bot commands, `get_scripting_api` for\n   code blocks and Playwright, and `get_example` when you need a starting point.\n\n## Author, validate, play\n\nA saved script is unverified until it has been played. Follow this loop and don't skip steps:\n\n1. **Create or update** the script with `create_script` or `update_script`. Use gentle, realistic think times\n   between steps. Use `create_dataset` and `append_dataset_rows` when steps need varied data such as logins or\n   search terms, then reference the dataset from the script.\n2. **Validate** with `validate_script`. Fix every problem it reports before playing.\n3. **Play** with `play_script`. This runs a single bot through the script once. Poll `get_play_status` until it\n   finishes.\n4. **Inspect the result.** Use `get_step_detail` for each failing or suspicious step (status codes, response bodies,\n   captured values, logs), and `get_screenshot` for Browser Bot and Playwright plays. Fix the script and play again\n   until every step passes for the right reasons, not just without errors. A 200 from a login page that didn't log in\n   is still a failure. When a failure doesn't make sense, check the failure modes in\n   [references/script-types.md](references/script-types.md) before guessing; several common ones (eventual\n   consistency, slow-but-healthy flows, client-side timeouts) leave no error in the response at all.\n5. **Stop** a stuck play with `stop_script` rather than leaving it running.\n\nTell the user what you changed between plays and why. Script updates create revisions, so\n`list_script_revisions` and `restore_script_revision` can undo a bad edit.\n\n## Build the scenario\n\n1. Call `list_engines` to see which regions and any private engines are available.\n2. Create the scenario with `create_scenario`: one or more bot groups, each with a script, a bot count, a ramp\n   pattern, and a region. Start smaller than the user's target and suggest ramping up in later runs; the goal of a\n   first test is usually to find where the system starts to degrade, not to knock it over.\n3. Ask before anything destructive. Deleting scripts, datasets, or scenarios removes the team's work, so confirm\n   with the user first even if the client doesn't prompt.\n\n## Hand off\n\nSummarize what you built: the script, what it does, what the play showed, and the scenario's bot groups. Point the\nuser to the scenario in their Loadster dashboard to launch it. Once the test has run, the `results` skill\ncovers reading the report.\n\nIf the tools made any of this harder than it should have been, `submit_feedback` sends a note to the Loadster team,\nwho read it to improve them. It's optional and nothing here depends on it. A note describes the tools, not the\nuser's prompts, their credentials, or anything from their account.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}