Prompts

A prompt is a guided, fill-in-the-blank request that the Cycle MCP server provides ready-made. Instead of composing the perfect instruction yourself, you pick a prompt, answer one question in plain words, and the server expands your answer into a complete, Cycle-aware request for the agent — one that already tells the agent to read the right resources, explore the live app instead of guessing, and hand authoring off to a specialized agent.

Prompts are the easiest on-ramp for Cycle MCP. They're especially useful if you're newer to working with AI agents: a short, vague request that would normally get a ineffective result becomes a well-structured workflow because the prompt supplies the structure for you.

How prompts are surfaced

Prompts are part of the MCP standard, but each agent host presents them differently:

Agent	How to invoke a prompt
Claude Code	Prompts appear as slash commands (type / and look for the cycle server's prompts), or in the prompt/command picker.
Cursor	Surfaced in the chat's prompt/command picker for the cycle MCP server.
GitHub Copilot in VS Code	Available through Copilot's MCP prompt surface in agent mode; support varies by Copilot version.

If your host doesn't list any Cycle prompts, confirm the server is connected and that you've signed in. Hosts that don't support MCP prompts at all simply won't show them — you can still describe the same request in plain language and the agent will use the Cycle tools and resources directly.

The agent also keeps a catalog of the available prompts at the cycle://prompts resource, so you can always ask: "What Cycle prompts are available?"

Available prompts

author-a-test

Use this when you want to create a new Cycle test but aren't sure what details the agent needs from you.

• You provide — one input, request: in plain words, what the test should do. Put it all in one description — what you want to verify, the app or site under test (a URL or a name), the key steps or expected outcome if you know them, and any test data (logins, sample records, search terms).
• The agent then — restates its understanding back to you for confirmation, asks for anything essential that's missing (especially the URL or screen to start from), explores the running application a step at a time so it never guesses at locators, hands the confirmed workflow to the feature-file-author subagent to produce a validated .feature file, and keeps a running record of the whole session in a MCP Prompt Logs/ folder at the root of your Cycle project.

You review the resulting .feature file and the log, then iterate.

debug-a-failed-run

Use this when a Cycle test just failed and you want help finding and fixing the cause.

• You provide — one input, request: in plain words, which test or .feature failed, what you observed (an error message, or the step that failed), and where the run output lives (the output directory or results .db) if you know it.
• The agent then — gathers the concrete failure evidence first (it reads the structured cycle://run-errors/{output_dir} resource rather than guessing from the test name), reasons about the most likely cause (locator drift, timing, data, or authentication), inspects the live page if it looks like a locator problem, and only then proposes a fix with the evidence that points to it — again keeping a running log under MCP Prompt Logs/.