We have a large manual regression test manifest stored in Excel (hundreds of test cases that are difficult or impossible to automate). We’d like to include it in our Cursor workflow so that agents or BugBot can help us identify which manual tests are relevant for a given code change or PR — basically generating a regression checklist automatically based on what changed.
Is there a supported way today to:
Attach or reference a test manifest file (Excel/CSV) as context for an agent or BugBot?
Define a repo-based manifest (YAML/JSON/Markdown) that agents automatically consult when reviewing changes for regression coverage?
Use Automations or Rules to map changed files/features to relevant manual test cases from the manifest?
If this isn’t natively supported yet, what’s the recommended pattern to build this on top of Cursor (e.g. via .cursor/rules, Automations, MCP, etc.)?
Our goal is to reduce manual QA time by having the agent surface the right subset of manual tests for each PR or code change, rather than reviewing the entire manifest every time.
Would love to hear if anyone has built something like this or if there’s a first-class feature planned for test manifest + diff → regression checklist workflows.
Hey, thanks for the detailed request. There’s no separate native feature for “manifest → pick manual tests for a diff” right now, but you can build that workflow from existing pieces. The key point is that the manifest needs to be stored as text in the repo (CSV / Markdown / YAML), not as a binary .xlsx. Agents and BugBot work with files in the worktree, so export your Excel to a text format.
Recommended pattern:
BugBot rules for PR review. Put instructions in .cursor/BUGBOT.md at the repo root, for example “output a checklist of manual regression tests relevant to the changed files”. It’s handy to split the manifest by feature or directory and keep it close to the code so changes in a specific area pull only the needed slice, not the whole list. Docs: Bugbot | Cursor Docs
Project rules for IDE and agent work. In .cursor/rules/*.mdc you can set globs: frontmatter so a rule attaches automatically when matching files are in context, and you can inline the relevant piece of the manifest via @file (for example a rule with globs: payments/** that references manual-tests/payments.md). Docs: Rules | Cursor Docs
Automations, if you want it to run on a PR event. Use an agent with a prompt like “take this diff, compare it with manual-tests/manifest.md, and build a regression checklist”. Docs: Automations | Cursor Docs
MCP is the best option if the manifest must live in an external system (TestRail, SharePoint, a live spreadsheet). You run an MCP server that exposes test cases as a queryable tool, and the agent fetches relevant cases dynamically without keeping a snapshot in the repo. Docs: Model Context Protocol (MCP) | Cursor Docs
Practical tip for “hundreds of cases”: keep the manifest split by features or directories like in item 1. If you put the whole manifest into one always applied rule, it bloats context and hurts relevance.
Related to this (BugBot rules closer to the code), there are open feature requests. You can check this thread: Pointing bugbot at repo's code guidelines rules and skills. If you build something that works well, I’d love to hear how it goes. Tell me if you want more detail on any step.
Hey, good choice. MCP is exactly for cases where the source needs to stay external and editable by non-devs.
Key point: you run and host the MCP server. Cursor only connects to it, Cursor does not host servers. There are two types:
Local (stdio): a process runs on your machine using command and args, and it’s only available to your local IDE. This won’t work for your case. Product users can’t use it, and cloud agents can’t reach it.
Remote (HTTP): the server lives at a URL, and you add its address in Cursor and, if needed, headers for auth. This is what you want: one server that agents can reach, while the source (TestRail, SharePoint, a live spreadsheet) stays outside the repo.
So yes, you need to host a remote MCP server somewhere yourself (your own hosting or any cloud provider, anywhere reachable over HTTPS). First check if your tool already has a hosted MCP endpoint. Some SaaS products ship one out of the box, then you just add the URL and token in Cursor and don’t need to run anything. Connection setup: Model Context Protocol (MCP) | Cursor Docs
A couple important notes:
Transport: for a remote server, pick Streamable HTTP, not SSE. SSE has a known issue where Cursor doesn’t always switch correctly and the server hangs. If your source is only available via SSE, a workaround is to wrap it with mcp-remote, which bridges a remote server into stdio.
BugBot: it supports MCP for extra context during PR review, but only on the Teams or Enterprise plan, set up via the BugBot dashboard. On Free or Pro, MCP in BugBot is not available. Keep that in mind if your flow depends on BugBot. For normal agents in the IDE and in the cloud, MCP works regardless. Docs: Bugbot | Cursor Docs
Tell me which external source you’re using, and I’ll suggest the exact setup.